Loading ToolBench
Semantic Tool Discovery Middleware for MCP
The server defines 4 tools with explicit schemas and descriptions. Tool naming follows verb_noun convention (find_*, get_*, set_*), which is good. However, descriptions are inconsistent in depth, some are brief (16 chars for 'Set discovery context') while others are detailed (250+ chars). Parameter descriptions are mostly missing or minimal. Input schemas are present but lack per-parameter descriptions except in tool 4. Output schemas are not documented anywhere. The server exhibits basic composition (discovery + fetch pattern) but lacks error handling guidance and response structure documentation. This puts it in the 'fair to good' range.
Set discovery context
Search for prompts semantically
Search the skill catalog by free-text query. Returns matching skills with name + frontmatter description so an agent can decide whether to fetch the full procedure via mcp_semantic_gateway_get_skill.
Fetch the full SKILL.md body (procedural steps + tool list) for a skill discovered via mcp_semantic_gateway_find_skills. Pass the skill 'name' from the find_skills result.
Tool 1 ('mcp_semantic_gateway_context') has an under-20-character description ('Set discovery context', 23 chars but minimal semantic content). Per HARD SCORING RULE, description score capped at 20. It is unclear what 'discovery context' means, when to call it relative to find_prompts/find_skills, or what state it modifies.
Parameter 'query' in all tools lacks per-parameter descriptions in the schema (except tool 4, which has 'Free-text search query for skills' inside the schema). Tool 1 and 2 schemas omit descriptions entirely.
No output schema is documented for any tool. The rubric requires: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Users must infer that find_skills returns 'name' and 'description' fields by reading the get_skill description, not from explicit schema. Tools 1 and 2 output structure is entirely undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 28 | 2024-11-05+ | v1 |
No error handling or recovery guidance is present. If a skill name is not found via get_skill, what happens? If a semantic search returns no results, does the tool return an empty array or error? The rubric requires: 'Error responses must tell the LLM what to do next.' No error classification or actionable guidance.
Tool 1 ('mcp_semantic_gateway_context') does not clearly state whether it modifies state or is read-only (though metadata says 'READ_ONLY'). The description 'Set discovery context' uses 'set', implying state mutation, but the Risk field contradicts it. This ambiguity violates the pattern: 'If the tool modifies state (creates, updates, deletes, sends), the description must say so.'
Tool 1 and 2 descriptions do not state WHEN to use them instead of similar tools. Both 'find_prompts' and 'find_skills' are discoverable via semantic search, but the distinction is unclear. The rubric: 'A tool description must answer: What does it do? When should the LLM call it instead of a similar tool?' No guidance.
No pagination or result-limit parameters are visible. If find_skills returns 100+ results, the LLM context window is exhausted. The rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' Neither parameter is present; no limit is stated in the description.