Loading ToolBench
A Model Context Protocol server implementation that exposes tools for governance, metadata execution, task runtime operations, and knowledge management in a repository-driven environment
This MCP server has severe definition quality gaps. Only 1 of 5 tools (emit_sized_payload) has a visible input schema in the provided source. The other 4 tools (apply_amendment, apply_contract_amendment, apply_delta, apply_metadata_transition) reference external implementation modules but show no actual schema definitions in the code excerpts provided. All tool descriptions are present but extremely brief and referential rather than self-contained, they point users to implementation modules rather than explaining what the tool does, when to use it, or what it returns. No output schemas are documented. The test/inline probe server reveals only one properly schematized tool. This indicates the core definitions are not materialized in the MCP layer, making the server unsuitable for agent selection and reasoning.
Stable public command; implementation lives at :mod:`Tools.execution.task_runtime.apply_amendment`
Stable public command; implementation lives at :mod:`Tools.execution.task_runtime.apply_contract_amendment`
Stable public command; implementation lives at :mod:`Tools.execution.task_runtime.apply_delta`
Stable public command; implementation lives at :mod:`Tools.knowledge.metadata.apply_metadata_transition`
Return a payload of exactly `size_bytes` UTF-8 bytes whose final field is a fixed tail nonce.
Four of five tools (apply_amendment, apply_contract_amendment, apply_delta, apply_metadata_transition) have NO visible input schema definitions in the source code. Descriptions reference external implementation modules (e.g. ':mod:`Tools.execution.task_runtime.apply_amendment`') instead of explaining what the tool does. Per the hard scoring rule: 'If a tool has NO input schema at all: its schema score MUST be 0.'
All five tool descriptions are under 100 characters and are purely referential rather than self-contained. E.g., 'Stable public command; implementation lives at :mod:`Tools.execution.task_runtime.apply_amendment`' tells an LLM nothing about what the tool does, when to call it, what parameters it accepts, or what it returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
No output schemas are documented for any of the five tools. LLMs cannot determine what fields will be returned, making downstream tool chaining impossible and forcing agents to guess at the response structure.
For the four tools with no schema, it is unclear whether schemas exist in the runtime and are simply not exposed in the MCP server definition, or whether they are missing entirely. Tools appear to be inferred from file paths (Tools/apply_amendment.py, etc.) rather than explicitly registered with full definitions.
Tool names like 'apply_amendment', 'apply_contract_amendment', 'apply_delta', and 'apply_metadata_transition' use the verb 'apply', which is vague. 'apply' could mean different things in each context, does it execute a state change, persist data, validate, or compute? More specific names like 'execute_amendment', 'finalize_amendment', 'stage_amendment' would better signal intent. The naming follows a pattern but lacks clarity for LLM selection.
emit_sized_payload's description is narrow and functional but lacks context. It states what the tool returns but not WHY an LLM would call it. Is it for testing, probing latency, or measuring protocol overhead? A test-only tool should not be exposed in a production server.