LLM 에이전트는 수천 개의 도구 정의를 컨텍스트에 모두 담을 수 없습니다. 벡터 검색은 유사한 도구를 찾지만, 해당 도구가 속한 워크플로우는 놓칩니다. graph-tool-call은 도구 그래프를 구축하고 단순한 일치 항목이 아닌 올바른 체인을 검색합니다.
검색 없음 | graph-tool-call | |
248개 도구 (K8s API) | 12% 정확도 | 82% 정확도 |
1068개 도구 (GitHub 전체 API) | 컨텍스트 오버플로우 | 78% Recall@5 |
토큰 사용량 | 8,192 토큰 | 1,699 토큰 (79% ↓) |
qwen3:4b (4-bit)로 측정됨 — 전체 벤치마크
LLM 에이전트에게는 도구가 필요합니다. 하지만 도구의 수가 증가함에 따라 두 가지 문제가 발생합니다:
컨텍스트 오버플로우 — 248개의 Kubernetes API 엔드포인트 = 8,192 토큰의 도구 정의. LLM이 과부하를 일으키고 정확도가 **12%**로 떨어집니다.
벡터 검색은 워크플로우를 놓침 — *"주문 취소"*를 검색하면 cancelOrder를 찾지만, 실제 흐름은 listOrders → getOrder → cancelOrder → processRefund입니다. 벡터 검색은 하나의 도구만 반환하지만, 실제로는 체인이 필요합니다.
graph-tool-call은 이 두 가지를 모두 해결합니다. 도구 관계를 그래프로 모델링하고, 하이브리드 검색(BM25 + 그래프 탐색 + 임베딩 + MCP 주석)을 통해 다단계 워크플로우를 검색하며, 정확도를 유지하거나 향상시키면서 토큰 사용량을 64~91% 절감합니다.
시나리오 | 벡터 전용 | 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은 여러 통합 패턴을 제공합니다. 스택에 맞는 것을 선택하세요:
사용 중인 도구... | 패턴 | 토큰 절감 | 가이드 |
Claude Code / Cursor / Windsurf | MCP 프록시 (N개의 MCP 서버 통합 → 3개의 메타 도구) | ~1,200 토큰/턴 | |
모든 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개의 도구를 모두 바인딩하는 것 대비 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) 검색기 자체가 올바른 도구를 상위 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, 미들웨어, 직접 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
