search_clients
Find existing Morning (Green Invoice) clients by name and paginate results for accounting lookups.
Instructions
Find existing Morning clients.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| page | No |
Find existing Morning (Green Invoice) clients by name and paginate results for accounting lookups.
Find existing Morning clients.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| page | No |
Changes observed during successful MCP inspections.
v0.1.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing else – no mention of result count, pagination behavior, or match semantics for the name parameter.
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?
A single short sentence with no filler. It is efficient, though perhaps too sparse given the tool's ambiguous role among its siblings.
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?
For a search tool with two undocumented params and no output schema, the description is far too thin. It doesn't say what is returned or how matching works, so an agent cannot confidently call it.
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 must compensate but does not. It never explains that 'name' is a match query or that 'page' controls result pagination, leaving both parameters undocumented in prose and schema.
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?
States a verb (Search/Find) and resource (clients), which is enough to know it returns matching clients. But 'existing Morning clients' and the name 'search_clients' don't differentiate it from the sibling get_client, nor does it clarify what a 'Morning client' is.
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?
No indication of when to use this versus get_client or the other search_* siblings. The agent must infer that this is keyword-find while get_client presumably fetches one by id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.