grafeo-mcp

Official

by GrafeoDB

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose, from CRUD operations to various search methods and graph algorithms. Descriptions explicitly state when to use each and when not to, eliminating ambiguity.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern (e.g., create_node, delete_edge, search_text). No mixing of case styles or inconsistent conventions.
Tool Count4/5
23 tools is comprehensive for a graph database server, covering CRUD, indexing, search, analytics, and import. Slightly on the higher side but well-scoped for the domain.
Completeness5/5
The tool set covers the full lifecycle: CRUD for nodes and edges, multiple index types, diverse search methods, graph algorithms, batch import, and custom GQL queries. No obvious gaps.
Average 4.7/5 across 23 of 23 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available, and the description does not cover side effects, authorization, or irreversibility. As a destructive operation, more transparency about consequences would be beneficial. The output schema exists but is not discussed in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with no wasted words. Includes args section and example. Structure is front-loaded with purpose and usage, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers input, usage, and return values. However, lacks mention of destructive nature (irreversible) given no annotations. Still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only states 'edge_id: The ID of the edge to delete.' While this adds some meaning, it is minimal. Could include format or source of edge_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Delete an edge from the graph,' clearly identifying the verb (delete) and resource (edge). It distinguishes from siblings like create_edge, update_edge, and delete_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('need to remove a relationship') and when-not-to-use, referencing specific alternatives (delete_node, update_edge). This helps agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes return format but lacks details on idempotency, validation, or side effects (e.g., what happens if node already exists). The examples and return info are helpful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (when to use, args, returns, examples). However, it could be slightly more concise; the two-line examples are useful but verbose. No wasted sentences overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has output schema (not shown but present), the description adequately covers purpose, parameters, and usage. It does not mention error handling or edge cases, but given low complexity (2 params, 1 required), it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries full burden. It explains labels as string array and properties as optional key-value object, with examples showing usage and optionality (null for no properties). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Create a new node in the graph'. It distinguishes this tool from siblings like create_edge and execute_gql by specifying it's for single entities only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('add a single new entity') and when not to ('bulk inserts' or 'creating relationships'), with alternative tools named (execute_gql, create_edge).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses indexing behavior for existing and future nodes, parameter effects, and return type. It could mention idempotency or side effects, but overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, usage, parameter list, returns, example. Every sentence adds value, and it is concise without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no annotations), the description is fairly complete. It includes an example call. It could elaborate on error cases or performance, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains every parameter with examples, defaults, and effects (e.g., '15 for OpenAI' for dimensions). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an HNSW vector index for fast similarity search. It specifies the usage context (call once before vector_search on a label+property pair) and distinguishes it from siblings like create_text_index and vector_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling this once before using vector_search. It provides clear context but does not explicitly mention when not to use or alternatives. The usage context is effective for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It details the return format (center node, list of neighbors, connecting edge info, counts) and explains parameter behavior (direction options, edge_type filtering, limit). However, it omits behaviors like error handling when the node_id is missing or a default limit of 50, but overall provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidelines, args, returns, examples). It is somewhat lengthy but every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no annotations, presence of an output schema) the description is sufficiently complete: it covers purpose, parameter semantics, usage boundaries, return format, and provides multiple examples. The absence of error behavior or rate limits is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all four parameters in the 'Args' section with intent, default values, and examples, adding significant meaning beyond the schema property titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Get neighboring nodes connected to a given node.' It prominently distinguishes itself from sibling tools like `search_nodes_by_label` and `execute_gql`, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use ('when you have a node ID and want to see what it connects to') and when-not-to-use ('finding nodes by property' or 'complex multi-hop queries'), with clear alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the tool returns database info, schema, and statistics, implying a read-only operation. Could be more explicit about idempotency, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and uses bullet points for the return section. A minor redundancy (the 'Returns:' line could be integrated) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description covers use cases, non-use cases, and return details comprehensively. No gaps for the intended purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; trivially 100% schema coverage. Description adds value by detailing the return structure (JSON with mode, node_count, edge_count, persistence, labels, edge_types, property_keys, statistics), helping the agent understand output beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Get an overview of the graph database: counts, labels, edge types, and schema,' and distinguishes from siblings by listing alternatives (get_node, search_nodes_by_label, execute_gql) for what not to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: 'when you need to understand what data is in the graph before writing queries, or to verify the database state after mutations,' and explicit when-not-to with sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the two-step process (vector search then expansion), defaults, and optional edge filtering. It mentions output truncation. However, it does not discuss potential performance implications or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, step-by-step explanation, and an example. It is moderately long but every sentence adds value, and the structure aids readability. Slightly verbose but justified for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, hybrid search) and the presence of an output schema, the description is complete. It explains the multi-step process, parameter defaults, return structure ('seeds' and 'neighbors'), and includes an example. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning: label must have a vector index, query_vector is a list of floats, expand_depth can be 0 to skip expansion. The example clarifies usage. Some parameters (property, k) are briefly described but could include more nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as hybrid search combining vector similarity and graph expansion. It explicitly distinguishes from sibling tools like vector_search and get_neighbors, making it easy for an AI agent to select the right tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'Use this tool when: you need both semantic relevance AND graph context. Use vector_search when: you only need the similar nodes themselves. Use get_neighbors when: you already have a node and want to explore around it.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the algorithm, output format (sorted JSON array with score, labels, properties), and error recovery advice. While it does not explicitly state it is read-only, it is implied and there are no contradictions with annotations (none provided). A slight improvement could be an explicit 'no side effects' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with purpose, but the long algorithmic line and Args block could be slightly more structured. Nonetheless, it is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and minimal schema, the description covers algorithm, parameters, output format, and error recovery, making it fully complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description compensates by explaining 'normalized' (normalization formula, default True) and 'top_k' (number of top-ranked nodes, default 20), providing essential meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes betweenness centrality using Brandes' algorithm, defines what it measures (bridge/bottleneck nodes), and distinguishes it from sibling tools like pagerank and louvain, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides 'Use this tool when' and 'Do NOT use this for' with concrete alternatives (pagerank, louvain), offering clear context for when to and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses undirected graph treatment, return format (num_components, components), and error condition (no edges). Lacks details on potential performance implications but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for description, usage, returns, and error recovery. Every sentence is necessary and informative; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema referenced, description fully explains behavior, use cases, and error handling. Provides sufficient context given sibling tools and zero parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline 4. Description adds value by explaining concept and return structure beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find connected components (treating the graph as undirected)' and distinguishes from sibling tool 'louvain' by explicitly stating not to use it for dense sub-communities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (e.g., 'want to know how many disconnected subgraphs exist') and when not to use (use louvain), along with error recovery guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains HNSW index usage, ef parameter trade-off, and return format. However, it doesn't mention error behavior (e.g., missing index) or performance nuances beyond ef, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, usage guidelines, args, returns, example). Every sentence adds value; no fluff. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema (context says true), the description covers functionality, prerequisites, parameters, return format, and example. Lacks only minor details like error conditions or ef formula, but overall strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters fully. It does so for all 5 parameters: label, property, query_vector, k (with default 10), and ef (with default None). Example call demonstrates usage pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Find the k nearest nodes by vector similarity (HNSW index).' It distinguishes from sibling tools like search_nodes_by_label (keyword search) and execute_gql (general queries), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you have an embedding vector and want semantically similar nodes'), when not to use ('Do NOT use for keyword or property search'), and even requires a prerequisite: vector index created via create_vector_index. Example call reinforces correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: nodes created first then edges, '@index' notation for referencing batch nodes, and non-atomic operation. With no annotations, these details are crucial. Could mention more about error handling, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections: purpose, usage guidelines, behavioral note, parameter details, return description, and example. Every sentence adds value; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, usage, behavior, parameters, return format, and example. Given the tool's complexity (bulk create with references and non-atomicity), the description is thorough and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents the internal structure of nodes and edges including required fields (labels, edge_type) and optional fields. Also explains the '@index' notation and provides an example, compensating completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bulk-create nodes and edges from JSON arrays in a single call.' It explicitly distinguishes itself from siblings by noting when to use create_node/create_edge for single entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this tool when' scenarios (loading datasets, building graphs) and 'Do NOT use for' cases (single node/edge, updates) with named alternative tools (create_node, create_edge, update_node, update_edge).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that edges are directed, requires existing nodes, and describes return format. Does not mention error handling or node existence validation, but provides sufficient behavioral context for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence for purpose, usage guidelines, then structured Args, Returns, and two examples. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage guidelines, parameters, and examples. It is complete for decision-making and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the Args section with type hints and examples (e.g., edge_type as 'KNOWS'). Schema has 0% description coverage, so description fully compensates and adds meaning beyond titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a directed edge (relationship) between two existing nodes', providing a specific verb and resource. It distinguishes from siblings by explicitly mentioning not to use for node creation (create_node) or querying (execute_gql).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use ('connect two nodes with a typed relationship') and when not to use, with specific alternative tools named (create_node, execute_gql).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions Cypher auto-normalization and the limit parameter. However, it does not detail error behavior, potential side effects of mutations, or authentication requirements. This is a minor gap, but overall good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (overview, usage guidelines, args, examples). Every sentence adds value; there is no redundancy. The length is justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (not requiring return value explanation), the description covers purpose, usage, parameters, and examples comprehensively. It is complete for an AI agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's 'Args' section provides comprehensive explanations for both parameters: query (with examples of GQL/Cypher syntax) and limit (purpose, default, and advice on also using LIMIT in the query). This adds significant meaning beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a GQL query against the graph database.' It elaborates on GQL, mentions Cypher normalization, and provides concrete examples. It distinguishes itself from sibling tools by specifying when to use this tool vs. CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines when to use the tool ('complex filters, multi-hop traversals, aggregations, or mutations beyond what the CRUD tools provide') and when not to use it ('simple node lookups', 'label browsing', 'one-hop exploration'). It references alternative tools, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return type (JSON with id, labels, properties or error/not-found message) and behavior for missing IDs. Lacks explicit mention of read-only nature, but implied. Minor gap for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, followed by return info, usage advice, arg details, and examples. Every sentence adds value; no redundancy. Well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with 1 param and no annotations, description adequately covers purpose, usage, return structure (with output schema present), and examples. All essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains the only parameter: 'node_id: The numeric node ID (e.g. 0, 1, 42).' Adds examples and clarifies it is numeric, going beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single node by its ID' and specifies it returns labels and properties or a not-found message. It distinguishes from sibling tools like search_nodes_by_label and execute_gql.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool when: you have a specific node ID and need its details' and 'Do NOT use this for: searching nodes by label or property (use search_nodes_by_label or execute_gql).' Provides clear when and when-not, with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses algorithm parameters, output truncation by token budget, and prerequisite (at least one edge). Does not explicitly state read-only nature, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, usage guidelines, args, returns, and error recovery sections. Each sentence earns its place; no redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given all optional parameters, presence of output schema, and no annotations, the description covers parameter semantics, return format, truncation, error recovery, and prerequisites. Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all four parameters (damping, max_iterations, tolerance, top_k) with defaults, behavior, and why top_k is needed. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run PageRank and return the top-k most important nodes', providing a specific verb and resource. It explains the algorithm's purpose (measuring node importance via link structure) and distinguishes from siblings like vector_search and dijkstra.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (finding important central nodes) and when-not-to-use (content similarity or shortest paths) with named alternatives. Also includes error recovery guidance on verifying graph non-emptiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses dependency on create_text_index, describes return format (JSON array sorted by relevance), but does not explicitly state that the tool is non-destructive (read-only). Annotations absent, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, prerequisites, usage guidance, parameter details, return description, and examples. Every sentence adds value; concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, output schema exists), the description covers prerequisites, usage, return format, and examples completely. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by detailing each parameter (label, property, query, limit) with context (e.g., 'Node label to search within') and examples, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Full-text keyword search over string properties' clearly stating the action and resource. It distinguishes from siblings like vector_search and search_nodes_by_label, providing specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('you want to search for nodes by keyword or phrase') and when not to use (vector_search, execute_gql, search_nodes_by_label), giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the merge behavior (merge vs replace), return structure, and that it updates existing properties. It could mention error handling or permissions, but it's sufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one purpose line, usage guidelines, Args, Returns, and Examples. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters, return shape, and usage examples. An output schema exists, but the description adds context. Given the tool's simplicity, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains all three parameters: edge_id, properties (key-value), merge (with default and behavior). Examples clarify usage beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Update properties on an existing edge,' using a specific verb and resource. It distinguishes itself from create_edge and delete_edge by stating what not to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('you need to modify an edge's properties after creation') and when not to (changing edge type, creating, deleting), naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that existing nodes are indexed immediately and future nodes are indexed on insertion, and mentions the return type (confirmation or error).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, args, returns, examples) but is slightly verbose. Every sentence adds value, but it could be trimmed slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and sparse schema, the description is remarkably complete. It covers purpose, behavior, parameter semantics, usage context, return type, and examples, making it fully sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description provides detailed parameter explanations (e.g., 'Node label to index') and concrete examples (e.g., 'Article', 'title'). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'full-text search index' on a string property. It distinguishes from sibling tool 'create_vector_index' by explicitly contrasting vector/embedding search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'call this once before using search_text' and provides clear 'Use this tool when' and 'Do NOT use for' guidance, including an alternative (create_vector_index).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns distance and path, error if unreachable, weight_property defaults to 1.0. Includes error recovery steps, leaving little ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, usage guidelines, and parameter details. Minor redundancy in repeating parameter info that could be inferred from schema, but justified due to lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers algorithm, parameters, return format, error handling, and sibling differentiation. Provides enough context for correct agent invocation even without annotations or output schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all three parameters: source_id (starting node), target_id (destination), weight_property (edge property, optional, default 1.0). Also describes return structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the shortest weighted path between two nodes using Dijkstra's algorithm. It distinguishes from sibling tools like pagerank and vector_search, specifying the exact algorithm and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (shortest/cheapest path between known nodes) and when not to (use pagerank for important nodes, vector_search for similar content), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it explains the effect of the resolution parameter, describes the return object (modularity, num_communities, communities), mentions output truncation due to token budget, and provides error recovery guidance (0 communities may indicate no edges).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (main purpose, usage, args, returns, error recovery). Each sentence adds value, though the returns section is somewhat verbose. Still, it is reasonably concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (community detection with one parameter), the description is complete: it explains the algorithm, parameter effect, return format, output truncation, and error handling. No missing information for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'resolution' is fully explained in the description with its default value and impact on community size, compensating for the schema's lack of description (coverage 0%). The explanation adds clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it detects communities using the Louvain algorithm. Distinguishes from sibling tools like dijkstra and pagerank by specifying what it is not for, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you want to discover clusters or groups') and when not to use it, providing specific alternatives (dijkstra for paths, pagerank for ranking). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully carries the burden. It details the MMR algorithm's balancing of relevance and diversity, explains the effect of lambda_mult, fetch_k, and ef, and notes that results are ordered by MMR selection, not pure distance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, usage advice, parameter details, return description, and example. Very informative, though slightly verbose in parameter explanations; still earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: algorithm behavior, parameter roles, return format (JSON array of objects with fields), and example invocation. Output schema exists, so return details are sufficient. Complements sibling tools like vector_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description comprehensively explains each parameter: label/property/query_vector (required), k, fetch_k (with default derivation from k), lambda_mult (with recommended range for RAG), and ef. Adds context like default values and tuning advice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Find diverse nearest neighbors using MMR') and explicitly distinguishes from sibling tool 'vector_search' by contrasting use cases ('Use this tool when... Use vector_search when...').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'when to use' (diverse results for RAG, avoiding near-duplicates) and 'when not to use' (use vector_search for absolute closest matches), with explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that deletion is permanent, that detach=True removes connected edges (like DETACH DELETE in Cypher), and that detach=False fails if edges exist. It also describes return value (confirmation or error) for both success and failure cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a one-line summary, usage guidelines, args section, returns section, and examples. Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (1 required) and an output schema, the description covers all necessary aspects: what the tool does, when to use it, parameter details, return value, and examples. It is complete and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains node_id as the ID of the node, and detach as controlling edge removal behavior with its default (True). Examples illustrate usage, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete a node) and the resource (node in graph). It explicitly distinguishes from siblings by saying 'do NOT use for updating properties (use update_node) or deleting edges only (use delete_edge)'. This provides specific verb+resource differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (remove a node permanently) and when not to (updating properties, deleting edges only) with alternative tool names. It also covers the detach parameter's behavior, giving clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully explains behavior: returns node IDs and properties, paginated with limit/offset, includes total count and truncation note, and gives defaults. Clearly a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, usage guidelines, args, returns, and examples. Every sentence adds value, concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no nested objects), the description is complete. It covers input, output, and behavior. Despite having an output schema (not shown), the description explains return format, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains all three parameters (label, limit, offset) with defaults, types, and examples, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find nodes that have a specific label' and differentiates from siblings like get_node (single node by ID) and execute_gql (complex filtered queries), using specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('list or browse nodes of a certain type') and when not to use ('getting a single node by ID', 'complex filtered queries'), naming alternative tools (get_node, execute_gql).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details the merge behavior (merge vs replace), describes return type, and provides examples. This is comprehensive behavioral disclosure beyond minimal requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: main statement, usage guidelines in bullet style, parameter descriptions, and examples. Every sentence adds value and there is no redundancy. Highly concise for the amount of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema exists, the description covers all necessary aspects: purpose, parameters, behavioral details, return type, and examples. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description fully describes all three parameters (node_id, properties, merge) with types and behavior. Adds significant meaning not present in the schema, such as merge default and properties allowed value types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update properties on an existing node.' It uses a specific verb and resource, and distinguishes from siblings by explicitly listing what not to use it for (changing labels, creating, deleting nodes) with sibling tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you need to modify a node's properties after creation') and when not to use ('Do NOT use for: changing labels (use execute_gql), creating new nodes (use create_node), or deleting nodes (use delete_node)'). Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![grafeo-mcp MCP server](https://glama.ai/mcp/servers/GrafeoDB/grafeo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GrafeoDB/grafeo-mcp)

Score Badge

Copy to your README.md:

[![grafeo-mcp MCP server](https://glama.ai/mcp/servers/GrafeoDB/grafeo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GrafeoDB/grafeo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GrafeoDB/grafeo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server