LitCoin MCP presents a focused knowledge graph query interface with 5 tools, all read-only and well-scoped to Neo4j and semantic search operations. However, the implementation has significant gaps in description quality, parameter documentation, and output schema clarity. Tool names follow a reasonable verb_noun pattern (get_*, search_*), but descriptions are minimal (10-25 chars), and parameter descriptions lack detail about constraints, formats, and expected input ranges. No output schemas are documented in the code, forcing LLMs to infer result structure. Error handling is absent, queries that fail return raw database errors with no recovery guidance. The server uses STDIO transport, which is not remotely testable and caps the protocol readiness at 50.
Tools (5)
get_edges_betweenread onlysource verified43/100
Retrieve edges between two specific nodes
get_noderead onlysource verified43/100
Retrieve a node from the knowledge graph by its ID
All tool descriptions are under 20 characters and provide minimal context. Examples: 'Retrieve a node from the knowledge graph by its ID' (55 chars is borderline acceptable, but most descriptions lack detail on when to use the tool, what it returns structurally, or error cases).
Parameter descriptions are either missing or trivial. For example, 'top_k' and 'k_per_index' in semantic search tools have descriptions like 'Maximum number of results to return' but do not specify: (1) valid range (e.g., 1 - 100), (2) performance implications of large values, (3) default behavior or side effects.
Expand all tool descriptions to 50 - 200 characters, following pattern:tool-description. Example for get_node: 'Retrieve a node from the knowledge graph by its unique ID. Returns the node with all properties (embeddings removed). Use this to fetch detailed information about a specific entity. Returns empty list if node not found.'
Add explicit parameter constraints in descriptions. Example for get_semantic_similar_nodes: 'query (string, required): Natural language query string (e.g., "diseases causing fever"). top_k (integer, default 10, range 1 - 100): Maximum results to return; higher values increase latency. k_per_index (integer, default 2): Results per node type index; affects diversity vs relevance trade-off.'
Document output schemas in tool registration using JSON Schema. Example for get_node_edges: 'Returns array of objects with fields: source (string, node ID), predicate (string, relationship type), target (string, node ID), properties (object, additional metadata). Example: [{"source": "gene:123", "predicate": "associated_with", "target": "disease:456", "properties": {}}]'
Implement error handling with recovery guidance. Wrap Neo4j queries in try-catch blocks. Return structured error responses with actionable messages. Example: On node not found, return {"error": "Node not found", "node_id": "<provided_id>", "suggestion": "Use get_semantic_similar_nodes() to search by name or properties"}. On connection error, return {"error": "Database unavailable", "retryable": true, "suggestion": "Retry in 30 seconds"}.
No output schemas are documented. The code shows that tools return lists of dictionaries (e.g., get_node returns [{'n': node_dict}], get_node_edges returns [{'source', 'predicate', 'target', 'properties'}]), but no JSON Schema or field descriptions are visible in tool registration. Without this, agents cannot know what fields to extract for subsequent operations.
Error handling is absent. The code has no try-catch blocks or error response strategies. If a Neo4j query fails (e.g., node not found, connection timeout, malformed query), the raw exception or database error will propagate. Currently, agents have no guidance.
STDIO transport only. The server runs on STDIO (standard input/output), not HTTP or HTTP+SSE. STDIO servers are not remotely accessible and cannot be used by hosted MCP clients. Per hard scoring rule, STDIO-only servers cap at 50 for protocol readiness.
Parameter naming lacks specificity. The 'query' parameter in semantic search tools is vague, does it expect a natural language string, a graph pattern, a keyword list, or something else? Current naming does not clarify expected input format.
Migrate from STDIO to HTTP transport using FastMCP's HTTP support or uvicorn. STDIO cannot be tested remotely and blocks adoption by hosted clients. FastMCP supports both STDIO and HTTP; add HTTP endpoint configuration.
Add enums or constraints for relationship types. Tools like get_edges_between implicitly depend on valid edge types from config.py (biolink:* namespace). Add input validation and document valid edge types in parameter descriptions to prevent silent failures on typos.
For semantic search tools, clarify the 'query' parameter format with examples in the description. Specify if it expects free text, structured keywords, or a specific domain language. Document how the embedding service processes the query (e.g., using OpenAI's text-embedding-3-small).
Add pagination support to semantic search tools if result sets can grow large. Return a total_count field and next_offset or next_cursor for chaining requests.
Return consistent, chainable IDs in all responses. If get_semantic_similar_nodes returns node_id values, ensure downstream tools (get_node_edges) accept the same node_id format. Verify field naming consistency across tools (e.g., all use 'source_id' or all use 'source', not mixed).
Add tool annotations for safety. Mark all tools with readOnlyHint: true (since they are all read-only graph queries). This helps clients optimize caching and understand tool semantics without parsing descriptions.