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

With no annotations, the description carries the full burden and does so well: it discloses the ownership refusal, the required grant (read + send), the side effect that the owner sees a >_ agent mark with this agent's name on every device, and the destructive-ish semantics of an empty title clearing the label. It stops short of describing what an error or partial failure looks like, so it is not fully exhaustive.

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 primary action and its id-preserving nature are front-loaded, followed by exclusions, prerequisites, and side effects in a tight sequence. No sentence is padding; the owner-visibility note is a genuine behavioral disclosure, not filler.

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

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

For a six-parameter mutation tool with no annotations and no output schema, the description covers ownership, authorization, partial-update semantics, and visibility side effects. It omits error behavior and does not mention whether changing channel relocates the item, which is a modest remaining 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?

Schema coverage is 100%, so baseline is 3, but the description adds partial-update semantics ("Pass only the fields to change") and the empty-title clearing rule, which are behavioral rather than restatements. The channel parameter's role in moving an item is only covered by the schema, not the description.

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?

States a specific verb (change) and resource (an item this agent sent) with the deliberate constraint that the id is preserved, and explicitly separates itself from the sibling that handles file bytes (zas_replace_file). An agent can distinguish this from zas_send_note and zas_replace_file without opening any schema.

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?

Names the alternative explicitly ("A file's bytes change with zas_replace_file") and states the ownership precondition ("Refuses items sent by anyone else") plus the grant requirement. It also gives a usage rule for partial updates ("Pass only the fields to change"), 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?

With no annotations, the description carries the behavioral burden well: it discloses that files are written to disk, that dest defaults to a temp directory, that existing files are never overwritten, and that the returned path may differ from dest. It does not cover permissions, failure modes, or why the final sentence about what the owner sees applies to a fetch 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 key purpose is front-loaded, but the file-writing behavior is repeated across multiple sentences and the final sentence about the owner seeing every item this agent sends is off-topic for a get tool. Those issues make it less tight than it could be.

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 three-parameter tool with no annotations and no output schema, the description explains the important side effect and return value well: notes come back as text, files are written without overwriting, and the written path is returned. It still leaves out error behavior and any channel access requirements.

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, but the description adds useful semantics for dest and the returned path, including temp default and non-overwrite behavior. It adds little beyond the schema for channel and id.

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

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

The description states a specific verb and resource: fetch one item from a Zas channel. It also clarifies the two payload modes, note as text and file to disk, which distinguishes retrieval-by-id from list-oriented siblings such as zas_list_items.

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?

It implies retrieval by item id, but does not say when to use this tool versus zas_list_items or direct-receive siblings. There are no explicit alternatives, prerequisites, 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?

With no annotations the description carries the full burden, and it does disclose meaningful traits: results are ordered newest-first, each entry carries the phase reached and how it ended, returned job_ids are surfaced, and completed jobs retain their results here. It also notes the visibility model (owner sees items with the agent mark/name on every device). It stops short of stating read-only safety, pagination, or result limits.

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 sentences, front-loaded with the core action and ordering. The second sentence about owner visibility is the least essential and slightly tangential, but it is short and not padded.

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-only list tool with no output schema and no annotations, the description covers the important ground: what is listed, ordering, per-item fields, job_id retention, and result persistence. Missing only operational details such as pagination or result-count limits.

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 takes zero parameters, so the baseline is 4; there is no schema-level parameter meaning to add or compensate for.

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 gives a specific verb ('List') and resource ('the sends and Directo transfers this server started'), plus the ordering ('newest first') and the fields surfaced (phase, outcome, job_id). It is clearly distinguishable from write-oriented siblings like zas_send_direct, though it never names a sibling to sharpen the boundary against zas_list_items or zas_status.

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?

Usage is only implied: 'a finished job keeps its result here' suggests this is where you check the outcome of a prior send, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. zas_status) to route the agent. The final sentence adds context but not selection 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?

With no annotations, the description carries the full burden. It discloses the read-grant requirement and that results are ordered most-recent-first, which is genuinely beyond the schema. However, the final sentence about the owner seeing sent items with the '>_ agent mark' describes send behavior, not this list tool, so it is confusing rather than informative; return format and pagination remain undisclosed.

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?

Three short sentences, but the last one is off-topic for a list operation and consumes space without helping the agent decide or invoke. The essential scoping and auth facts are front-loaded, so structure is sound; content economy is not.

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

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

