consents_signedRetrieve signed client consents from a salon's Booksy Biz account, with pagination and a cache-skip option for current results.
Consents assigned to clients.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, from 1 | |
| fresh | No | Skip the local cache | |
| per_page | No | Items per page, at most 100 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it doesn't disclose that results are paginated, that a local cache exists (implied only by the 'fresh' param), or what the shape of a consent record is.
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 wasted words, but it is under-specified rather than concise — the terseness removes disambiguating information an agent needs among ~100 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 listing tool in a large namespace with a near-identical sibling (consent_forms), the description is not complete enough to route correctly. Annotations and schema are the only reliable signal; the description resolves neither scope nor relationship to the sibling.
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?
All three parameters (page, fresh, per_page) have full schema descriptions with defaults and bounds, so the schema carries the load and a baseline of 3 is appropriate. The description contributes no additional meaning about how paging or cache-skipping interact with consent listings.
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 restates the name/title ('Consents') and appends a minimal scope qualifier ('assigned to clients'), but supplies no verb — it never says this lists or retrieves signed consents, nor how it differs from the sibling consent_forms.
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?
There is no statement of when to use this tool, when not to, or what the alternative (consent_forms) covers. An agent must guess which of the two consent tools to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.