give_feedbackSubmit corrections, flag missing information, or request changes to notes in your shared markdown vault. Queues feedback for later review and retrieval.
Queue feedback: correct info, flag missing info, or file a request.
kind is one of: correction | missing | request.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| kind | Yes | ||
| note_id | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The word 'Queue' usefully implies asynchronous, non-blocking submission rather than an immediate answer, which is real behavioural signal. But it says nothing about who consumes the feedback, whether it is anonymous, whether it requires auth, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines with zero filler: the action and its three modes come first, then the enum constraint. Every sentence earns its place and nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. But for a 3-parameter tool with 0% schema coverage, only kind is really covered; note_id and body semantics, and the tool's relationship to ask_question, are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 3 parameters. The description usefully enumerates the allowed kind values (correction | missing | request), which the schema lacks as an enum, so it compensates for the most important parameter. It says nothing about body or about note_id, whose empty-string default and relationship to a note are left entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Queue feedback') and breaks it into three concrete modes: correct info, flag missing info, file a request. That distinguishes it from the note CRUD siblings and from ask_question, though it never explicitly contrasts itself with ask_question, which is the closest functional neighbour.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The three phrasings map intent to the kind values, which implicitly tells the agent which mode to pick. However, there is no guidance on when to use this tool versus ask_question, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.