For a simple read-only two-parameter tool this covers purpose, auth, and ordering. Missing are return-shape hints (what an 'item' contains), pagination or cursor behavior, and any note on erroring when the grant is absent or the channel is unknown — gaps that matter more because no annotations or output schema exist.

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%, so both `channel` and `limit` (1–50, default 20) are fully documented in the schema. The description adds only the implicit notion of recency ordering and no format or id-vs-name nuance. Baseline 3 is appropriate since the schema does the heavy lifting.

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?

Uses a specific verb plus resource plus scope: 'List the most recent items in one of the owner's Zas channels.' An agent immediately knows this is a read-list operation scoped to a channel. It never distinguishes itself from siblings like zas_get_item or zas_receive_direct, so it stops short of a 5.

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

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

'Needs a grant that includes reading' states an auth prerequisite, which is useful. But there is no guidance on when to choose this over zas_get_item (single item) or zas_receive_direct (direct messages), and no exclusions. Usage is implied by the purpose rather than explicitly directed.

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 exist, so the description carries the whole burden, and it does disclose the important non-obvious traits: this is a multi-call asynchronous owner-approval handshake, re-pairing in an existing profile replaces the prior agent, and the owner sees this agent's mark and name on every device. It stops short of stating code expiry, rate limits, or what the first response contains besides a URL.

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?

Four short sentences, the action and the flow front-loaded with the conditional `code` case placed where the agent will need it. The closing sentence on the agent mark is mild extra detail but earns its place as visible-behavior disclosure.

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-optional-param pairing tool with no output schema and no annotations, the description covers the full interaction shape: initiation, polling, code fallback, and re-pairing semantics. Only the absence of any timeout or expiry guidance keeps it from being fully complete.

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 `code` at 100% coverage, and the description adds why it exists: it is the fallback for when the browser cannot reach this machine. That contextualizes a parameter an agent might otherwise supply blindly, though it doesn't give format specifics.

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?

Opens with a specific verb and resource: 'Pair this agent with a Zas account.' That is unmistakably distinct from the send/receive/status siblings, which all operate on already-paired data. An agent can pick this tool without opening the schema.

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?

Lays out the call sequence clearly: first call yields a URL for the owner, a later call reports approval, and a `code` argument is only needed when the page shows one. What's missing is any routing versus siblings (e.g. check zas_status first, or what to do if the profile is already paired beyond 'replaces the old agent').

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 the full behavioral burden and does so well: it discloses waiting behavior, a one-minute return with a job id, a possible ten-minute offer wait, no server-side storage, non-overwriting behavior, and the returned path. These are meaningful operational traits beyond the input 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 purpose and key constraints are front-loaded, and the async timing details are useful. However, the final sentence about the owner seeing items this agent sends is tangential for a receive tool and weakens the claim that every sentence 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 complex async receive operation with no output schema and no annotations, the description is largely complete: it covers prerequisites, waiting, job id follow-up, return path, and overwrite safety. It still omits failure/timeout behavior and does not name the fallback alternative.

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%, so both dest and channel are already documented in the schema. The description reinforces writing to disk and returning the path, but it does not add syntax or defaults beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description states a specific verb and resource: receive a file the owner sends through Directo and write it to this machine. It clearly explains the receive/write flow, but it does not explicitly name the fallback sibling used in other modes, so sibling differentiation is only implicit.

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?

It gives clear usage conditions: call it when the owner says they are sending something, only for a channel in Directo mode, and only with a grant that includes reading. It does not explicitly point to zas_receive_direct_fallback as the alternative for other modes.

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 does real work: it discloses that the copy is decrypted locally, that it is written to the same destination as the failed receive, and the gating condition on the sender's delivery choice. It does not say what happens on failure (missing copy, wrong sender choice) or whether the write overwrites an existing file, which keeps it below a 5.

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 core information (precondition, action, destination, parameter) is front-loaded and compact. The trailing sentence about the owner seeing agent-marked items is tangential to invoking this tool and slightly dilutes focus, but it is short and does not obscure the main instruction.

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 single-parameter, no-output-schema recovery tool, the description covers the precondition, the action, the local decrypt/write behavior, and the argument. The main missing piece is error/edge behavior when the sender did not enable reliable delivery or the stored copy is unavailable.

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% and the only parameter's description already says 'the job id zas_receive_direct or zas_jobs reported for the receive that failed'. The description's 'Pass the failed job's id' restates that without adding format or sourcing detail, so the baseline of 3 applies.

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 names a specific action (download the encrypted copy stored instead) and ties it directly to the recovery of a failed zas_receive_direct job, which cleanly separates it from the sibling zas_receive_direct and the other send/receive tools. An agent can tell exactly which operation this is without opening the schema.

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?

