List your Austin HQ conversation with its unread message count and last message preview. Facility routing is automatic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of conversations to return (1-100). Defaults to 20. | |
| offset | No | Number of conversations to skip for pagination. Defaults to 0. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | Facility conversations plus pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by specifying the output includes unread count and last message preview, and that facility routing is automatic, which goes beyond the annotations.
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 two concise sentences, immediately front-loaded with the action and key output details. Every word adds value, with no repetition of schema or annotation information.
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?
Given the existence of an output schema and comprehensive annotations, the description covers the essential purpose and output fields. Minor ambiguity arises from the singular 'conversation' in the description versus the plural tool name, but overall the context is sufficient for a simple list tool.
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 coverage is 100% with both limit and offset fully described, so the baseline is 3. The description does not add further parameter-level meaning; 'Facility routing is automatic' simply negates a parameter rather than enriching existing ones.
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 ('List'), a specific resource ('your Austin HQ conversation'), and the key returned fields ('unread message count and last message preview'). This clearly distinguishes it from sibling tools like get_facility_messages or send_facility_message, and the added note 'Facility routing is automatic' clarifies scope.
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 description provides clear context that this tool handles the Austin HQ conversation automatically ('Facility routing is automatic'), implying no facility parameter is needed. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide appropriate use.
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.
Most tools map cleanly to distinct resources and actions, forming clear list/get pairs for outbound mail, inbound mail, and postal threads. The main ambiguity is between get_facility_messages and list_facility_conversations, which both target the same Austin HQ conversation, and get_mailbox versus list_inbound_forwarding_addresses are closely related address lookups.
All tool names use a consistent lowercase snake_case verb_noun pattern with familiar verbs like get, list, send, cancel, create, update, and propose. There are no mixed naming conventions or vague generic names.
19 tools is within the 16-25 range that feels heavy for a single-domain MCP server. The broad outbound/inbound lifecycle, threads, facility messaging, MAILBOX.md, usage, and webhook support justify much of the count, but a few tools such as the facility conversation list/get pair could reasonably be consolidated.
The tool surface covers the core physical mail workflow well: test and real outbound sends, cancellation, inbound forwarding and retrieval, postal threads, facility communication, MAILBOX.md sync, usage, and webhooks. Minor gaps exist around webhook inspection/removal and direct document download, but these are unlikely to cause agent dead-ends in the main workflows.
