Loading ToolBench
The Bear MCP server defines 5 tools with explicit schemas and descriptions. Naming follows verb conventions (open_, create, replace_, add_), and parameter descriptions are present. However, several issues limit the quality: (1) Some parameter descriptions are minimal (e.g., 'note title' lacks context on length/format constraints). (2) Output schemas are defined as Pydantic models but not documented inline with the tools, LLMs must infer expected fields. (3) Error handling is present but generic (ErrorResponse wrapping), with no recovery guidance in tool descriptions. (4) Some tools have optional parameters that could create ambiguity (e.g., open_note accepts either 'id' or 'title', but the description does not state what happens if both are provided or neither is provided). (5) The add_file tool's 'file' parameter accepts 'base64 representation of a file or a URL', this dual mode is not clearly constrained, inviting LLM confusion. Most tools follow basic naming patterns, but descriptions lack LLM-optimized context (WHEN to use, dependencies, prerequisites).
Append or prepend a file to a note identified by its title or id.
Add a title to a note identified by its id.
Create a new note and return its unique identifier. Empty notes are not allowed.
Open a note identified by its title or id and return its content.
Replace the content of an existing note identified by its id.
Parameter mutual-exclusivity not documented. open_note accepts either 'id' or 'title' but does not state behavior when both are supplied or neither is supplied. This forces LLM to guess.
add_file 'file' parameter accepts two mutually exclusive formats ('base64 representation' vs 'URL') without clear disambiguation. No enum or constraint guides the LLM on which format to use when.
Output schemas are defined as Pydantic models (Note, NoteID, NoteInfo, ModifiedNote) but are not documented inline with tool descriptions. LLMs cannot see what fields to expect without examining the source code.
Error handling is generic (ErrorResponse with errorCode and errorMessage). Tool descriptions do not include recovery guidance. E.g., if open_note fails with 'note not found', should the LLM call list_notes() or search_notes()? Not documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions are minimal. E.g., 'note title' lacks constraints: max length, allowed characters, uniqueness requirements. 'Base64 representation of a file' in add_file does not state max size or supported file types.
No batch operations. Tools like add_file operate on single items. If an agent needs to add multiple files to a note, it must call add_file N times sequentially, wasting tokens and latency.