Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, and the description adds value by specifying the return contents (account info, piece counts). However, it doesn't mention permissions, error behavior, or side effects, though these are less critical for a read operation.

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 a single, efficient sentence with no filler. The key information (specific inbox, account info, piece counts) is front-loaded and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with one required parameter and no nested objects, the description is largely sufficient. It states what the tool does and hints at the response contents. A return schema would improve completeness, but the description adequately covers the essential context needed to call the 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 description coverage is 100%—the single parameter inbox_id is described as 'The inbox ID to retrieve'. The tool description adds no additional parameter semantics beyond what the schema already 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get details') and a specific resource ('a specific inbox'), and even previews the returned data ('account info and piece counts'). This clearly distinguishes it from sibling listing tools like ecm_list_inboxes.

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 phrase 'specific inbox' implies the caller must already have an inbox ID, and the required parameter reinforces this. It doesn't explicitly contrast with ecm_list_inboxes or other siblings, but the context is clear enough for a simple get-by-ID operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries more responsibility. It adds useful behavioral context in the include_media description: full media URLs are 'very long,' default to false, and should be enabled only when images are needed. However, it does not describe the response structure, potential errors, or whether any auth/scoping constraints apply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise, front-loaded sentence, and the parameter descriptions are economical. No filler or redundant restatement of the tool name appears.

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?

