Loading ToolBench
A unified MCP server that manages multiple domain-specific MCP servers for context management across software development, project management, student education, and research domains
This MCP server has critical definition quality gaps. Of 29 tools examined, most lack proper input schema visibility in the source code provided. Tool descriptions are present but generic (average ~50-80 chars, well below the 194-char baseline for A-tier tools). Parameter descriptions exist but lack specificity around constraints, formats, and valid value sets. No explicit error handling guidance is visible. The server appears to manage a knowledge graph with domain-switching capabilities, but the tool interface does not follow Arcade patterns for clarity, composability, or error recovery. Tools like setActiveDomain (READ_ONLY) and endsession (WRITE with complex multi-parameter signature) are not idempotent-safe, no retry guidance. Many tools accept open-ended string inputs (domain, query, entityName) without enums or validation hints. The server shows no evidence of schema documentation in responses, making downstream tool chaining difficult. Per-tool analysis reveals 18 tools with zero visible input schema, capping those at 0 for schema quality.
Add observations to existing entities
Create entities in the knowledge graph of the active domain
Create relations between entities in the knowledge graph
Delete entities from the knowledge graph
Delete specific observations from entities
Delete relations from the knowledge graph
End an active session in a domain with stage tracking and optional analysis
Find projects related to a given project with optional depth
Input schemas not visible in source for 18 of 29 tools (62%). Tools like readGraph, searchNodes, getProjectStatus, getComponentContext, getDecisionHistory, getMilestoneProgress, getProjectOverview, getTeamMemberAssignments, getProjectTimeline, getResourceAllocation, getProjectRisks, getDecisionLog, getProjectHealth have no explicit schema definitions in provided code.
Tool descriptions are generic and short (35-50 chars), missing WHEN to use the tool and prerequisites. Baseline for A+ tools is 194 chars. Examples: 'Change the active domain' (31 chars), 'Read the complete knowledge graph' (33 chars), 'Get the status and details of a software development project' (60 chars). These lack context about side effects, dependencies, and decision factors for LLM tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get comprehensive context about a software component
Get the history of decisions made in a project
Get the decision log for a project
Get progress information for project milestones
Get progress information for a specific milestone
Get health assessment and recommendations for a project
Get an overview of a project including status and key components
Get identified risks for a project
Get the status and details of a software development project
Get the timeline and schedule of a project
Get entities related to a given entity with optional relation type filtering
Get resource allocation information for a project
Get task dependencies with optional depth control
Get all task assignments for a team member
Open and retrieve specific nodes by name
Read the complete knowledge graph
Search for nodes in the knowledge graph by query string
Change the active domain for subsequent tool calls
Set the priority of an entity (low or high)
Set the status of an entity (inactive, active, or complete)
Start a new session in the specified domain
Parameter descriptions lack specificity. 'domain' param is described as 'The name of the domain to activate (developer, project, student, qualitativeresearch, or quantitativeresearch)' but enums are not formally declared in schema. 'query' in searchNodes has no constraint (length? regex? free-form?). 'stageNumber' in endsession has no bounds (0-based? positive?). Open-ended descriptions invite LLM hallucination.
No output schema documentation visible. Tools return complex structures (knowledge graph entities, project overviews, decision logs) but the response format is not documented. LLMs cannot plan downstream tool chaining (e.g. after getProjectStatus returns a project ID, what field is it stored in?). This violates pattern:tool-chain.
Destructive tools (deleteEntities, deleteObservations, deleteRelations) lack confirmation or dry-run support. endsession modifies state (WRITE) and may be non-idempotent (isRevision flag suggests state tracking). No error guidance provided for recovery if deletion succeeds partially. Violates pattern:confirmation-request and pattern:error-classification.
Duplicate or near-duplicate tool names reduce clarity. getMilestoneProgress appears twice (developer domain and project domain) with identical name but possibly different payloads. LLMs will conflate them. Per pattern:name-clarity, 'get_channel_metadata' vs 'get_channel_messages' is clear; 'getMilestoneProgress' vs 'getMilestoneProgress' is not. Naming should distinguish domain scope (e.g. getDeveloperMilestoneProgress, getProjectMilestoneProgress).
No error handling guidance. Tools return undefined error responses. What happens if deleteEntities is called with a non-existent entityName? 'Not found' vs 'Permission denied' vs 'Invalid input'? No recovery instructions. Pattern:recovery-guide requires 'User not found. Try search_users() with a partial name.', this server provides none of that.
Tool composition is weak. setActiveDomain is READ_ONLY but is a prerequisite for all subsequent tools in that domain. No tool discovery mechanism (e.g. listAvailableDomains) to help LLMs know what domains exist. After startsession succeeds, the sessionId must be passed to endsession, but no documentation of the sessionId format or lifetime. This forces LLMs to infer structure.
Batch operations are missing. addObservations accepts an array but other create/add tools (createEntities, createRelations) may require N sequential calls if the agent needs to create multiple entities in sequence. Batch support would reduce token waste and latency. Pattern:composition suggests batch variants.