It states the triggering condition ('After a zas_receive_direct job failed in flight') and the prerequisite that the sender chose reliable delivery, which is enough to route correctly. It stops short of naming what to do when that prerequisite is not met (e.g. retry zas_receive_direct or report failure), so it is not fully explicit about alternatives.

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 the full burden and does so well: it explains preservation of item id/channel/pin, refusal conditions, return shape (item id or job id for uploads over a minute), and security cautions about secrets and owner visibility. This is rich behavioral context 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.

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

The description is front-loaded with the core action and then layers in constraints, return behavior, and visibility context without repetition. Every sentence adds useful information for an agent deciding whether and how to call the tool.

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?

There is no output schema, but the description explains the return value clearly (item id, or a job id for long uploads). Combined with refusal conditions and security notes, it is complete enough for correct invocation.

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 schema already documents all four parameters, including 'title' and 'channel' that the description does not discuss. The description adds slight context that 'path' refers to a file readable by this process, but it largely relies on the schema for parameter meaning.

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 precise verb ('Replace') and resource ('the bytes of a file this agent sent'), and clarifies that the existing item id, channel position, and pin are retained. This distinguishes it from sibling send operations that create new items.

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?

It clearly states when the tool will refuse: items sent by anyone else, notes, and items with a public share. That gives strong negative guidance, but it does not explicitly name an alternative sibling such as zas_send_file for sending a new file instead of replacing an existing one.

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 the full burden and does it well: nothing is stored, there is a ten-minute receive window, the call blocks for roughly a minute, and it returns either a result or a job id for zas_jobs. It also discloses the agent-attribution mark the owner sees and warns to confirm before sending secrets. Error behavior and what happens if the owner never presses Receive are left unstated.

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?

Front-loaded with the purpose and the transport model, then timing, then the return contract, then safety. Mostly earns its place, but the return behavior is stated twice ('returns a job id to check with zas_jobs' and 'Returns the transfer result, or a job id'), which is a small 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?

No output schema and no annotations, yet the description covers return shape (result or job id), the follow-up tool, the blocking latency, the human-in-the-loop requirement, and the sensitive-data caution. An agent has everything needed to call this correctly and interpret the response.

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 both parameters are already documented, establishing a baseline of 3. The description adds modest meaning — 'any file this process can read' clarifies the path scope, and the channel must be in Directo mode — but nothing about path formats, size limits, or what happens if multiple channels exist.

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?

States a specific verb and resource (send a file) plus the transport constraint: a live device-to-device transfer into a channel in Directo mode, with nothing stored. That distinguishes it from a stored-upload sibling in substance, though it never names zas_send_file or zas_send_direct_fallback as the alternatives.

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?

Prerequisites are clear (channel must be in Directo mode, owner must press Receive within ten minutes, the call blocks for about a minute). What's missing is routing guidance: no statement of when to use this versus zas_send_file or zas_send_direct_fallback if the owner is unreachable or the channel isn't in Directo mode.

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 the full behavioral burden and does so well: it explains encryption on the local machine, storage of only the encrypted copy in Cloudflare R2 for up to 24 hours, no use of owner space, later download by the claiming device, and that bytes pass through storage rather than remaining purely Directo. It also discloses the consent requirement and that the owner sees the agent mark and agent name on every device.

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 purpose is front-loaded and most sentences earn their place by clarifying the fallback behavior, consent requirement, parameter, and owner visibility. It is fairly long and somewhat jargon-heavy around "Directo", but the length is justified for a fallback operation with no annotations.

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 no-annotation fallback send tool with no output schema, the description covers the critical context: when it applies, what happens to the file, retention, privacy implications, consent, and parameter source. An agent has enough information to decide whether to use it and how to call it correctly.

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

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

