search_notesSearch notes by name or content using ripgrep. Provide a query and optionally set limit and offset to control the result set.
Search notes by name and content (ripgrep).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| offset | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "type": "integer"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, but it is sparse: 'search' implies a read-only operation and 'ripgrep' hints at regex behavior, yet side effects, result ordering, and pagination semantics are unstated. The ripgrep mention and by-name/content scope add some behavioral context, but the description remains a high-level line.
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?
One short sentence, front-loaded with the action and scope, with no filler. The 'ripgrep' parenthetical earns its place by adding an implementation/regex signal. It is concise, though it sacrifices routing and parameter detail.
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?
This is a low-risk search tool and an output schema exists, so the description does not need to document the return shape. However, in a sibling set that includes search_by_tag, the lack of explicit differentiation and the 0% schema coverage leave an agent to infer usage details like pagination parameters and whether tag queries are supported.
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%, so the description should compensate for the undocumented 'query', 'limit', and 'offset' parameters. It only partially helps for 'query' by stating name/content search, and it never addresses 'limit' or 'offset'. The parameter names and defaults are relatively self-explanatory, which is why this is not a 1.
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 gives a clear verb ('Search'), resource ('notes'), and scope ('by name and content'), and the parenthetical 'ripgrep' signals full-text/regular-expression search. It does not explicitly name a sibling to differentiate it from, so it stops short of a perfect score.
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 description implies the tool should be used for full-text/name searches, but it provides no explicit when-to-use guidance or alternatives, such as preferring search_by_tag for tag-based lookups. The context is oriented around the tool's own function rather than placement among its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.