展示HN:One-MCP:无上下文膨胀的无限工具MCP服务器

1作者: freakynit21 天前原帖
嘿,HN, 我一直在实验如何让大型语言模型(LLMs)动态使用大量工具,而无需将所有工具预先加载到上下文中——因此我构建了 one-mcp 来探索这个想法。 one-mcp 是一个开源的 MCP 服务器,使用 FastAPI 构建,充当语义索引和 API 工具的动态加载器。 与其在 LLM 会话中硬编码或嵌入每个工具规格(这会迅速增加上下文大小和成本),one-mcp 允许模型按需搜索、加载和执行工具——使用嵌入和自然语言查询。 它的功能包括: - 工具的语义搜索:使用自然语言查询您的 API 目录(例如“如何获取用户信息”),并返回相关的工具规格。 - 上传/管理/删除工具:通过简单的 REST API 或直接从 MCP 本身进行 JSON 或文件格式的工具导入。 - MCP 集成:作为一个合规的 MCP 服务器工作——可以将其插入到支持 MCP 的客户端或框架中。 示例: --- 上传工具 --- ```bash curl -X POST http://localhost:8003/api/tools/upload-json \ -H "Content-Type: application/json" \ -d '{"tools": [{"name": "getUserProfile", "description": "Retrieves user profile"}]}' ``` --- 语义搜索 --- ```bash curl -X POST http://localhost:8003/api/tools/search \ -H "Content-Type: application/json" \ -d '{"query": "how to get user info"}' ``` 您也可以直接使用 MCP 进行这两项操作 :) 为什么这很重要: 目前大多数 LLM 设置(即使是那些具有 MCP 或工具 API 的设置)都在前期加载所有工具——这会膨胀提示/上下文大小,浪费令牌预算,并增加推理成本。 通过 one-mcp,工具存储在外部向量存储中——LLMs 只“看到”与当前用户查询最相关的少数工具。这种架构可能使动态工具生态系统更具可扩展性。 我期待您的反馈。 [https://github.com/freakynit/one-mcp](https://github.com/freakynit/one-mcp)
查看原文
Hey HN,<p>I’ve been experimenting with how LLMs can dynamically use large sets of tools without needing to preload them all into context - and built one-mcp to explore that idea.<p>one-mcp is an open source MCP server built with FastAPI that acts as a semantic index + dynamic loader for API tools.<p>Instead of hardcoding or embedding every tool spec in an LLM session (which quickly blows up context size and costs), one-mcp lets the model search, load, and execute tools on demand — using embeddings and natural language queries.<p>What it does:<p>- Semantic Search for Tools: Query your API catalog with natural language (&quot;how to get user info&quot;) and get relevant tool specs back.<p>- Upload&#x2F;Manage&#x2F;Delete Tools: JSON or file-based tool ingestion with a simple REST API or directly from MCP itself.<p>- MCP Integration: Works as a compliant MCP server — plug it into MCP-enabled clients or frameworks.<p>Example:<p>--- Upload tools ---<p>curl -X POST [http:&#x2F;&#x2F;localhost:8003&#x2F;api&#x2F;tools&#x2F;upload-json](http:&#x2F;&#x2F;localhost:8003&#x2F;api&#x2F;tools&#x2F;upload-json) -H &quot;Content-Type: application&#x2F;json&quot; -d &#x27;{&quot;tools&quot;: [{&quot;name&quot;: &quot;getUserProfile&quot;, &quot;description&quot;: &quot;Retrieves user profile&quot;}]}&#x27;<p>--- Semantic search ---<p>curl -X POST [http:&#x2F;&#x2F;localhost:8003&#x2F;api&#x2F;tools&#x2F;search](http:&#x2F;&#x2F;localhost:8003&#x2F;api&#x2F;tools&#x2F;search) -H &quot;Content-Type: application&#x2F;json&quot; -d &#x27;{&quot;query&quot;: &quot;how to get user info&quot;}&#x27;<p>You can MCP itself as well for both these operations :)<p>Why this matters:<p>Most current LLM setups (even those with MCP or tool APIs) load all tools upfront - which inflates prompt&#x2F;context sizes, wastes token budget, and increases inference costs.<p>With one-mcp, tools live in an external vector store - LLMs only &quot;see&quot; the few tools most relevant to the current user query. This architecture could make dynamic tool ecosystems more scalable.<p>I’d love your feedback..<p><a href="https:&#x2F;&#x2F;github.com&#x2F;freakynit&#x2F;one-mcp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;freakynit&#x2F;one-mcp</a>