Loading ToolBench
DevContext is a cutting-edge Model Context Protocol (MCP) server designed to provide developers with continuous, project-centric context awareness.
DevContext MCP server has 3 tools with READ_ONLY risk profiles. Tool definitions are present but suffer from significant gaps: descriptions lack specificity and context guidance, parameter schemas are incomplete or minimal, and output schemas are undocumented. The 'ping_server' tool is trivial (just a healthcheck). The two substantive tools ('initialize_conversation_context' and 'retrieve_relevant_context') have generic descriptions that fail to explain WHEN to use them or WHY they differ, making tool selection ambiguous for LLMs. Parameter descriptions are sparse, 'retrievalParameters' is described only as 'Optional retrieval parameters' with no detail on what parameters it accepts or their format. No output schemas are documented anywhere in the source, preventing agents from knowing what fields to expect or how to chain calls. Error handling guidance is absent. This is below the 60-69 'Fair' band due to missing schemas, generic descriptions, and no error recovery guidance.
Creates a new conversation session and optionally logs an initial query. Fetches project structure summary, recent conversation topics summary, architecture context summary, and FTS snippets for initial query.
Simple handler that responds with a pong message and current timestamp. Used to verify that the server is running and responding to MCP tools.
Retrieves relevant context snippets based on a query within a conversation session.
Output schemas completely undocumented. No tool returns a documented schema, LLMs cannot predict what fields are available or plan downstream tool chains. 'initialize_conversation_context' returns project structure, conversation topics, architecture context, and FTS snippets, but no schema is visible in the source. 'retrieve_relevant_context' returns context snippets but schema is opaque.
Parameter descriptions are generic or missing. 'retrievalParameters' is described as 'Optional retrieval parameters', no detail on what keys it accepts, their types, or constraints. LLMs cannot use this parameter correctly without guessing. 'max_context_tokens' lacks guidance on minimum/maximum bounds or common values.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Tool descriptions lack 'WHEN to use' guidance. 'initialize_conversation_context' and 'retrieve_relevant_context' both deal with context retrieval but their differences are not explained. LLMs cannot disambiguate which to call first or when to call each one. For example: should you always initialize first? Can you call retrieve without initialize?
No error handling guidance. Tools have READ_ONLY risk but no error descriptions explain what can go wrong (network failure? invalid conversation ID? token budget exceeded?) or how to recover. Agents have no recovery path.
Parameter type definitions incomplete. 'retrievalParameters' is typed as 'object' with no schema, this is too loose. LLMs cannot validate their own input. All object-type parameters should include a nested schema or explicit documentation of required/optional keys and their types.
ping_server description is appropriate for a healthcheck but offers no guidance on use cases or when an agent should call it vs relying on the MCP protocol's own connection management.