mail_getOrderPlanV1Retrieve the hosting plan tied to a mail order, including domain and mailbox quotas, limits, and protocol availability. Use this to verify or audit mail service capabilities for a specific order.
Retrieve the plan the given mail order was purchased with, including domain-level and mailbox-level quotas, limits, and protocol availability.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Order resource ID |
Changes observed during successful MCP inspections.
v1.23.0Does 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 clear. The description adds useful context about what the response covers (quotas, limits, protocol availability), but it does not disclose output shape, error behavior, or whether the plan can be missing for certain orders.
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?
The description is one focused, front-loaded sentence that states the action, the target resource, and the key contents of the returned plan. There is no redundant phrasing or filler.
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 read-only getter with one required parameter, this description is sufficiently complete. It explains what the tool returns, the annotations cover safety, and the schema fully documents the only input, so an agent can select and invoke it correctly.
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?
The single parameter orderId is fully documented in the schema as 'Order resource ID', so schema coverage is 100%. The description only refers to it indirectly as 'the given mail order' and adds no new format, source, or prerequisite details beyond the 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?
The description uses a specific verb 'Retrieve' and identifies the exact resource: the plan a mail order was purchased with. It further clarifies the scope by enumerating what the plan includes (domain-level and mailbox-level quotas, limits, protocol availability), making it clearly distinct from sibling list/retrieval tools such as mail_listOrdersV1.
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?
The usage context is implied: call this when you need the plan details for a specific mail order. However, there is no explicit guidance about when not to use it, prerequisites such as obtaining the orderId first, or how it compares to related mail order tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.