mailbox-mcp

by arbengine

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource or action (packages, inbound mail, outbound mail, facilities, rules, etc.) with clear boundaries. Even related tools like add_note and update_action have clearly separated purposes (package notes vs action request notes). There is no overlapping functionality that would cause confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_package, list_inbound_mail, send_outbound_mail, update_webhook). The naming style is uniform across all 29 tools, making the API predictable and easy to navigate for an agent.
Tool Count4/5
At 29 tools, the count is above the typical well-scoped range (3-15) but fits the comprehensive domain of mail and package management. Each tool serves a necessary function without redundancy, and the scope justifies the number.
Completeness3/5
The tool set covers core workflows (create, read, list, request actions) but lacks explicit update and delete operations for several resources like rules, packages, and webhooks. Notable gaps include no update_rule, delete_rule, delete_package, or delete_webhook, which may cause dead ends when agents need to modify or remove resources.
Average 4.3/5 across 29 of 29 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the HTTPS requirement and 10-second response time constraint, but does not detail side effects like whether event subscriptions are replaced or appended, or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, succinct and to the point. It front-loads the main action and then provides key constraints. Minor improvement could be omitting 'and more' in favor of referencing the schema for full event list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage and an output schema present, the description sufficiently covers the tool's purpose and a critical timing constraint. It does not explain return values, but the output schema likely does. No missing aspects given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description repeats the HTTPS requirement mentioned in the schema, but adds no new parameter-level meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'configure' and the resource 'webhook endpoint URL and event subscriptions', with a specific purpose of real-time notifications. It lists example event types, distinguishing it from sibling tools like create_rule or list_packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating webhook settings but does not explicitly state when to use or not use this tool versus alternatives. No exclusion criteria or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, and the description reinforces this by stating that adding the same tag twice is a no-op. This adds behavioral context beyond the annotations. No other behavioral traits (e.g., authorization needs) are disclosed, but the key trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three short sentences. Every sentence adds value: purpose, tag nature, and idempotency. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (2 params, fully described in schema), presence of output schema, and annotations, the description covers the essential behavior. It could optionally mention case-sensitivity explicitly, but the schema already notes it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes both parameters. The description adds that tags are free-form strings and that adding duplicates is a no-op, which provides minor additional context but does not significantly enhance the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add a tag/label) and the resource (package), with a purpose (categorization and filtering). However, it does not distinguish from sibling tool 'add_note', which serves a similar function but for notes instead of tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for categorization and filtering but fails to provide explicit guidance on when to use this tool versus alternatives like 'add_note'. No exclusion conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal safety hints (readOnlyHint=false, destructiveHint=false). The description adds significant value by detailing each state transition and what gets simulated or added (e.g., simulated pages, tracking info, receipt photo). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the main purpose, second breaks down state transitions. No wasted words, appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the full lifecycle for a test mode mail record, covering all state transitions. An output schema exists, so return values need not be described. The tool is well specified for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description repeats the schema description ('UUID of the test_mode outbound mail record to advance') almost verbatim, adding no new meaning beyond structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('advance') and clearly identifies the resource ('test_mode outbound mail record') and the action (moving one lifecycle step and queuing webhook). It distinguishes from siblings like create_test_outbound_mail and send_outbound_mail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for test mode records and enumerates transitions, but does not explicitly state when to use this tool versus alternatives or provide exclusions. Context from sibling names helps but is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations leave room for description to cover side effects (e.g., action execution on matching). The description mentions requires_approval but does not detail consequences of actions like shredding or forwarding, which could be destructive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with core purpose and a specific usage hint. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, nested objects, output schema), the description covers the basic flow and a key parameter hint. It lacks details on rule persistence or action schema dependencies, but the output schema likely fills gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds useful context for requires_approval but does not significantly enhance meaning beyond the schema for other parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates standing instructions that auto-trigger actions based on package conditions. It distinguishes from sibling tools like request_action (manual) and add_note by focusing on automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for automating package handling with rules, and provides explicit guidance on using requires_approval for a human review step. However, it does not explicitly contrast with alternatives like request_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by revealing the inclusion of a time-limited signed URL and fulfillment photos, which are behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key information without any redundancies. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (implicitly known), the description sufficiently lists the major return fields. However, it does not mention how to use the time-limited URL or any authentication requirements, but for a simple retrieval tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes mail_id as 'UUID of the outbound mail job to retrieve.' The description adds no extra semantics for the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details of an outbound mail job and enumerates specific fields (recipient address, mail class, page count, etc.), distinguishing it from sibling tools like list_outbound_mail (which likely returns summaries) and send_outbound_mail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after obtaining a mail_id but lacks explicit when-to-use or when-not-to-use guidance compared to siblings. No alternative tools are mentioned, leaving context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by listing returned data fields and filter options, clarifying what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return fields, no fluff. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the return structure and filtering. Could explicitly mention pagination behavior, but schema parameters already cover limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value. It reinforces the status filter usage but does not provide details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists outbound mail jobs with status tracking and specifies the returned fields (mail ID, recipient, mail class, status, cost, timestamps), distinguishing it from send/get/advance sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering by status but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like get_outbound_mail for a single job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: messages appear in a shared conversation visible to the renter and facility. Annotations already indicate non-destructive, non-read-only, open-world behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence defines purpose, second adds optional context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and comprehensive annotations plus schema, the description covers purpose, visibility, and optional linking. It lacks mention of character limits or error handling, but these are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds minimal extra meaning about linking messages to packages or action requests, but this is already stated in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a message to the facility operator, specifying the recipient and action. It distinguishes from sibling tools like get_facility_messages (retrieval) and list_facility_conversations (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sending messages to the facility operator but does not explicitly compare to alternatives or state when not to use it. No exclusion criteria or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond mentioning 'optional timeline events,' which is already present in the schema. It does not describe additional behaviors like empty results or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, first stating the action and optional component, second giving the recommended use case. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, output schema provided), and the description plus annotations fully cover safety, purpose, and usage context. No significant gaps remain for the agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully documented in the schema. The description's mention of 'optional timeline events' adds no new meaning beyond the 'include' parameter schema. The baseline of 3 applies when the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get one physical-mail thread with optional timeline events.' It specifies a distinct resource (a single postal thread) and action, distinguishing it from siblings like list_postal_threads. The additional use case sentence explains the tool's purpose in business terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this to explain how a generated outbound mail piece relates back to prior inbound scans and review decisions.' This implies when to use it, though it does not explicitly mention alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive, so the description needn't repeat those. The description adds context about the thread grouping semantics, explaining that threads tie together inbound mail and outbound documents. It doesn't disclose specific behavior like pagination or default sorting, but those are covered by the schema and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb and resource, and both sentences contribute: one defines what the tool does, the other explains its purpose. There is no redundant or unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 5 optional documented parameters, and an output schema, the description sufficiently covers the tool's purpose and use case. It lacks explicit alternatives/exclusions but those are not essential for a list operation with good schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the schema (100% coverage), so the description doesn't need to elaborate on them. The description doesn't add parameter-specific meaning beyond the schema, but the baseline is 3 given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists physical-mail threads and explains their function of grouping inbound context, human review, and outbound sends. This distinguishes it from sibling list tools like list_inbound_mail and list_outbound_mail, which focus on individual items rather than workflow grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use this to understand which inbound items and outbound documents belong to the same business workflow.' This gives clear context for when to choose this tool over alternatives, though it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and description confirms a write operation. It adds visibility context (notes visible to operator and renter) beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with no wasted words. First sentence states purpose, second adds context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers purpose, usage, and visibility. It provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It briefly mentions 'note' and 'metadata' but mostly relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add an observation or context note') and the resource ('to a package'). It distinguishes from sibling tools like 'add_tag' by specifying it's a note, not a tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that notes are visible to facility operator and renter, and suggests use cases (recording decisions, observations, agent reasoning). It does not explicitly state when not to use but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds useful behavioral detail: returns empty while scan is processing, and lists the type of data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no unnecessary words. First sentence front-loads the key content types, second adds important edge-case behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main output types and edge case. With output schema present, description is adequate. Minor gap: no mention of how to handle empty results (retry?), but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with complete schema description (100% coverage). Description does not add extra semantics for package_id, but schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves document scan results and lists specific content (OCR text, structured fields, confidence scores). Distinguishes from siblings like request_scan by describing retrieval behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage after scan request by noting it returns empty if still processing. Could be more explicit about when to use vs siblings, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds non-redundant behavioral context by revealing that the default output includes a compact draft_context with specific elements (OCR context, reply contact candidates, deadlines, thread linkage), which helps an agent understand what the tool returns beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core function, the second explains the default output's purpose. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich output schema and comprehensive annotations, the description is complete enough for an agent to know what the tool does, when to use it, and what to expect in the default output. It doesn't need to explain return values or pagination, as those are covered by the output schema and input schema. A minor gap is not explicitly contrasting with related list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'Default output includes compact draft_context,' which aligns with the include parameter's default, but it does not add substantial meaning to any individual parameter beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('inbound mail items') with a precise qualifier ('forwarded ... captured from private forwarding aliases'), clearly differentiating it from sibling tools like list_outbound_mail and get_inbound_mail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'so an LLM or external agent can reason about OCR context, reply contact candidates, deadlines, and thread linkage before generating outbound mail.' This gives clear context for when to use the tool, though it doesn't explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-destructive write operation. The description adds behavioral context: auto-matching on arrival and auto-execution of actions, which are side effects not captured by annotations alone. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded, and the optional auto-action is clearly separated with examples. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but signaled), return value explanation is not needed. The description covers the tool's core function and an important optional feature. Parameter details are adequately handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description adds value by explaining the optional auto_action and giving examples, but the schema already describes all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pre-register' and resource 'expected inbound shipment', with a specific purpose 'auto-matched when it arrives'. It distinguishes from sibling tools like 'create_rule' or 'request_scan' by focusing on incoming package expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when expecting an inbound shipment that should be auto-matched, and mentions optional auto-action. It does not explicitly state when not to use or provide alternatives, but the context from sibling names makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds value by specifying which actions (shred, dispose) are irreversible, and lists all actions, providing context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the purpose and lists actions, second warns about irreversibility. No fluff, front-loaded, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 actions, nested parameters, output schema present), the description covers the main purpose and key constraints without needing to repeat schema details. It could mention action-specific parameter requirements briefly, but the schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with detailed parameter descriptions. The description adds practical context by listing actions and noting irreversibility, but the schema already explains each enum and the parameters object. The description's added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request a physical action on a package at the facility' and lists all possible actions (forward, shred, scan, etc.), making the tool's purpose specific and distinct from read-only tools like 'list_packages' or 'get_package'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool covers a wide range of physical actions and mentions irreversible ones, but does not explicitly guide when to use this tool versus siblings like 'request_scan' or other action-specific tools. Usage is implied rather than explicitly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show readOnlyHint=false, so the description adds value by explaining that this is a request (non-instantaneous) and that results come later via another tool. It does not fully disclose potential side effects (e.g., whether the package is consumed or altered), but the async nature is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, followed by clarifying detail. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but context signal indicates true) and the description explains the overall workflow (request then retrieve). It lacks explicit error or edge-case handling, but for a simple async request tool, this level of detail is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters (package_id and scan_type enum). The tool description does not add new parameter-level meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair ('Request document scanning') and adds detail about OCR and structured data extraction, clearly distinguishing it from the sibling get_scan_results that retrieves the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (to initiate scanning a package) and mentions the follow-up tool (get_scan_results), providing implicit usage guidance. However, it does not explicitly state when not to use it or list alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds valuable behavioral context: 'compact draft_context by default' and 'stable payload', which go beyond the annotations and help the agent understand what the response will feel like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, immediately followed by usage guidance. Every word earns its place, no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return values. It explains when to use the tool, what type of data to expect (sender context, contacts, deadlines, files, thread linkage), and the default behavior. This is complete for a single-item retrieval tool with robust annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds minimal semantic value beyond the schema, only implying default behavior ('compact draft_context by default') which aligns with the include parameter's documented default. Baseline 3 is appropriate when schema carries the explanatory weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get one forwarded inbound mail item with compact draft_context by default.' It distinguishes from siblings like get_outbound_mail and list_inbound_mail by specifying this is for a single inbound item and for pre-reply drafting context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this before drafting an outbound reply when you need sender context, reply contact candidates, deadline clues, source files, and thread linkage in one stable payload.' This provides clear context for when to use, but doesn't explicitly name alternatives or exclusions like list_inbound_mail for multiple items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by listing the specific data fields returned (e.g., photos, tracking events, shipping label data), providing context beyond the safety profile. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all included details without waste. It is front-loaded with the core action 'Get full package details' and then enumerates specifics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), comprehensive annotations, and presence of an output schema, the description adequately covers what the tool returns. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any parameter-specific information beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'full package details' while enumerating specific data categories (photos, tracking events, shipping label data, etc.). This distinguishes it from sibling tools like list_packages (which returns a list) and get_package_photos (which focuses on photos alone).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use when full details of a specific package are needed, but it does not explicitly contrast with alternatives like list_packages or provide when-not-to-use guidance. The purpose is clear but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds that photos include OCR-extracted text and confidence scores, and that filtering is supported. This provides additional context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The key action and differentiation are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the small number of parameters, annotations, and the presence of an output schema (though not shown), the description is complete. It covers what the tool does, what it returns, and how to filter. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the photo_type enum values (e.g., 'exterior' = package exterior). This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves photos for a package, including OCR-extracted text and confidence scores, and allows filtering by photo type. This is specific and distinguishes it from sibling tools like 'get_package'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when photos with OCR data are needed, but lacks explicit guidance on when to use this tool over alternatives among the many sibling tools. No 'when to use' or 'when not to use' instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint, covering safety. The description adds beyond these: it reveals the output structure (itemized events with costs) and the default billing period behavior, which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The main action and return are front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return types. It covers the main aspects: what the tool returns, default behavior, and time period scope. Complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with format descriptions. The description adds meaning by stating the default behavior for unspecified dates ('Defaults to the current billing period'), which clarifies optionality and default values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('usage summary and billing events'), and clearly states what is returned (itemized events with costs, period totals). The tool's purpose is distinct from siblings, as no other sibling deals with billing/usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining billing data over a time period but does not explicitly mention when to use it over alternatives or provide exclusions. The purpose is clear enough to guide selection, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds that it returns unread counts and last message preview, providing extra behavioral context beyond safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wordiness, front-loaded with key action and resource. Second sentence adds necessary context about conversation meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers essential purpose and return content. No gaps in information needed for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters (limit, offset). Description adds no additional meaning beyond standard pagination parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists active facility conversations with specific details (unread counts, last message preview), and defines what a conversation is. Distinguishes from siblings like list_inbound_mail which lists individual mail items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for overview of conversations; context with sibling tools suggests alternatives for individual messages, but no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: the renter sees the suggestion in their dashboard and can accept, reject, or modify it. This clarifies that the tool does not directly apply changes but proposes them, which is not disclosed by the annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the purpose and workflow, the second gives usage context. Every sentence earns its place with no unnecessary wordage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the schema covers parameters, the output schema covers return values, and the annotations cover safety profile. The description effectively explains the purpose, the proposal workflow, and when to use, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters clearly described (reason and suggested_content). The description itself does not elaborate on parameters, but the schema already provides sufficient semantics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Propose changes to the renter's MAILBOX.md instructions' with a specific verb and resource. It also distinguishes from siblings by emphasizing the proposal nature (renter can accept/reject/modify), unlike direct write or rule-creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this when you observe patterns that could be codified into standing instructions.' This is clear context for when to use, though it does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: billing charges with production keys, no billing with sandbox keys, cost preview via dry_run, deferral via requires_approval, and optional linking to inbound mail. Annotations only indicate non-read-only and non-idempotent; the description adds critical detail about side effects and conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then key notes and optional parameters. It is somewhat long but dense with useful information. Could be slightly more concise, but it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 28 parameters (7 required) and an existing output schema, the description covers the essential workflow: submission, billing, dry run, approval, and thread linkage. It provides enough context for an agent to invoke the tool correctly, though missing minor details like max file size (present in schema) and explicit return value format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping return address fields and explaining the intent of dry_run and requires_approval, but it does not systematically explain each parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the verb ('submit') and resource ('document for printing and postal mailing'). Supported formats are listed. The title 'Send Outbound Mail' further reinforces the purpose. No explicit sibling differentiation, but the purpose is unambiguous given the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (submitting for mailing), important billing differentiation (production vs sandbox keys), and optional behaviors like dry_run and requires_approval. However, it does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the return fields (tracking number, carrier, status, received timestamp) and the scope of data (inbound mail/packages for specific accounts), which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers action and filters, second covers return fields and alternative tool. No wasted words, front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and zero required parameters, the description is fairly complete. It covers purpose, filters, return fields, and alternative. Could mention pagination settings (limit/offset) but those are in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions optional filters by status, carrier, and date, but the schema already documents all parameters with descriptions. The description does not add significant new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List inbound mail or packages for approved real mailing address/package beta accounts with optional filters', providing a specific verb and resource. It distinguishes from sibling tool list_inbound_mail by mentioning the account type and alternative for general context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('for approved real mailing address/package beta accounts') and explicitly indicates when not to use it ('For generally available inbound postal context, use list_inbound_mail'), providing a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds meaningful context: member-scoped aliases, live/sandbox key convergence, and the fact that the tool doesn't initiate OCR/uploads itself. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with the core action in the first sentence and supplementary context in the following two. Each sentence earns its place: the second clarifies the relationship to OCR, the third explains member-scoping. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and has an output schema (so return values are covered elsewhere), the description fully explains purpose, the role of the aliases, and notable behaviors. It is complete for a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per the baseline for 0 params, the description doesn't need to elaborate on parameters. It still adds useful context about what the aliases are for, which helps interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists private inbound forwarding aliases, using specific verb 'List' and resource 'renter’s private inbound forwarding aliases'. It further distinguishes this from uploading files into OCR and from siblings like list_inbound_mail by clarifying it's a discovery-only tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context of use: forwarding attachments initiates OCR, and this tool discovers the intake address without uploading directly. This implies when to use it (before forwarding) and when not (not for direct OCR upload), but doesn't explicitly name alternative tools for those actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and not destructive. Description adds valuable context: auto-resumes action when providing clarification response, requires sync verification. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose. Every word contributes: first sentence states function and three use cases, second adds critical requirement. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a mutation tool: covers purpose, detailed use cases, required parameter, and behavioral effects (auto-resume). Output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear. The tool description adds minimal extra meaning beyond the schema (only the sync verification requirement), meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'update' and resource 'action request', listing three distinct use cases (push notes, attach data, respond to clarification). Clearly distinguishes from siblings as no other tool updates an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to add reasoning, attach extracted data, or respond to clarification requests. Mentions requirement for mailbox_md_version. Does not explicitly exclude scenarios but covers primary use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: always test_mode=true, cost_cents=0, includes estimated_live_cost_cents and cost_breakdown, and queues a mail.submitted webhook. Annotations only indicate non-readonly, non-destructive, non-idempotent, so the description adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states purpose, second adds key behaviors and usage context. No redundant wording; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 10 optional parameters, nested objects, and output schema, the description covers core behavior (test-only, estimates, webhook) and usage context (sandbox rehearsal). It's sufficiently complete for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the overall effect of parameters (e.g., simulation for pricing, live estimates) beyond individual field descriptions. It does not detail each param but contextualizes them well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a sandbox outbound mail record without uploading a real document. It distinguishes itself from sibling tools like send_outbound_mail (real mail) and advance_test_outbound_mail (state progression) by focusing on simulated creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it with a sandbox key to rehearse workflows before real sending. While it doesn't explicitly list when not to use it or compare to all siblings, it provides clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds non-obvious behaviors: cursor-based pagination and automatically marking facility messages as read, which is valuable beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and output schema present, the description covers purpose, ordering, pagination, and side effects, making it complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context about pagination and reverse chronological order, but the schema already covers limit, before, and facility_id adequately. Some added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the message thread with a specific facility', using a specific verb ('Read') and resource ('message thread'). It distinguishes from sibling tools like list_facility_conversations (which lists conversations) and send_facility_message (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (reading a facility's messages) but does not explicitly contrast with siblings. It provides clear context but lacks explicit when-not-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the beta-access restriction and 'approved accounts' context, which is valuable behavioral information not present in the annotations. It does not explain what happens if beta access is missing, but this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the tool's purpose and access requirements, second provides an alternative. It is front-loaded, free of redundancy, and every sentence serves a distinct function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, a documented output schema, and clear annotations (read-only, idempotent), the description fully covers usage context. It also notes the beta access constraint and alternative tool, making it complete for practical decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameter details. The baseline for 0 parameters is 4, and no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the agent's real mailing address (street address + mailbox number) for beta-approved accounts, and explicitly distinguishes it from the sibling list_inbound_forwarding_addresses tool by noting that tool returns a private intake alias for general inbound context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: use this tool only for the beta mailbox address, and for generally available inbound context, use list_inbound_forwarding_addresses instead. This directly addresses alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint true, idempotentHint true, destructiveHint false. The description adds behavioral context such as caching the version and its role in sync verification for other tools, which is valuable beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: stating what the tool does and providing usage instructions. No superfluous text; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but indicated) and zero parameters, the description covers the key behavioral aspects: caching, sync verification necessity. Combined with annotations, it provides complete context for tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined; schema coverage is 100%. The description adds no parameter info because none exist. Baseline 4 is appropriate as no additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the renter's MAILBOX.md standing instructions, listing the specific return fields (full instruction text, version, content hash, last update timestamp). It is distinct from siblings like 'get_mailbox' by specifying the 'md' suffix and instructions context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this on startup and cache the version, and mandates passing it to send_outbound_mail and update_action for sync verification. This provides clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mailbox-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![mailbox-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/arbengine/mailbox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/arbengine/mailbox-mcp)

Score Badge

Copy to your README.md:

[![mailbox-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/arbengine/mailbox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/arbengine/mailbox-mcp)