The definition is adequate for a simple two-parameter lookup with no output schema, and the include_media note improves completeness. However, it leaves ambiguity with ecm_get_piece_content and does not specify what 'detailed information' includes, so an agent may not know exactly what to expect or which sibling to pick.

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%, so the baseline is 3. The description adds value beyond the schema by explaining why include_media defaults to false (URLs are very long) and when to set it to true (need scanned images). This extra rationale helps the agent make a deliberate parameter choice.

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 clear verb and resource: 'Get detailed information about a specific mail piece,' and mentions scanned content URLs as part of the response. It does not explicitly contrast itself with the sibling ecm_get_piece_content, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to choose this tool over ecm_get_piece_content or ecm_list_pieces; it only states what the tool does. The include_media parameter offers conditional guidance for one optional flag, but no tool-selection context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the burden. It does disclose the primary behavior — returning a scanned PDF and/or envelope images — which is useful for a read-only fetch. However, it does not describe the output format (e.g., binary, base64, URL), error behavior, or what happens when no content exists, so transparency is partial.

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 compact and front-loaded: the first sentence states the core action and subject, and the second clarifies the return payload. Every word contributes to understanding, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter getter with full schema coverage, the description is reasonably adequate. However, with no output schema and no annotations, it leaves key context unspecified: the exact shape of the returned data, how 'all' behaves in practice, and any failure or empty-result semantics. An agent may still be unsure how to consume the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters already have meaningful descriptions. The tool description adds minimal semantic value beyond the schema; it reinforces the PDF/image distinction but does not explain additional parameter nuances or dependencies.

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 clearly states the action 'Get' and the resource 'scanned content (PDF or images) from a mail piece'. It also specifies the return types (scanned PDF and/or envelope images), making the tool's function unambiguous and distinct from more general ECM operations.

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 implies the usage context: when you need the scanned content of a mail piece. However, it provides no explicit guidance about when to use this tool over alternatives, no exclusions, and no mention of related tools for metadata or other mail piece operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full behavioral burden. It clearly signals a read-only fetch operation, but it does not mention authentication requirements, possible errors, or what response shape to expect.

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 a single front-loaded sentence with no filler. Every word contributes meaning: 'current', 'Earth Class Mail', and 'user profile information' all clarify scope and intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool, the description is largely complete: it identifies the operation and the target resource. It lacks detail about which profile fields are returned, but the simplicity of the tool limits the impact of that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds useful context about the resource being 'current user profile' even though no parameters need explanation.

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 starts with a specific verb ('Get') and names a clear resource: the current Earth Class Mail user profile. It is immediately distinguishable from sibling tools focused on inboxes, pieces, and actions.

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 implies when to use it: whenever the current user's profile information is needed. However, it does not explicitly contrast it with sibling tools or state when not to use it, so guidance is largely implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses the listing operation and the inclusion of piece counts, but it does not mention pagination, ordering, whether the operation is read-only, or edge cases like ineligible inboxes. This is adequate for a simple zero-parameter tool but leaves some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one front-loaded, efficient sentence. It conveys operation, scope, and expected output content without any filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list operation with no output schema, the description is nearly complete. The 'with piece counts' detail helps set expectations for the return payload, but it does not name returned fields or connect to sibling tools like ecm_get_inbox for follow-up actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is nothing for the description to document. The description correctly implies that the tool requires no arguments and operates across the entire account.

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 the specific action ('List all') and resource ('mailbox inboxes'), scoped to the user's Earth Class Mail account, and includes a meaningful output trait ('with piece counts'). It is clearly distinguishable from the singular sibling ecm_get_inbox.

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 phrase 'List all mailbox inboxes' makes the use case clear: call this when you need to enumerate inboxes, not when you need a single inbox or individual pieces. It does not explicitly name alternatives or when-not-to-use conditions, so it falls just short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that the return value is only a summary, not full piece details, and that media URLs are excluded. The 'List' verb makes the read-only intent obvious, though it does not explicitly mention pagination or filtering behavior; those are covered in 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short, purposeful sentences with no filler. The core action is front-loaded ('List mail pieces in an inbox'), and the alternative-tool pointer is packed into a compact parenthetical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with a well-described schema, the description is complete enough to support correct selection and invocation. It clarifies the summary nature of the output and routes the agent to ecm_get_piece for richer data. Pagination and unread filtering are fully documented in the schema, so no critical context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all four parameters (inbox_id, page, per_page, unread_only), so parameter documentation coverage is 100%. The description itself adds no parameter-specific meaning beyond what the schema already states, making the baseline score of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List mail pieces in an inbox.' It also differentiates itself from ecm_get_piece by clarifying that this tool returns only a summary, while ecm_get_piece provides full details including media URLs. An agent can immediately determine what this tool does and how it differs from its sibling.

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 parenthetical gives explicit routing guidance: use ecm_get_piece when full details or media URLs are needed, implying this tool is for summary-level listing. This is clear when-to-use and when-to-use-alternative guidance, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the behavioral burden. It communicates a read-only listing operation and that all recipients are returned as names, but it does not disclose pagination, ordering, authentication needs, or whether the result is a flat array of names. These gaps are notable but not fatal for such a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one focused sentence that front-loads the verb and resource, then adds a clarifying parenthetical. Every word earns its place; there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only list tool with no annotations or output schema, the description is nearly complete. It explains what will be returned ('names on your mailbox') and what input is needed. Minor omissions like output shape and absence of pagination details are acceptable at this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the single parameter fully: 'The inbox ID to list recipients for'. The tool description only restates the same inbox relationship and adds no new meaning about parameter format, constraints, or expected values. With 100% schema coverage, baseline 3 is appropriate.

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 clearly states the action ('List all recipients') and the resource scope ('for an inbox'), and clarifies the meaning of recipients as '(names on your mailbox)'. It is not a tautology and the inbox scoping distinguishes it from listing inboxes or pieces, though it does not explicitly name a sibling alternative.

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 gives clear context for when to use the tool: after having an inbox_id and wanting its recipients/names. It does not explicitly state when not to use it or name alternatives, but the inbox_id anchor is sufficient for a simple listing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full transparency burden. It discloses that some actions may not be available via API, which is helpful, but it does not state what each action does, whether actions are destructive (e.g., shred), what permissions are required, or what the response looks like. For a mutation tool, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with no filler. The main action list is front-loaded, and the availability caveat is placed second. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description covers the core invocation and warns about unavailable actions. However, it leaves out expected outcomes, error conditions, and whether operations are asynchronous or immediate, making it only partially complete for an agent deciding how to handle the result.

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%, so the baseline is 3. The description adds 'move-to-inbox' as an example of an unavailable action, which is extra context beyond the schema's enum. However, the parameter meanings themselves (piece_id, action) are fully documented in the schema, so the description adds only marginal value.

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 action on a specific resource ('Perform an action on a mail piece') and enumerates the working actions: scan, shred, ship, archive. This clearly distinguishes it from the read-only sibling tools (list/get/inbox content), so an agent can tell what this tool does at a glance.

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 implies usage for the listed actions but never explicitly says when to choose this tool over alternatives. It does provide a useful availability warning ('move-to-inbox and some other actions may not be available via API'), yet there is no direct guidance about when not to use it or which sibling might be a fallback. Context with read-only siblings implies this is the mutation tool, but that is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.