cancel_feasibility_requestWithdraw a pending feasibility request. A request already answered cannot be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| organization_id | No | Organization for this operation and billing. Use list_organizations to choose an active membership. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | The withdrawn feasibility request. |
Changes observed during successful MCP inspections.
Input schema / properties / organization_id / descriptionPrevious value: -"Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet."New value: +"Organization for this operation and billing. Use list_organizations to choose an active membership."Input schema / properties / organization_idAdded value: +{
+ "description": "Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet.",
+ "maxLength": 128,
+ "minLength": 1,
+ "type": "string"
+}Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / request_id / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / result / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / result / properties / cancelled_at / $refRemoved value: -"#/properties/result/properties/responded_at"Output schema / properties / result / properties / cancelled_at / descriptionAdded value: +"ISO 8601 timestamp."Output schema / properties / result / properties / cancelled_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / result / properties / estimated_timeline_hours / $refRemoved value: -"#/properties/result/properties/estimated_total_cost_per_interview_usd"Output schema / properties / result / properties / estimated_timeline_hours / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / result / properties / estimated_total_cost_usd / $refRemoved value: -"#/properties/result/properties/estimated_total_cost_per_interview_usd"Output schema / properties / result / properties / estimated_total_cost_usd / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / result / properties / expected_response_by / $refRemoved value: -"#/properties/result/properties/responded_at"Output schema / properties / result / properties / expected_response_by / descriptionAdded value: +"ISO 8601 timestamp."Output schema / properties / result / properties / expected_response_by / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / result / properties / target / maximumAdded value: +9007199254740991Output schema / properties / result / properties / target / minimumAdded value: +-9007199254740991Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the agent knows this is a destructive but idempotent mutation. The description adds the pending-only lifecycle constraint, which is genuinely beyond the annotations, but says nothing about the effects of withdrawal (does it free held capacity, can it be resubmitted, is it reversible).
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, front-loaded with the action and followed by the blocking condition. Nothing is wasted and nothing is buried.
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?
An output schema exists so return values need not be explained, and the annotations carry the safety profile. For a two-parameter tool the description covers the key precondition; only the permissions needed and post-cancel effects are left unstated.
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 only 50%: organization_id is documented in-schema, but request_id has no description in the schema and none in the tool description. The description adds zero meaning about which request identifier to supply or how to obtain one.
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 and resource ('Withdraw a pending feasibility request'), which is inherently distinct from the sibling verbs submit_feasibility_request, get_feasibility_request and list_feasibility_requests. It does not name those siblings explicitly, so it stops short of a 5.
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?
'A request already answered cannot be cancelled' gives a clear when-not condition tied to request state. It does not point the agent at alternatives (e.g. call get_feasibility_request first to confirm the request is still pending), so no explicit alternative routing.
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.