LLM 智能体无法将数千个工具定义放入上下文。 向量搜索可以找到相似的工具，但会遗漏它们所属的工作流。 graph-tool-call 构建工具图并检索正确的链条——而不仅仅是一个匹配项。
无检索 | graph-tool-call | |
248 个工具 (K8s API) | 12% 准确率 | 82% 准确率 |
1068 个工具 (GitHub 完整 API) | 上下文溢出 | 78% Recall@5 |
Token 使用量 | 8,192 tok | 1,699 tok (减少 79%) |
使用 qwen3:4b (4-bit) 测量 — 完整基准测试
LLM 智能体需要工具。但随着工具数量的增加，会出现两个问题：
上下文溢出 — 248 个 Kubernetes API 端点 = 8,192 个 Token 的工具定义。LLM 会不堪重负，准确率降至 12%。
向量搜索无法处理工作流 — 搜索 "取消我的订单" 会找到 cancelOrder，但实际流程是 listOrders → getOrder → cancelOrder → processRefund。向量搜索只返回一个工具；你需要的是整个链条。
graph-tool-call 同时解决了这两个问题。它将工具关系建模为图，通过混合搜索（BM25 + 图遍历 + 嵌入 + MCP 注解）检索多步工作流，在保持或提高准确率的同时，减少了 64–91% 的 Token 使用量。
场景 | 仅向量搜索 | graph-tool-call |
"取消我的订单" | 返回 |
|
"读取并保存文件" | 返回 |
|
"删除旧记录" | 返回任何匹配 "delete" 的工具 | 通过 MCP 注解优先排序破坏性工具 |
"现在取消它" (在列出订单后) | 历史记录无上下文 | 降低已使用工具的权重，提升下一步工具的权重 |
多个具有重叠工具的 Swagger 规范 | 结果中存在重复工具 | 跨源自动去重 |
1,200 个 API 端点 | 缓慢，结果嘈杂 | 分类 + 图遍历以实现精确检索 |
Related MCP server: nexus-mcp-ci
OpenAPI / MCP / Python functions → Ingest → Build tool graph → Hybrid retrieve → Agent示例 — 用户说 "取消我的订单并处理退款"
向量搜索找到 cancelOrder。但实际工作流是：
┌──────────┐
PRECEDES │listOrders│ PRECEDES
┌─────────┤ ├──────────┐
▼ └──────────┘ ▼
┌──────────┐ ┌───────────┐
│ getOrder │ │cancelOrder│
└──────────┘ └─────┬─────┘
│ COMPLEMENTARY
▼
┌──────────────┐
│processRefund │
└──────────────┘graph-tool-call 返回整个链条，而不仅仅是一个工具。检索通过 加权倒数排名融合 (wRRF) 结合了四个信号：
BM25 — 关键词匹配
图遍历 — 基于关系的扩展 (PRECEDES, REQUIRES, COMPLEMENTARY)
嵌入相似度 — 语义搜索 (可选，支持任何提供商)
MCP 注解 — 只读 / 破坏性 / 幂等提示
核心包零依赖 — 仅使用 Python 标准库。按需安装：
pip install graph-tool-call # core (BM25 + graph) — no dependencies
pip install graph-tool-call[embedding] # + embedding, cross-encoder reranker
pip install graph-tool-call[openapi] # + YAML support for OpenAPI specs
pip install graph-tool-call[mcp] # + MCP server / proxy mode
pip install graph-tool-call[all] # everything扩展 | 安装内容 | 使用场景 |
| pyyaml | YAML OpenAPI 规范 |
| numpy | 语义搜索 (连接到 Ollama/OpenAI/vLLM) |
| numpy, sentence-transformers | 本地 sentence-transformers 模型 |
| rapidfuzz | 重复检测 |
| langchain-core | LangChain 集成 |
| pyvis, networkx | HTML 图导出, GraphML |
| dash, dash-cytoscape | 交互式仪表盘 |
| ai-api-lint | 自动修复错误的 API 规范 |
| mcp | MCP 服务器 / 代理模式 |
uvx graph-tool-call search "user authentication" \
--source https://petstore.swagger.io/v2/swagger.jsonQuery: "user authentication"
Source: https://petstore.swagger.io/v2/swagger.json (19 tools)
Results (5):
1. getUserByName — Get user by user name
2. deleteUser — Delete user
3. createUser — Create user
4. loginUser — Logs user into the system
5. updateUser — Updated userfrom graph_tool_call import ToolGraph
# Build a tool graph from the official Petstore API
tg = ToolGraph.from_url(
"https://petstore3.swagger.io/api/v3/openapi.json",
cache="petstore.json",
)
print(tg)
# → ToolGraph(tools=19, nodes=22, edges=100)
# Search for tools
tools = tg.retrieve("create a new pet", top_k=5)
for t in tools:
print(f"{t.name}: {t.description}")
# Search with workflow guidance
results = tg.retrieve_with_scores("process an order", top_k=5)
for r in results:
print(f"{r.tool.name} [{r.confidence}]")
for rel in r.relations:
print(f" → {rel.hint}")
# Execute an OpenAPI tool directly
result = tg.execute(
"addPet", {"name": "Buddy", "status": "available"},
base_url="https://petstore3.swagger.io/api/v3",
)plan_workflow() 返回带有先决条件的有序执行链 — 将智能体的往返次数从 3-4 次减少到 1 次。
plan = tg.plan_workflow("process a refund")
for step in plan.steps:
print(f"{step.order}. {step.tool.name} — {step.reason}")
# 1. getOrder — prerequisite for requestRefund
# 2. requestRefund — primary action
plan.save("refund_workflow.json")编辑、参数化和可视化工作流 — 请参阅 Direct API 指南。
# From an MCP server (HTTP JSON-RPC tools/list)
tg.ingest_mcp_server("https://mcp.example.com/mcp")
# From an MCP tool list (annotations preserved)
tg.ingest_mcp_tools(mcp_tools, server_name="filesystem")
# From Python callables (type hints + docstrings)
tg.ingest_functions([read_file, write_file])MCP 注解 (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) 被用作检索信号 — 查询意图会自动分类，读取查询会优先考虑只读工具，而删除查询会优先考虑破坏性工具。
graph-tool-call 提供了几种集成模式。选择最适合你技术栈的一种：
你正在使用... | 模式 | Token 节省 | 指南 |
Claude Code / Cursor / Windsurf | MCP 代理 (聚合 N 个 MCP 服务器 → 3 个元工具) | ~1,200 tok/轮 | |
任何兼容 MCP 的客户端 | MCP 服务器 (作为 MCP 的单一源) | 不等 | |
LangChain / LangGraph (50+ 工具) | 网关工具 (N 个工具 → 2 个元工具) | 92% | |
OpenAI / Anthropic SDK (现有代码) | 中间件 (1 行猴子补丁) | 76–91% | |
对检索的直接控制 | Python API ( | 不等 |
当你拥有许多 MCP 服务器时，它们的工具名称会在每一轮 LLM 对话中堆积。将它们捆绑在一个服务器后面：172 个工具 → 3 个元工具。
# 1. Create ~/backends.json listing your MCP servers
# 2. Register the proxy with Claude Code
claude mcp add -s user tool-proxy -- \
uvx "graph-tool-call[mcp]" proxy --config ~/backends.json完整设置、透传模式、远程传输 → MCP 代理指南。
from graph_tool_call.langchain import create_gateway_tools
# 62 tools from Slack, GitHub, Jira, MS365...
gateway = create_gateway_tools(all_tools, top_k=10)
# → [search_tools, call_tool] — only 2 tools in context
agent = create_react_agent(model=llm, tools=gateway)与绑定所有 62 个工具相比，Token 减少了 92%。请参阅 LangChain 指南 以获取自动过滤和手动模式。
from graph_tool_call.middleware import patch_openai
patch_openai(client, graph=tg, top_k=5) # ← add this one line
# Existing code unchanged — 248 tools go in, only 5 relevant ones are sent
response = client.chat.completions.create(
model="gpt-4o",
tools=all_248_tools,
messages=messages,
)也通过 patch_anthropic 支持 Anthropic。请参阅 中间件指南。
两个问题：(1) 当只给出检索到的子集时，LLM 是否仍能选择正确的工具？(2) 检索器本身是否将正确的工具排在 Top K 中？
数据集 | 工具数 | 基准准确率 | graph-tool-call | Token 减少 |
Petstore | 19 | 100% | 95% (k=5) | 64% |
GitHub | 50 | 100% | 88% (k=5) | 88% |
混合 MCP | 38 | 97% | 90% (k=5) | 83% |
Kubernetes core/v1 | 248 | 12% | 82% (k=5 + 本体) | 79% |
关键发现 — 在 248 个工具时，基准测试崩溃（上下文溢出）至 12%，而 graph-tool-call 恢复至 82%。在较小规模下，基准测试已经很强，因此 graph-tool-call 的价值在于在不损失准确率的情况下节省 Token。
→ 完整结果（流水线 / 仅检索 / 竞争性 / 1068 规模 / 200 工具 LangChain 智能体，涵盖 GPT 和 Claude）：docs/benchmarks.md
# Reproduce
python -m benchmarks.run_benchmark # retrieval only
python -m benchmarks.run_benchmark --mode pipeline -m qwen3:4b # full pipeline在 BM25 + 图的基础上添加语义搜索。无需繁重的依赖 — 连接到任何外部嵌入服务器。
tg.enable_embedding("ollama/qwen3-embedding:0.6b") # Ollama (recommended)
tg.enable_embedding("openai/text-embedding-3-large") # OpenAI
tg.enable_embedding("vllm/Qwen/Qwen3-Embedding-0.6B") # vLLM
tg.enable_embedding("sentence-transformers/all-MiniLM-L6-v2") # local
tg.enable_embedding(lambda texts: my_embed_fn(texts)) # custom callable权重会自动重新平衡。请参阅 API 参考 获取所有提供商格式。
tg.enable_reranker() # cross-encoder rerank
tg.enable_diversity(lambda_=0.7) # MMR diversity
tg.set_weights(keyword=0.2, graph=0.5, embedding=0.3, annotation=0.2)传递之前调用的工具以降低其权重，并提升下一步候选工具的权重。
tools = tg.retrieve("now cancel it", history=["listOrders", "getOrder"])
# → [cancelOrder, processRefund, ...]tg.save("my_graph.json")
tg = ToolGraph.load("my_graph.json")
# Or use cache= in from_url() for automatic save/load
tg = ToolGraph.from_url(url, cache="my_graph.json")tg.auto_organize(llm="ollama/qwen2.5:7b")
tg.auto_organize(llm="litellm/claude-sonnet-4-20250514")
tg.auto_organize(llm=openai.OpenAI())构建更丰富的类别、关系和搜索关键词。支持 Ollama、OpenAI 客户端、litellm 和任何可调用对象。请参阅 API 参考。
功能 | API | 文档 |
跨规范重复检测 |
| |
冲突检测 |
| |
操作分析 |
| |
交互式仪表盘 |
| |
HTML / GraphML / Cypher 导出 |
| |
自动修复错误的 OpenAPI 规范 |
|
文档 | 描述 |
所有 | |
| |
MCP 服务器 / 代理、LangChain、中间件、直接 API | |
完整流水线 / 检索 / 竞争性 / 规模表格 | |
系统概览、流水线层、数据模型 | |
算法设计 — 规范化、依赖检测、本体 | |
竞争分析、API 规模数据 | |
发布流程、变更日志流程 |
欢迎贡献。
git clone https://github.com/SonAIengine/graph-tool-call.git
cd graph-tool-call
pip install poetry pre-commit
poetry install --with dev --all-extras
pre-commit install # auto-runs ruff on every commit
# Test, lint, benchmark
poetry run pytest -v
poetry run ruff check . && poetry run ruff format --check .
python -m benchmarks.run_benchmark -vExecute an OpenAPI tool via HTTP.
Sends the actual HTTP request based on the tool's method and path
from the OpenAPI spec. Use after search_tools() + get_tool_schema()
to call the API.
Args:
tool_name: Exact tool name (as returned by search_tools)
arguments: JSON string of parameter values (e.g. '{"owner":"me","repo":"test"}')
base_url: API base URL (e.g. https://api.github.com). Required if not inferrable.
auth_token: Bearer token for authentication (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| base_url | No | ||
| arguments | Yes | ||
| tool_name | Yes | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it sends an HTTP request and mentions the auth_token is a Bearer token, which is useful. However, it does not warn that the operation may be destructive or non-idempotent, nor does it mention error handling, side effects, or the dependence of the HTTP method on the specific tool being executed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence purpose, followed by usage context and a structured argument list. It is concise enough but slightly longer than necessary; the Arg list is justified given the need to explain parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description needn't detail return values. It covers enough for an agent to know when to use the tool, how to sequence it, and what each parameter means. It lacks details about error conditions or authentication caveats, but those are not critical given the output schema and the tool's straightforward role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully with an 'Args' block explaining each parameter, including expected format ('JSON string'), examples, and defaults (e.g., 'base_url' required if not inferrable). This adds meaning well beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute an OpenAPI tool via HTTP' and 'Sends the actual HTTP request based on the tool's method and path from the OpenAPI spec,' specifying the exact verb, resource, and mechanism. It distinguishes from siblings like search_tools and get_tool_schema by positioning this as the actual API-calling step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use after search_tools() + get_tool_schema() to call the API,' giving a clear usage sequence. While it does not enumerate alternatives nor explicitly say when not to use, the context of sibling tools and the provided sequence sufficiently imply the appropriate conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full schema of a specific tool by name.
Use this after search_tools() to get complete parameter details
for a tool you want to call.
Args:
name: Exact tool name (as returned by search_tools)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It doesn't disclose side effects, permissions, or error behavior, but as a read-only getter, the risk is low. It adds no extra behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a summary, usage note, and args. Every sentence is useful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and an output schema exists. The description covers when to use and the parameter. It could mention error cases, but it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section adds essential meaning: the name must be exact and as returned by search_tools. This clarifies the parameter beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full schema of a specific tool by name' with a specific verb and resource. It distinguishes from sibling tools like search_tools and execute_tool by focusing on schema retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this after search_tools() and before calling a tool, providing clear context on when to use. It doesn't mention exclusions or alternatives, but the sequencing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show summary statistics about the loaded tool graph.
Returns tool count, node count, edge count, and category breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states that the tool returns summary statistics (tool count, node count, edge count, category breakdown) and uses the verb 'Show', implying a non-destructive, read-only operation. While it doesn't explicitly guarantee no side effects, the description is transparent enough for a simple info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately state the purpose and the returned statistics. There is no wasted wording, and the structure is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description is nearly complete. It explicitly lists the key statistics returned, which is more than necessary. The only gap is the lack of explicit guidance on when to use this tool relative to siblings, but this is minor for a straightforward info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). The description adds no parameter-specific information, but none is needed. Baseline for zero parameters is 4, and the description appropriately focuses on the output rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and resource ('summary statistics about the loaded tool graph'), clearly stating the tool's purpose. It distinguishes itself from sibling tools such as search_tools and list_categories by focusing on graph-level statistics, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining an overview of the tool graph, but it does not explicitly state when to use this tool versus alternatives like search_tools or list_categories. No exclusions or alternative recommendations are provided, leaving the context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tool categories in the graph.
Returns categories with their tool counts, useful for understanding the available tool landscape before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description implies a read-only operation by saying 'List' and 'Returns categories with their tool counts,' but it does not explicitly state that it causes no side effects or requires no special permissions. Since this is a simple listing tool, the lack of explicit safety language is acceptable but leaves room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action ('List all tool categories in the graph'), and adds only relevant additional detail about return values and use case. Every word earns its place—no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema also exists, so the description does not need to detail return structures. The description explains what is returned (categories with tool counts), why it is useful (understanding the tool landscape), and when to use it (before searching). This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is an empty object with 100% schema description coverage. Since there are no parameters to explain, the description does not need to add parameter semantics. The baseline for no parameters is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all tool categories in the graph.' The verb 'List' is specific, the resource is 'tool categories in the graph,' and the scope is explicit. It also distinguishes itself from siblings like search_tools by positioning categories as an overview tool before searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'useful for understanding the available tool landscape before searching.' This implies using it as a precursor to search_tools, but it does not explicitly mention when not to use it or name alternative tools directly. Still, the usage context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load additional tools from an OpenAPI spec URL or file path.
Supports:
- Direct spec URLs (JSON/YAML): https://api.example.com/openapi.json
- Swagger UI URLs: https://api.example.com/swagger-ui/index.html
- Local file paths: ./openapi.json, /path/to/spec.yaml
Args:
source: OpenAPI spec URL or local file path
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions supported formats but omits critical details: side effects (e.g., modifies available tools), error behavior, reversibility, or whether loading is cumulative. The description lacks sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. It lists examples efficiently, though structuring them as a bullet list would improve readability. Nearly every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are not needed in the description. However, the description lacks information about error handling, state changes, or the significance of loading tools, leaving gaps for a tool that modifies the environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by listing example formats (URLs, local paths) for the 'source' parameter. However, it does not specify input validation rules or required formatting beyond examples, limiting its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Load additional tools from an OpenAPI spec URL or file path.' It identifies the specific verb ('load') and resource ('tools from a spec'), and distinguishes from sibling tools which focus on execution, schema retrieval, or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like get_tool_schema or search_tools. No context on prerequisites or typical scenarios is given, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for relevant tools by natural language query.
Returns the most relevant tools for the given query, ranked by
graph-based hybrid retrieval (BM25 + graph traversal + embedding).
Previously called tools are automatically deprioritized to surface
new candidates on repeated searches.
Args:
query: Natural language description of what you want to do.
Examples: "user authentication", "delete a file",
"manage shopping cart items"
top_k: Maximum number of tools to return per page (default: 5)
page: 1-based page for browsing beyond the first results. The
response carries ``page`` and ``has_more`` so you can decide
whether to request the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description comprehensively discloses behavioral traits: the hybrid retrieval method (BM25 + graph traversal + embedding), deprioritization of seen tools, and pagination behavior with page/has_more fields. This fully compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args section and front-loaded purpose statement. It covers necessary details without excessive verbosity, though some sentences could be slightly trimmed for even greater conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists, no annotations), the description covers retrieval method, pagination, and repetition management comprehensively. All aspects needed for correct invocation are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description takes full responsibility for explaining parameters. It provides clear explanations for 'query' (with examples), 'top_k' (with default), and 'page' (with pagination context). This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Search for relevant tools by natural language query.' It clearly identifies the action (search) and resource (tools), and distinguishes itself from the sibling tool 'load_source' by its focus on discovery rather than loading a specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (natural language queries) and includes helpful details about automatic deprioritization of previously used tools and pagination. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.37.0execute_toolget_tool_schemagraph_infolist_categoriesv0.28.0execute_toolget_tool_schemagraph_infolist_categoriessearch_tools1 field changedInput schema / properties / pageAdded value: +{
+ "default": 1,
+ "title": "Page",
+ "type": "integer"
+}v0.20.0execute_toolget_tool_schemagraph_infolist_categoriesload_sourcesearch_toolsv0.8.0execute_toolget_tool_schemagraph_infolist_categoriesload_sourcesearch_toolsv0.13.1execute_toolget_tool_schemagraph_infolist_categoriesload_sourcesearch_toolsEach tool serves a distinct role: search_tools for discovery, get_tool_schema for inspection, list_categories and graph_info for overview, execute_tool for execution, and load_source for ingestion. No two tools overlap in functionality, making selection unambiguous.
Most tool names follow a consistent verb_noun snake_case pattern (search_tools, get_tool_schema, list_categories, execute_tool, load_source). The sole deviation is graph_info, which uses noun_noun instead of verb_noun, but it remains clear and stylistically consistent.
With 6 tools, the set is well-scoped for a tool-graph management server. Each tool supports a distinct step in the workflow (load, discover, inspect, execute, overview), and there is no bloat or sense of missing essentials.
The core workflow is complete: load_source brings in new tools, search_tools discovers them, get_tool_schema inspects them, and execute_tool runs them. list_categories and graph_info provide useful overview. The only minor gap is the absence of a direct 'list all tools' function, but search_tools with a broad query can cover that.
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
LLM Orchestration Agent (Mcp)
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SonAIengine/graph-tool-call'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
