visits_cancelSeries
Cancel the visits of a repeating series that have not started yet, from a time onward (default now). Past, started and done visits stay.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | ||
| reason | No | ||
| series_id | Yes |
Cancel the visits of a repeating series that have not started yet, from a time onward (default now). Past, started and done visits stay.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | ||
| reason | No | ||
| series_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does it well: it names the selective effect (only future, unstarted visits are cancelled) and the default cutover time (now). It stops short of saying whether cancellation is reversible, whether visits are deleted or flagged, or what permissions are required for a series-wide mutation.
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 sentences, no filler, and the core scope plus the preservation rule are front-loaded. Every clause earns its place.
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?
There is no output schema and no annotations, so the description is the only source of behavioral detail; it covers the essential blast radius but omits return shape, reversibility, and error conditions (e.g. invalid series). Adequate to invoke, thin for confident use of a destructive series-wide operation.
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 for all three parameters and only partially does. It explains 'from' well (a time onward, defaulting to now) but says nothing about series_id (presumably the recurring series identifier) or 'reason' (max 500 chars) — why it's recorded and whether it's shown to the customer.
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 specific verb (cancel) applied to a precise resource (visits of a repeating series), with an explicit qualifier scoping the operation to not-yet-started visits. The phrase 'repeating series' cleanly separates it from the single-visit sibling visits_cancel, so an agent can pick correctly without opening either schema.
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?
It tells the agent exactly which visits are affected (not started yet, from a time onward) and which are preserved ('Past, started and done visits stay'), which is real when-to-use guidance. What's missing is an explicit pointer to the alternative (visits_cancel for a single visit) or a stated precondition such as the caller needing series ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.