There is only one required parameter and schema description coverage is 100%, so the schema already explains that job is the failed Directo send id reported by zas_send_direct or zas_jobs. The description adds "Pass the failed job's id" but no further syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: deliver the same file after a zas_send_direct job failed in flight. It explicitly distinguishes this fallback path from the original direct send, so an agent can tell exactly what the tool is for without opening the schema.

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 trigger condition is explicit: use this only after a zas_send_direct job failed in flight and pass that failed job's id. It also adds a clear prerequisite to ask the owner first, though it does not explicitly say not to use this for brand-new sends where zas_send_direct or zas_send_file should be chosen.

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 the burden well: it discloses the return contract (item id, or a job id when the upload exceeds a minute), the refusal behavior in Directo mode, and the visibility side effect (owner sees every item with the >_ agent mark and agent name on every device). It omits permission/size limits and any rate-limit or failure behavior, keeping it short of a 5.

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?

Four sentences, front-loaded with the action, then return contract, then the routing exception, then the safety and visibility notes. Every sentence carries distinct information with no repetition of the schema or title.

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?

No output schema exists, but the description explains the two possible return values, the async case, and the visibility side effect, which is what an agent needs to act on the result. Remaining gaps are secondary: file size limits, permission requirements on the target channel, and how the job id is later resolved (presumably via zas_jobs).

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 each of the four parameters is already documented in the schema, including the clamping behavior of expires_in_days. The description adds only a light constraint on path ("any file this process can read"), which is capability context rather than parameter syntax, so the baseline 3 applies.

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?

States a specific verb and resource ("Send a file from this machine into one of the owner's Zas channels") and explicitly carves out the case where it does not apply ("A channel in Directo mode refuses this tool: use zas_send_direct there"). An agent can distinguish it from the direct-send siblings without opening either schema.

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?

Gives a concrete when-not condition (Directo-mode channels) plus the named alternative, and adds a safety precondition ("confirm with the owner before sending secrets, keys or credentials"). It does not distinguish itself from other siblings like zas_replace_file or zas_send_note, so routing guidance is clear but not exhaustive.

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 the full burden, and it does disclose a genuinely non-obvious trait: everything sent is visible to the owner on every device and is stamped with the >_ agent mark and the agent's name. That is real value beyond the schema. However, it says nothing about permissions or auth needs, rate limits, failure behavior, or whether the call returns an identifier for the created item.

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 tight sentences, front-loaded with the action and destination, with no filler. The trailing visibility clause is slightly redundant ('owner sees every item' and 'on every device') but earns its place as the key trust signal.

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 tool has no annotations and no output schema, so the description must cover behavior, and it covers visibility but not the return value or error modes — notably whether an item id comes back that could feed zas_get_item or zas_edit_item. Parameter detail is fully carried by the schema, so the gap is behavioral rather than parametric.

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%, so all six parameters (including secret, expires_in_days, channel) are already documented in detail, which sets the baseline at 3. The description only adds the text-vs-snippet framing and the multi-channel destination, which is marginal over what the schema already conveys.

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?

States a specific verb and resource ('Send a note') plus the payload variants it accepts (plain text or code snippet with language) and the destination (one of the owner's Zas channels). It does not name or contrast itself with siblings like zas_send_direct or zas_send_file, so the distinction between a channel note and a direct message is left implicit.

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 explicit statement of when to use this tool versus zas_send_direct, zas_send_file, or zas_edit_item. The only conditional guidance ('Optional when the agent holds exactly one channel') lives in the schema, not the description, so an agent gets no routing help from the prose.

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 the full burden, and it does disclose a meaningful behavioral trait: the owner sees every item sent by this agent with the >_ agent mark and agent name on every device (an auditing/visibility property). It does not explicitly confirm the call is side-effect-free or describe behavior when unpaired.

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 sentences, front-loaded with the core purpose (pairing status plus channel list). The second sentence about owner-visible agent marking is somewhat tangential to invocation but adds legitimate context, so it earns its place without bloat.

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?

With no annotations and no output schema, the description must convey return content, and it does: pairing status plus the list of channels the agent may send to or read from. It omits the unpaired/error case and any note on caching or refresh, but is otherwise complete for a zero-parameter status 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?

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4 and there are no parameter semantics for the description to add. Nothing is missing on this dimension.

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?

States a specific verb and resource: reports whether the agent is paired with a Zas account and lists the owner's channels available for send/read. It is clearly distinguishable from zas_pair, but it never names a sibling or scope boundary explicitly, so it stops short of full 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?

Usage is only implied: an agent can infer this is a status/introspection check, likely before sending. There is no explicit when-to-use, when-not, or alternative (e.g., 'use zas_pair if not yet paired'), so the guidance is adequate but thin.

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