Loading ToolBench
An MCP server that provides a semantic search over an Obsidian vault
The server defines 1 tool (search-notes) with basic structure but significant quality gaps. The tool has a name and description, but the description is extremely minimal (23 characters: 'Search for relevant notes'), falls below the recommended 50-200 character range for LLM optimization, and lacks critical context about when to use it, what it returns, or how results are structured. The input schema is present and includes a 'query' parameter with type 'string', but the parameter itself lacks a description, the parameter schema only defines the type, not what the query should contain, format constraints, or examples of valid queries. The tool documentation does not explain the output structure (EmbeddedResource with TextResourceContents), pagination behavior, or result limits. No error handling guidance is provided. The overall definition quality is poor-to-fair, placing this in the D (50-59) to C (60-69) range before transport penalty.
Search for relevant notes
Tool description is critically undersized (23 chars). Rubric baseline is 50-200 chars for LLM optimization. Current description 'Search for relevant notes' provides no context on when to call this tool, what kind of results are returned, or how to interpret them.
Parameter 'query' has no description in the schema. The rubric states: 'Every parameter needs a description explaining what it controls.' LLMs cannot infer whether 'query' expects a full sentence, keyword, boolean operators, file names, tags, etc.
Output schema is not documented in the tool definition. The code returns EmbeddedResource objects with TextResourceContents (uri, mimeType, text), but the tool schema does not declare this structure. LLMs cannot plan downstream operations or understand what fields are available.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No result limits or pagination documented. The search returns a list of file contents but does not specify: are results capped? What is the max number of matches? Can the agent request more results? Large result sets risk context explosion.
No error handling guidance. If the query is empty, malformed, or matches nothing, what does the tool return? The code raises ValueError but does not document recovery steps for the LLM.
Tool name 'search-notes' is acceptable but generic. It does not indicate whether this is semantic search, full-text search, or tag-based search. The implementation uses embeddings (sentence-transformers) but the name does not signal 'semantic' search.