wakeup_cancelCancel a scheduled wake-up call.
| Name | Required | Description | Default |
|---|---|---|---|
| wakeup_id | Yes | wakeup_id from wakeup_schedule or wakeup_list. | |
| instance_id | Yes | Utility instance id from buy or list_utilities. | |
| passport_token | No | Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in. |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesAdded value: +falseInput schema / properties / passport_token / descriptionPrevious value: -"Leave it out when your MCP app signed in to AgentMart (it is refused then). Otherwise your passport bearer token (amp_...) or session token (amp_s_...), only if your client cannot send it as an Authorization header. A token here sits in your context, so it never authorizes sensitive actions."New value: +"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."Input schema / properties / wakeup_id / descriptionAdded value: +"wakeup_id from wakeup_schedule or wakeup_list."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds nothing beyond restating the title—it does not explain what is destroyed, whether cancellation is reversible, or any auth/permission requirements.
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 front-loaded sentence with no wasted words, appropriate for a simple cancel operation. It is efficient but borders on under-specification rather than genuine conciseness.
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 simple mutation tool with a fully-documented schema and annotations that carry the safety profile, the description is minimally sufficient. However, it leaves out any behavioral detail (reversibility, failure modes, auth) that an agent might want before invoking a destructive 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 100%, so the schema fully documents wakeup_id, instance_id, and passport_token. The description adds no parameter meaning, so the baseline of 3 applies.
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 ('Cancel') and resource ('a scheduled wake-up call'), which is clear and matches the title. It does not explicitly differentiate from the sibling wakeup_list or wakeup_schedule, though the distinct verb makes the intent reasonably inferable.
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 guidance on when to use this tool versus alternatives, no prerequisites, and no named siblings. The only routing hints (wakeup_id from wakeup_schedule or wakeup_list) live in the schema, not the description.
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.