This server enables tool discovery and execution by building a graph-based index of API tools, allowing you to efficiently find and call the right tools.
Search for tools (search_tools): Find relevant tools using natural language queries with hybrid retrieval (BM25 + graph traversal + embedding); supports pagination (top_k, page) and deprioritizes previously called tools.
Get tool schema (get_tool_schema): Retrieve the full parameter/schema details for a specific tool by name, typically used after searching to prepare for execution.
List categories (list_categories): Browse all tool categories in the loaded graph along with their tool counts.
View graph info (graph_info): Get summary statistics about the tool graph, including tool count, node/edge counts, and category breakdowns.
Execute tools (execute_tool): Send real HTTP requests to OpenAPI-defined endpoints by providing the tool name, arguments (as a JSON string), a base URL, and an optional auth token.
Load additional sources (load_source): Dynamically add more tools from OpenAPI spec URLs (JSON/YAML), Swagger UI pages, or local file paths to expand the tool graph at runtime.
Supports ingesting GitHub API tool definitions to manage complex workflows and reduce context usage in repository and issue management scenarios.
Ingests Kubernetes API definitions to build a tool graph, enabling high-accuracy tool retrieval and significant token reduction for complex K8s management tasks.
Provides a dedicated integration for LangChain, allowing developers to incorporate tool graph retrieval and workflow guidance into LangChain-based agents.
Integrates with Ollama to provide semantic embedding similarity for tool retrieval, enabling cross-language and semantic search capabilities.
Connects to OpenAI for semantic embedding search and supports ingesting OpenAI-compliant tool definitions to facilitate workflow-aware tool selection.
Automatically ingests tool definitions from Swagger and OpenAPI specifications to construct relationships and suggest multi-step execution workflows.
Supports parsing and ingesting tool definitions from YAML-based OpenAPI specifications to build the internal tool graph.
Graph-structured retrieval for large LLM tool catalogs.
Find the target tool, the prerequisite tools that produce its inputs, and the smallest schema bundle that fits the planner's token budget.
Documentation · Quickstart · PyPI · Benchmarks
English · 한국어
A semantic search for "refund an order" can find refundOrder. That is not
enough when the operation requires an order_id that the user does not have.
A usable candidate set also needs the operation that produces that field:
findOrdersByEmail(email) -> order_id -> refundOrder(order_id)Large catalogs create a second problem: sending every schema to the model wastes context and can lower selection quality. graph-tool-call treats retrieval as a contract-aware graph problem instead of flat similarity search.
It provides:
deterministic ingestion from OpenAPI, GraphQL introspection, MCP tools, Python functions, and structured tool catalogs;
hybrid target retrieval with keyword, graph, optional embedding, and MCP annotation signals;
evidence-backed target selection and typed prerequisite expansion;
token-budgeted, contract-projected schemas for the model-facing catalog;
readiness, failure, and trace metadata for application-side diagnostics;
adapters for OpenAI, Anthropic, LangChain v1, MCP, Docker, and Kubernetes.
Authentication, tenant policy, approval, and product-specific execution remain in the host application.
Related MCP server: nexus-mcp-ci
No model, API key, or network call is required:
uvx graph-tool-call demo dependency-chainSelected target:
refundOrder(order_id)
Required producer:
findOrdersByEmail(email) -> order_id
evidence: api_contract, openapi_link
Execution order:
1. findOrdersByEmail
2. refundOrder
Planner context:
6 catalog tools -> 2 required tools
estimated tokens: 1476 -> 160 (89% fewer)This demo runs the real retriever, deterministic target selector, typed dependency closure, and schema admission pipeline.
The core search and graph package uses only the Python standard library. Optional integrations are installed explicitly:
pip install graph-tool-call
pip install "graph-tool-call[openapi]" # YAML OpenAPI documents
pip install "graph-tool-call[korean]" # Kiwi tokenizer
pip install "graph-tool-call[langchain]" # LangChain v1 middleware
pip install "graph-tool-call[mcp]" # MCP server and proxy
pip install "graph-tool-call[all]" # all optional featuresPython 3.10 through 3.14 are tested in CI.
from graph_tool_call import ToolGraph
graph = ToolGraph.from_url(
"https://petstore3.swagger.io/api/v3/openapi.json",
cache="petstore.graph.json",
)
for result in graph.retrieve_with_scores("create a new pet", top_k=5):
print(result.tool.name, result.score, result.confidence)OpenAPI ingestion preserves request and response schemas, parameter locations,
content types, security requirements, links, examples, response envelopes, and
typed consumes/produces contracts. Swagger 2.0, OpenAPI 3.0, and OpenAPI 3.1
are supported.
Inspect a collection before exposing it to an agent:
graph-tool-call inspect-openapi ./openapi.json --json
graph-tool-call build-openapi-collection ./openapi.json -o collection.jsonThe report contains stable readiness issue codes, semantic coverage, and edge quality rather than a single opaque score.
from graph_tool_call.ingest import ingest_source
openapi_result = ingest_source(openapi_document)
graphql_result = ingest_source(introspection_result)
mcp_result = ingest_source({"tools": mcp_tools}, format_hint="mcp-tools")
python_result = ingest_source([read_file, write_file])Every adapter returns normalized ToolSchema objects, capability metadata, and
structured unsupported-feature diagnostics.
Environment | Recommended surface | What graph-tool-call owns |
Python application |
| ingest, search, evidence, dependency closure |
OpenAI Responses or Chat Completions |
| per-request function-tool filtering |
Anthropic Messages |
| per-request tool filtering |
LangChain v1 |
| model-call tool selection |
Claude Code, Cursor, Windsurf | MCP proxy | many MCP backends behind 3 gateway tools |
OpenAI Agents, PydanticAI, Google ADK | remote MCP server | protocol-neutral search service |
Docker or Kubernetes | Streamable HTTP MCP | private deployable service |
See the compatibility matrix for validation boundaries. Protocol compatibility does not imply that every framework or cloud release is tested by this repository.
from graph_tool_call.middleware import patch_openai
patch_openai(client, graph=graph, top_k=5)
response = client.responses.create(
model=model_name,
input="delete a user account",
tools=all_function_tools,
)Hosted tools such as web search pass through unchanged. The same patch keeps legacy Chat Completions support.
from langchain.agents import create_agent
from graph_tool_call.langchain import create_tool_selection_middleware
selection = create_tool_selection_middleware(langchain_tools, top_k=5)
agent = create_agent(
model,
tools=langchain_tools,
middleware=[selection],
)The middleware intersects with tools still allowed by earlier permission or feature-flag middleware; it does not reintroduce filtered tools.
graph-tool-call ingest ./openapi.json -o graph.json
graph-tool-call serve \
--graph graph.json \
--transport streamable-http \
--host 127.0.0.1 \
--port 8000The MCP endpoint is /mcp; HTTP deployments also expose /healthz and
/readyz. Keep remote endpoints private or behind an authenticated gateway.
graph-tool-call proxy \
--config ./mcp-backends.json \
--transport streamable-httpThe proxy accepts local stdio, SSE, and Streamable HTTP backends. In gateway
mode it exposes search_tools, get_tool_schema, and call_backend_tool, then
notifies capable clients when matching backend tools become visible.
The release headline is deliberately model-free and small enough to replay in CI. On seven curated commerce cases, adding typed producer expansion to the same selected target produced:
Metric | Target only | Target + graph producers |
Required-producer recall | 14.3% | 100% |
Candidate plan coverage | 47.6% | 100% |
Candidate binding support | 14.3% | 100% |
Target Recall@5 | - | 100% |
The case-level v0.46.0 artifact records fixture hashes, every expected target and producer, and replay commands:
make launch-evidence
make launch-evidence-checkThe separate
observability artifact
checks that tracing leaves engine inputs unchanged, replays deterministically,
scrubs secrets, explains every decision, and stays below the documented
5ms/span p95 capture-cost gate:
make observability-evidence-checkThis is an engine regression suite, not a population-level estimate of LLM tool-calling accuracy and not a state-of-the-art claim. Larger external comparisons, model-loop experiments, confidence intervals, and known weak cases are reported in Benchmark Results and the paper protocol.
graph-tool-call is the retrieval and contract layer. A production adapter still owns:
user and service authentication;
tenant authorization and approval policy;
downstream secrets and cookie handling;
side-effect confirmation, cleanup, and audit retention;
provider/model lifecycle and final response policy.
Do not store raw credentials in graph artifacts, tool descriptions, trace records, or model-visible arguments.
Start here | Purpose |
first search, graph, readiness, and execution loop | |
understand the pipeline and boundaries | |
contract extraction and collection build | |
ranking evidence and deterministic guard | |
frameworks, MCP, and deployment | |
stable public Python surface | |
current product and research priorities |
git clone https://github.com/SonAIengine/graph-tool-call.git
cd graph-tool-call
poetry install --with dev --all-extras
poetry run ruff check .
poetry run ruff format --check .
poetry run pytest tests/ -qSee CONTRIBUTING.md and the release checklist.
Execute 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
