Los agentes LLM no pueden incluir miles de definiciones de herramientas en su contexto. La búsqueda vectorial encuentra herramientas similares, pero pierde el flujo de trabajo al que pertenecen. graph-tool-call construye un grafo de herramientas y recupera la cadena correcta, no solo una coincidencia.
Sin recuperación | graph-tool-call | |
248 herramientas (API K8s) | 12% precisión | 82% precisión |
1068 herramientas (API completa de GitHub) | desbordamiento de contexto | 78% Recall@5 |
Uso de tokens | 8,192 tok | 1,699 tok (79% ↓) |
Medido con qwen3:4b (4-bit) — benchmark completo
Los agentes LLM necesitan herramientas. Pero a medida que aumenta el número de herramientas, dos cosas fallan:
Desbordamiento de contexto — 248 endpoints de la API de Kubernetes = 8,192 tokens de definiciones de herramientas. El LLM se bloquea y la precisión cae al 12%.
La búsqueda vectorial pierde los flujos de trabajo — Buscar "cancelar mi pedido" encuentra cancelOrder, pero el flujo real es listOrders → getOrder → cancelOrder → processRefund. La búsqueda vectorial devuelve una herramienta; tú necesitas la cadena.
graph-tool-call resuelve ambos problemas. Modela las relaciones de las herramientas como un grafo, recupera flujos de trabajo de varios pasos mediante búsqueda híbrida (BM25 + recorrido de grafos + embedding + anotaciones MCP) y reduce el uso de tokens entre un 64% y un 91% mientras mantiene o mejora la precisión.
Escenario | Solo vectorial | graph-tool-call |
"cancelar mi pedido" | Devuelve |
|
"leer y guardar archivo" | Devuelve |
|
"eliminar registros antiguos" | Devuelve cualquier herramienta que coincida con "delete" | Herramientas destructivas clasificadas primero mediante anotaciones MCP |
"ahora cancélalo" (después de listar pedidos) | Sin contexto del historial | Desprioriza herramientas usadas, impulsa herramientas del siguiente paso |
Múltiples especificaciones Swagger con herramientas superpuestas | Herramientas duplicadas en los resultados | Deduplicación automática entre fuentes |
1,200 endpoints de API | Lento, resultados ruidosos | Categorizado + recorrido de grafos para una recuperación precisa |
Related MCP server: nexus-mcp-ci
OpenAPI / MCP / Python functions → Ingest → Build tool graph → Hybrid retrieve → AgentEjemplo — El usuario dice "cancela mi pedido y procesa un reembolso"
La búsqueda vectorial encuentra cancelOrder. Pero el flujo de trabajo real es:
┌──────────┐
PRECEDES │listOrders│ PRECEDES
┌─────────┤ ├──────────┐
▼ └──────────┘ ▼
┌──────────┐ ┌───────────┐
│ getOrder │ │cancelOrder│
└──────────┘ └─────┬─────┘
│ COMPLEMENTARY
▼
┌──────────────┐
│processRefund │
└──────────────┘graph-tool-call devuelve toda la cadena, no solo una herramienta. La recuperación combina cuatro señales mediante Reciprocal Rank Fusion (wRRF) ponderado:
BM25 — coincidencia de palabras clave
Recorrido de grafos — expansión basada en relaciones (PRECEDES, REQUIRES, COMPLEMENTARY)
Similitud de embedding — búsqueda semántica (opcional, cualquier proveedor)
Anotaciones MCP — sugerencias de solo lectura / destructivas / idempotentes
El paquete principal tiene cero dependencias — solo la biblioteca estándar de Python. Instala solo lo que necesites:
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] # everythingExtra | Instala | Cuándo usar |
| pyyaml | Especificaciones YAML OpenAPI |
| numpy | Búsqueda semántica (conectar a Ollama/OpenAI/vLLM) |
| numpy, sentence-transformers | Modelos locales de sentence-transformers |
| rapidfuzz | Detección de duplicados |
| langchain-core | Integración con LangChain |
| pyvis, networkx | Exportación de grafo HTML, GraphML |
| dash, dash-cytoscape | Panel interactivo |
| ai-api-lint | Corrección automática de malas especificaciones API |
| mcp | Modo servidor / proxy 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() devuelve cadenas de ejecución ordenadas con requisitos previos, reduciendo los viajes de ida y vuelta del agente de 3-4 a 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")Edita, parametriza y visualiza flujos de trabajo: consulta la guía de la API directa.
# 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])Las anotaciones MCP (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) se utilizan como señales de recuperación: la intención de la consulta se clasifica automáticamente, y las consultas de lectura priorizan las herramientas de solo lectura, mientras que las consultas de eliminación priorizan las herramientas destructivas.
graph-tool-call incluye varios patrones de integración. Elige el que coincida con tu stack:
Estás usando... | Patrón | Ganancia en tokens | Guía |
Claude Code / Cursor / Windsurf | Proxy MCP (agrega N servidores MCP → 3 meta-herramientas) | ~1,200 tok/turno | |
Cualquier cliente compatible con MCP | Servidor MCP (fuente única como MCP) | varía | |
LangChain / LangGraph (más de 50 herramientas) | Herramientas Gateway (N herramientas → 2 meta-herramientas) | 92% | |
SDK de OpenAI / Anthropic (código existente) | Middleware (monkey-patch de 1 línea) | 76–91% | |
Control directo sobre la recuperación | API de Python ( | varía |
Cuando tienes muchos servidores MCP, sus nombres de herramientas se acumulan en cada turno del LLM. Agrúpalos detrás de un servidor: 172 herramientas → 3 meta-herramientas.
# 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.jsonConfiguración completa, modo passthrough, transporte remoto → Guía de Proxy 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)Reducción del 92% de tokens frente a vincular las 62 herramientas. Consulta la guía de LangChain para patrones de filtrado automático y manual.
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,
)También funciona con Anthropic mediante patch_anthropic. Consulta la guía de Middleware.
Dos preguntas: (1) ¿El LLM sigue eligiendo la herramienta correcta cuando solo se le da el subconjunto recuperado? (2) ¿El recuperador clasifica las herramientas correctas en el top K?
Dataset | Herramientas | Precisión base | graph-tool-call | Reducción de tokens |
Petstore | 19 | 100% | 95% (k=5) | 64% |
GitHub | 50 | 100% | 88% (k=5) | 88% |
MCP mixto | 38 | 97% | 90% (k=5) | 83% |
Kubernetes core/v1 | 248 | 12% | 82% (k=5 + ontología) | 79% |
Hallazgo clave — con 248 herramientas, la base colapsa (desbordamiento de contexto) al 12%, mientras que graph-tool-call se recupera al 82%. A escalas más pequeñas, la base ya es sólida, por lo que el valor de graph-tool-call es el ahorro de tokens sin pérdida de precisión.
→ Resultados completos (pipeline / solo recuperación / competitivo / escala 1068 / agente LangChain de 200 herramientas en GPT y Claude): docs/benchmarks.md
# Reproduce
python -m benchmarks.run_benchmark # retrieval only
python -m benchmarks.run_benchmark --mode pipeline -m qwen3:4b # full pipelineAñade búsqueda semántica sobre BM25 + grafo. No se necesitan dependencias pesadas: conéctate a cualquier servidor de embedding externo.
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 callableLos pesos se reequilibran automáticamente. Consulta la referencia de la API para todas las formas de proveedores.
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)Pasa las herramientas llamadas anteriormente para despriorizarlas e impulsar los candidatos del siguiente paso.
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())Construye categorías, relaciones y palabras clave de búsqueda más ricas. Soporta Ollama, clientes OpenAI, litellm y cualquier invocable. Consulta la referencia de la API.
Característica | API | Docs |
Detección de duplicados entre especificaciones |
| |
Detección de conflictos |
| |
Análisis operativo |
| |
Panel interactivo |
| |
Exportación HTML / GraphML / Cypher |
| |
Corrección automática de malas especificaciones OpenAPI |
|
Doc | Descripción |
Todos los comandos CLI de | |
Métodos | |
Servidor / proxy MCP, LangChain, middleware, API directa | |
Tablas completas de pipeline / recuperación / competitivo / escala | |
Resumen del sistema, capas de pipeline, modelo de datos | |
Diseño de algoritmos: normalización, detección de dependencias, ontología | |
Análisis competitivo, datos de escala de API | |
Proceso de lanzamiento, flujo de changelog |
Las contribuciones son bienvenidas.
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
