Loading ToolBench
A Model Context Protocol server for Graphiti knowledge graphs
Graphiti MCP server has a mixed definition quality profile. The 8 tools show reasonable naming conventions (all verb-start actions like search_*, get_*, add_*, clear_*) and basic descriptions are present. However, several critical gaps emerge: (1) Parameter descriptions are minimal or missing detail about constraints and formats; (2) Output schemas are not documented in the visible code, we see TypedDict definitions in graphiti_mcp_server.py (NodeResult, NodeSearchResponse, FactSearchResponse, ErrorResponse) but no explicit schema definitions tied to tool outputs; (3) The clear_graph tool has no input validation or confirmation mechanism despite being destructive; (4) Error handling lacks actionable recovery guidance; (5) Some parameter types are inferred rather than formally declared. The code shows reasonable structure with FastMCP framework and proper typing, but falls short of production-grade definition quality.
Add an observation to the knowledge graph with automatic entity extraction and linking
Clear all data from the knowledge graph
Get statistics about the knowledge graph
Get detailed information about a specific node in the knowledge graph
Get the neighboring nodes connected to a specific node in the knowledge graph
Search for episodes in the knowledge graph
Search for facts in the knowledge graph
clear_graph is destructive but lacks confirmation mechanism and warning in description. Description is only '"Clear all data from the knowledge graph"' with no mention of irreversibility or need for user confirmation.
Parameter descriptions lack constraint documentation. 'limit' parameters say only 'Maximum number of results to return (default: 10)' without specifying bounds (e.g., min=1, max=100). 'filters' parameter in search_nodes has no examples or format specification. 'relationship_type' in get_node_neighbors is optional but has no guidance on valid types.
Output schemas are not explicitly documented in tool definitions. While TypedDict classes exist in the code (NodeResult, NodeSearchResponse, FactSearchResponse), they are not formally tied to tool return contracts. LLMs cannot infer the exact field structure they will receive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for nodes in the knowledge graph using hybrid search with optional filters
Error handling is generic. No evidence of actionable error messages that tell LLMs what to do next (e.g., 'UUID not found. Call search_nodes() first to find a valid node_uuid.').
add_observation lacks detail on what 'observation_type' accepts. The parameter description says 'The type of observation (default: \'Fact\')' but does not enumerate valid types or reference the ENTITY_TYPES dict (Requirement, Preference, Procedure, Fact) visible in the code.
search_nodes 'filters' parameter documentation is insufficient. No specification of what filter keys are valid, their types, or format. LLMs cannot construct valid filter objects without examples.
Pagination not clearly specified for search tools. While 'limit' parameter exists, there is no mention of offset/page_size/cursor support for iterating large result sets. No documented max result cap to prevent context window exhaustion.