LLMエージェントは数千ものツール定義をコンテキストに収めることができません。 ベクトル検索は類似したツールを見つけますが、それらが属するワークフローを見逃してしまいます。 graph-tool-callはツールグラフを構築し、単なる一致ではなく、適切なチェーンを検索します。
検索なし | graph-tool-call | |
248ツール (K8s API) | 精度 12% | 精度 82% |
1068ツール (GitHubフルAPI) | コンテキストオーバーフロー | Recall@5 78% |
トークン使用量 | 8,192 tok | 1,699 tok (79% ↓) |
qwen3:4b (4-bit) で測定 — 完全なベンチマーク
LLMエージェントにはツールが必要です。しかし、ツールの数が増えるにつれて、2つの問題が発生します。
コンテキストオーバーフロー — 248個のKubernetes APIエンドポイント = 8,192トークンのツール定義。LLMは処理しきれず、精度は**12%**まで低下します。
ベクトル検索はワークフローを見逃す — 「注文をキャンセルして」と検索すると cancelOrder が見つかりますが、実際のフローは listOrders → getOrder → cancelOrder → processRefund です。ベクトル検索は1つのツールしか返しませんが、必要なのはチェーン全体です。
graph-tool-callはこれら両方を解決します。ツール間の関係をグラフとしてモデル化し、ハイブリッド検索（BM25 + グラフ探索 + 埋め込み + MCPアノテーション）を通じてマルチステップのワークフローを検索し、精度を維持または向上させながらトークン使用量を64〜91%削減します。
シナリオ | ベクトルのみ | graph-tool-call |
「注文をキャンセルして」 |
|
|
「ファイルを読み込んで保存して」 |
|
|
「古いレコードを削除して」 | 「削除」に一致するツールを返す | 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) を通じて4つのシグナルを組み合わせます：
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はいくつかの統合パターンを提供しています。スタックに合ったものを選んでください：
使用環境 | パターン | トークン削減効果 | ガイド |
Claude Code / Cursor / Windsurf | MCPプロキシ (N個のMCPサーバーを3つのメタツールに集約) | ~1,200 tok/turn | |
MCP互換クライアント | MCPサーバー (単一ソースをMCPとして) | 可変 | |
LangChain / LangGraph (50+ツール) | ゲートウェイツール (N個のツールを2つのメタツールに) | 92% | |
OpenAI / Anthropic SDK (既存コード) | ミドルウェア (1行のモンキーパッチ) | 76–91% | |
検索の直接制御 | Python API ( | 可変 |
多くのMCPサーバーがある場合、ツール名がすべてのLLMターンで蓄積されます。それらを1つのサーバーの背後にバンドルします：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個すべてのツールをバインドする場合と比較して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でも動作します。詳細はミドルウェアガイドを参照してください。
2つの疑問：(1) 検索されたサブセットのみを与えられた場合でも、LLMは正しいツールを選択できるか？ (2) 検索エンジン自体が正しいツールを上位K件にランク付けできるか？
データセット | ツール数 | ベースライン精度 | graph-tool-call | トークン削減率 |
Petstore | 19 | 100% | 95% (k=5) | 64% |
GitHub | 50 | 100% | 88% (k=5) | 88% |
Mixed 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の価値は精度を損なわないトークン節約にあります。
→ 完全な結果（パイプライン / 検索のみ / 競合比較 / 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 pipelineBM25 + グラフの上にセマンティック検索を追加します。重い依存関係は不要で、外部の埋め込みサーバーに接続するだけです。
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、ミドルウェア、Direct 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.
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
