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

No annotations are provided, so the description carries the full burden. It discloses the authorization requirement (channel creator or mesh admin only) and a precondition on the target user's state, which are non-obvious behavioral traits. It could go further on idempotency or what happens on re-add, but the core constraints are well covered.

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 action and qualification, with no wasted words. The authorization note is tucked into the parenthetical efficiently.

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 two-parameter mutation with an output schema, the description supplies the authorization rule, the accepted formats for the user identifier, and the mesh-membership precondition. An agent has what it needs to call this 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?

Schema coverage is 0%, so the description must compensate. It does: 'user' is explained as a username, display name, or UUID, and the channel is implicitly the target channel. This adds real meaning beyond the bare string-typed schema.

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

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

States a specific verb and resource ('Add a mesh member to a channel') and clearly distinguishes from sibling remove_channel_member and list_channel_members. The parenthetical rule reference (§88a) further disambiguates the operation.

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 clear when-to-use context: channel creator or mesh admin only, and the user must already be an accepted mesh member. It does not explicitly name alternatives, but the constraints effectively tell the agent when this tool will and won't work.

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 burden. It implies a read-only status check (enrolled key and its kid) but does not explicitly state that there are no side effects or auth requirements beyond the implicit identity of the caller. Adequate but thin for a zero-annotation 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?

A single sentence, front-loaded with the core question and the returned field (kid). No 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-param, output-schema-backed status tool, the description covers the core question and output field. An output schema exists, so return-value detail is not required. It is complete enough for an agent to call 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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly indicates no inputs are needed to perform the status check.

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 query about the caller's enrolled agent key and its kid. The resource is clear, though the phrasing restates the name somewhat. It sits adjacent to sibling tools like enroll_agent_credential and revoke_agent_credential, but does not explicitly distinguish itself from them.

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 context is implied (check current enrollment state) but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives like revoke_agent_credential or enroll_agent_credential that an agent might choose instead.

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 full burden, yet it discloses almost nothing behavioral: no permissions/auth requirements, no size limits (a real constraint for base64 uploads), no note on overwrite/duplication if a file with the same name already exists. 'base64 JSON lane' hints at encoding but gives no size or payload implications.

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?

A single dense sentence that front-loads the action and packs the entity-type list inline. Efficient, though the entity enumeration makes it long-ish and the trailing 'base64 JSON lane' phrase is jargon with no unpacking.

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 mutation tool with zero annotations and 0% schema coverage, this is too thin. An output schema exists so return values need not be described, but auth requirements, size/format constraints, and identifier semantics are all 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?

Schema description coverage is 0% and the description only marginally compensates. It implies path is a local filesystem path and enumerates entity_type values, but entity_id is never explained (which identifier? name vs numeric id?) and no parameter syntax or format is given.

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?

Clear verb+resource: 'Attach a local file to an entity'. It enumerates the valid entity types, which usefully narrows scope beyond what the schema provides (entity_type has no enum). No sibling does file attachment, so differentiation is implicit but adequate.

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?

No when-to-use guidance, no prerequisites, and no mention of the alternative download_attachment sibling or when this lane applies versus other attachment mechanisms. The 'base64 JSON lane' hint is the only usage cue and it is not explained.

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 discloses one genuinely non-obvious behavior: 'company' is free text and the server resolves it to an existing company when possible. This is valuable, but it omits permissions, duplicate handling, and side effects for a mutation 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?

Two tightly written sentences, front-loading the core purpose and then the one parameter caveat. No wasted words.

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?

An output schema exists, so return values need no explanation. However, for a mutation tool with no annotations and zero schema coverage, the description should say more about failure modes, required permissions, or duplicate behavior to be 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?

Schema coverage is 0%, so the description must compensate. It explains the least obvious parameter ('company' free-text resolution), which is the highest-value gap, but first_name, last_name, and email receive no added semantics, so compensation is only partial.

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 ('Create a CRM contact') plus the scoping context ('active mesh'), so the agent knows what operation it performs. It does not explicitly distinguish itself from the sibling create_lead, leaving a minor ambiguity between the two creation tools.

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?

No when-to-use guidance is given. There is no indication of when to create a contact versus the sibling create_lead, nor any prerequisites or conditions for use.

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 provided, the description carries the full behavioral burden and does disclose meaningful traits: creation happens in the active mesh's default pipeline at the first stage, implying no pipeline/stage selection. It omits auth/permission requirements, what happens if the contact lookup fails, and whether a pipeline must exist, which are the real risks for a mutation tool with zero annotation coverage.

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 with the primary action front-loaded, followed by parameter clarifications and the next-step pointer. No filler or restatement of the tool name.

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 3-parameter mutation tool, the description covers placement, the two ambiguous parameters, and the follow-up action, and the existing output schema removes any need to describe returns. It stops short of covering permission requirements or failure modes when the referenced contact does not 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 0%, so the description must compensate, and it does for the non-obvious parameters: 'contact links a CRM contact by name or UUID' clarifies the accepted identifier forms, and 'value is the deal amount' disambiguates a bare number. 'title' remains unexplained, so it falls short of full compensation.

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 verb and resource ('Create a lead') plus the exact placement scope ('the active mesh's default pipeline (first stage)'). It also distinguishes itself from the sibling create_contact and routes the agent to move_lead_stage for the next step, so it is identifiable 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 gives clear workflow context by stating the lead lands in the default pipeline's first stage and that move_lead_stage is the follow-up action. It does not, however, state any when-not conditions or contrast itself with the sibling create_contact, so the guidance is contextual rather than explicit routing.

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 usefully discloses one behavioral rule (if out_path is a directory, the server-provided filename is used) and that it writes to local disk, but omits overwrite behavior, permission/auth requirements, and error handling for an attachment download.

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 each sentence adds non-redundant information. No filler.

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

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

For a simple two-parameter download with an output schema (so return values need not be explained), the description covers the action, destination, and filename-resolution rule. It leaves minor gaps around overwriting and permissions, but is largely complete for the tool's complexity.

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 0%, so the description must compensate. It identifies attachment_id as an entity attachment UUID and gives meaningful semantics for out_path (directory vs. file handling), but does not document UUID format, path format, or expected values for a tool with two fully undocumented required parameters.

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+resource ('Download an entity attachment by UUID') and the side effect ('save it locally'), which distinguishes it from sibling write tool attach_file. It does not explicitly name or contrast with a sibling alternative, 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?

There is no guidance on when to use this tool versus alternatives such as attach_file, nor prerequisites or exclusions. Usage is only implied by the verb 'Download'.

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 discloses that the RSA keypair is generated locally, that the private key is never transmitted, where it is stored, that re-running overwrites the existing key, and what is returned. It omits auth/permission requirements and rate-limit 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?

Front-loads the core action, then layers in the security-critical detail (local keygen, never transmitted) and the constraints. Dense but every sentence carries information; the parenthetical digressions make it slightly less scannable than a tight 5.

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, side-effecting tool with an output schema, the description covers the operation, security model, prerequisites, and idempotency. Return values are covered by the output schema, so nothing essential is missing, though auth/permission prerequisites are not stated.

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 nothing extra for the description to document, and it correctly implies the operation is parameterless.

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 (self-enroll) and resource (non-human auth credential), and clearly distinguishes itself from siblings like revoke_agent_credential and agent_credential_status. An agent knows exactly what this tool produces: a registered public key plus kid and token endpoint.

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?

Explicitly names the precondition 'Non-human members only,' which drives selection over alternatives, and notes the prerequisite package ('cryptography') and idempotency behavior ('Re-running replaces the existing key'). It does not explicitly name a sibling alternative, but the gating condition is clear.

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 burden. It discloses the required privilege level (admin/account-manager), the async nature of the operation, the readiness polling pattern, and a key gotcha: the archive link expires. It doesn't describe whether the export is destructive, rates, or the size of the response, but covers the behavioral essentials well.

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?

Every clause earns its place: purpose, identifier form, permission gate, polling step, download path, and expiry warning. Front-loaded with the action and no 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?

Output schema exists, so return values need not be explained. The description fills in the async workflow, permissions, and expiry caveat, which the schema and (absent) annotations cannot. Complete enough for an agent to invoke correctly, though it doesn't state how long to poll or what export_status returns.

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 0% with one undocumented parameter, so the description must compensate. It does, by naming the accepted identifier forms (UUID or name) for mesh_id. One parameter with no other constraints, so this is sufficient.

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 (Start a full data export) plus the resource (mesh) and the identifier form (by UUID or name). This is clearly distinguishable from export_status and download_attachment in the sibling set.

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?

Explicitly states when to use (start an export) and routes the agent through the full workflow: poll export_status until 'ready', then download from the SPA rather than the API. Names the alternative tool (export_status) and the admin/account-manager precondition.

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. It usefully reveals the status progression pending → running → ready (or failed) and that mesh_id accepts UUID or name, but it omits permission requirements, rate limits, what 'recent' means, and whether the operation is read-only.

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?

Extremely concise: one sentence plus a compact status chain. Information is front-loaded and every element 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?

The tool is simple with one required parameter and an output schema, so return values need not be described. The description supplies the status lifecycle and accepted mesh_id formats. It is nearly complete, though usage guidance remains thin.

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 0%, so the description must compensate. It adds meaningful semantics by stating that mesh_id can be a UUID or a name, which is not present in the input schema. The remaining ambiguity is minor for a single-parameter tool with an output schema.

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

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

States a specific verb and resource: 'List recent exports for a mesh ... with their status.' The status lifecycle and the word 'exports' distinguish it from export_mesh, which likely initiates an export. However, it does not explicitly name the sibling tool or contrast with 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?

No guidance is given on when to use this tool versus alternatives such as export_mesh or other list tools. It does not state prerequisites, when-not conditions, or the practical scenario for checking export status.

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 provided, the description carries the full behavioral burden. It discloses a key authorization behavior: the server refuses if you cannot see the channel, and clarifies that private-channel results are the access list. It does not mention pagination or ordering, but for a simple read-only listing this is substantially transparent.

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 short sentences, front-loaded with the tool's purpose. Every phrase adds information, and the private-channel behavior is compactly stated.

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 is simple, output schema exists, and the description covers the main read behavior plus the private-channel authorization nuance. However, it leaves the sole required parameter completely unspecified and offers no sibling differentiation, so it is minimally adequate rather than 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?

Schema description coverage is 0% and there is only one parameter, channel. The description does not explain what form the channel identifier takes (name, ID, slug) or any other constraint. It gives no meaning beyond the schema itself.

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 identifies the resource: members of a channel. It goes further by noting that for private channels this is the access list, which helps distinguish the tool from generic channel reads. However, it does not explicitly name sibling tools like list_channels or list_mesh_members to clarify selection.

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 context is implied: use this to see who belongs to a channel. The private-channel access-list detail adds useful scope, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling tools.

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 must carry the behavioral load. It discloses a genuinely useful access rule — private channels (§88a) appear only if you are a member — but says nothing about ordering, pagination, or the fact that results are scoped to the active mesh session (only implied). Decent but incomplete for a zero-annotation 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?

Two short sentences, scope statement front-loaded followed immediately by the visibility exception. No filler, nothing redundant.

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?

An output schema exists, so return shape needn't be described, and with zero parameters the schema covers the input side entirely. The only residual gaps are ordering/pagination behavior, which are minor for a small enumerating 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, so there is no per-parameter semantics to convey; the baseline for parameterless tools is 4.

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 (List) and resource (channels) plus a scoping constraint ('visible to you in the active mesh'), which cleanly separates it from read_channel (single-channel read) and list_channel_members. It does not explicitly name a sibling, so it falls just short of 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?

The use case (enumerate the channels you can see) is implied by the verb and scope, and the private-channel visibility rule hints at the filtering model, but there is no explicit when-to-use/when-not guidance or routing to alternatives such as search_chat or read_channel for deeper lookups.

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 burden. 'List' signals a read-only operation and the mesh scoping is disclosed, but nothing is said about result limits, pagination, or ordering. It adds some behavioral context but leaves notable 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?

A single front-loaded sentence that covers action, scope, and the filter. No 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?

An output schema exists, so return values need not be described. For a simple single-parameter list tool the description is nearly sufficient, losing only a note on result volume or ordering.

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?

With schema description coverage at 0% and one undocumented parameter, the description compensates by explaining that 'query' is a search term matched against name, email, and company — meaning the schema alone would not supply.

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+resource ('List CRM contacts') and adds the scoping constraint 'in the active mesh'. It does not explicitly differentiate from the sibling create_contact or list_leads, but the read operation is unambiguous.

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 word 'optionally filtered' implies two usage modes (list-all vs search), which is implied guidance, but there is no statement of when to prefer this over list_leads or how search relates to those siblings.

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 usefully discloses that results are scoped to the 'active mesh' (implying a dependency on set_active_mesh), but says nothing about pagination, result limits, permissions, or read-only safety. Some genuine context, but far from complete.

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, purpose first, filter semantics second. No filler and nothing redundant with the schema.

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?

An output schema exists, so return values need not be explained, and the one parameter is covered. However, with no annotations and no mention of pagination or volume expectations for a list operation, an agent lacks confidence about result set size and iteration.

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 0% and the single `stage` parameter is undocumented in the schema, so the description's note that it accepts a stage name or UUID provides real added meaning. It stops short of describing default/null behavior or valid stage values.

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+resource ('List CRM leads') and a scoping constraint ('in the active mesh'), which separates it from create_lead and move_lead_stage siblings. It does not explicitly differentiate itself from the other list_* siblings, so it falls just 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?

The description says what the tool returns but never when to reach for it versus alternatives like list_contacts or search_chat, and offers no prerequisites or exclusions. Usage is only implied by the verb 'List'.

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 one meaningful trait: the underlying roster is 'gated on membership,' so a caller knows authorization is required. It says nothing about pagination, result size, error behavior, or whether invitations/join requests can be absent. Useful but incomplete for an annotation-free 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 first sentence is well-formed and front-loaded, but the entire second paragraph is an engineering changelog (author, date, report number, endpoint archaeology) that carries zero selection or invocation value for an agent. Roughly half the description is noise.

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?

An output schema exists, so return values need not be restated. For a read-only, single-optional-parameter list tool with a disclosed membership gate and a documented default, the agent has enough to call it correctly. Only the absence of any sibling routing keeps it from a 5.

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 0% and the single parameter is documented only as anyOf string/null with default null. The description compensates by explaining that omission resolves to the active mesh, giving the null default real meaning. That is a genuine addition over the schema, though no format or ID-source detail is offered.

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 opening sentence names the resource (mesh members) and enumerates what comes back: members with roles, humans vs AI, pending invitations and join requests. That is far more specific than a tautology and implicitly separates it from list_channel_members. It stops short of an explicit sibling contrast, so a 4 rather than 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?

'Defaults to the active mesh' tells the agent what happens when mesh_id is omitted, which is genuine usage context. However, there is no statement of when to reach for this over list_channel_members, list_my_meshes, or whoami, and no exclusions. Usage is implied rather than guided.

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 must carry the full behavioral burden; it does disclose the returned fields and the active-mesh indicator, which is useful context. It omits any mention of permissions, pagination, or side effects, which matters since it is a list operation with no annotations.

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

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

The description is a single, tightly scoped sentence that front-loads the operation and follows with the returned fields. It is efficient and contains no filler, though the parenthetical list slightly delays the core action.

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?

An output schema exists, so the description need not explain return formats, and it still names the key fields for quick orientation. Combined with zero parameters, the definition is nearly complete; only explicit usage context and behavioral notes like permissions are 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 tool has zero parameters, so parameter semantics baseline is 4. There is nothing to clarify in the description, and it appropriately does not invent parameter details.

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: it lists the meshes the current user is a member of. This distinguishes it from sibling list_mesh_members, which would list members of a mesh rather than meshes of a user. However, it does not explicitly name or rule out any sibling, so 5 is not warranted.

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 'you're a member of' implies a personal scope, and the mention of active status hints at usage related to mesh selection, but there are no explicit when-to-use rules, exclusions, or named alternatives such as set_active_mesh or list_mesh_members.

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 does disclose meaningful behavior — results are identity-scoped ('your own'), mesh-scoped ('active mesh'), and filtered to exclude Done/Cancelled — but says nothing about ordering, pagination, or whether tasks from other meshes appear. The filter semantics are the strongest contribution; the operational traits are absent.

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?

A single sentence that front-loads the verb and scope, then parenthetically defines the 'open' filter. Nothing is wasted and nothing essential is buried.

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 listing tool with an output schema and full schema coverage, the definition covers scope and filtering well. Ordering and pagination behavior are the only notable omissions, and those may be handled by the output schema.

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 of 4 applies; there is nothing for the description to clarify beyond the implicit filter that defines the result set.

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 (your own open tasks) and then bounds the result set precisely: active mesh, excluding Done/Cancelled. No sibling in the toolset lists tasks, so there is no ambiguity to resolve against alternatives, and an agent can tell this apart from mark_task_done immediately.

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 implied rather than stated: it returns the caller's open tasks, which makes the intent self-evident, but there is no explicit 'use this when' clause, no mention of the alternative (mark_task_done for closing tasks), and no guidance about switching the active mesh first. Adequate but thin.

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 does not say whether listing unread notifications marks them as read, whether results are paginated or capped, or whether any auth scope is required — all material for a notification 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?

A single front-loaded sentence with no wasted words; the resource and the key filter (unread) appear immediately.

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?

An output schema exists, so return values need not be described. However, with no annotations and no guidance, the description leaves open the side-effect question (does reading clear unread status?) and any result limits, which a zero-param list tool should ideally address.

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, which is the baseline 4 case. Schema coverage is 100% and there is nothing further for the description to clarify about inputs.

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 (List) and resource (unread meshbook notifications) and enumerates example types (mentions, invites, assignments), so the agent knows exactly what it returns. No sibling tool covers notifications, so differentiation is not really needed, but there is no explicit contrast with any list_* 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 word 'unread' implies a use case, but the description gives no when-to-use guidance, no prerequisite context, and no alternatives. There is no other notification tool to route against, yet nothing tells the agent when this call is appropriate.

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, and it discloses almost nothing. It implies a state mutation but says nothing about permissions required, reversibility, behavior when the task is already Done, or error conditions.

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 single sentence is front-loaded and wastes no words, but here brevity reflects under-specification rather than economy. There is no filler, yet the space saved is not used to convey anything an agent could act on.

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?

An output schema exists, so return values need not be explained, but for a mutation tool with no annotations and 0% parameter coverage the description is inadequate. Critical context — task_id provenance, idempotency, and failure behavior — is missing entirely.

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 0%, so the single parameter task_id is undocumented in the schema and the description does not compensate. It never states what a task_id is, its format, or where the agent obtains it, which is the main practical gap for a one-parameter tool.

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 recognizable action on a recognizable resource (mark a task as Done), so the core purpose is understandable. However, it adds essentially nothing beyond the tool name 'mark_task_done' — no scope, no state-check semantics, and no differentiation from the sibling list_my_tasks, which is the tool an agent would need to find the task first.

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 on when to use this tool versus alternatives, nor any prerequisite context. It does not mention that a task_id must first be obtained (e.g., from list_my_tasks), nor whether the action is idempotent or fails on already-completed tasks.

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 for a mutation tool, yet says nothing about side effects, whether stage history is overwritten, permission requirements, or whether the move is reversible. Only the mutation itself is implied by 'Move'.

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?

A single front-loaded sentence with zero filler; the parenthetical clarifies the parameter without bloating the sentence.

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?

An output schema exists, so return values need not be described. However, for a mutation tool with no annotations and 0% schema coverage, the missing note on side effects and prerequisite state leaves gaps an agent would want covered.

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 0%, so the description must compensate. It usefully clarifies that 'stage' accepts either a stage name or a UUID, adding real meaning beyond type:string, but 'lead_id' is left completely unexplained.

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 (move), resource (lead), and target (pipeline stage), which is enough to distinguish it from the sibling list_leads and create_lead. It does not explicitly name or contrast against an alternative, but the purpose is unambiguous.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. An agent isn't told under what conditions moving a stage is appropriate or what must exist beforehand.

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 burden; it usefully discloses that content is markdown and the accepted channel identifier forms. It says nothing about authentication requirements, whether the post is editable/deletable, mention or notification behavior, or rate limits for a mutation 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?

Two tight sentences with no filler, and the core action is front-loaded. The identifier-format detail is appended where it belongs rather than padding the opening.

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?

An output schema exists, so return values need not be described. However, for a mutation tool with no annotations and 0% schema coverage, the definition omits who may post, which mesh is 'active' or how it is determined, and what a successful post yields.

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 0%, so the description must compensate. It does clarify the 'channel' parameter (name with or without '#', or UUID) and implies the 'message' parameter is markdown, but adds no constraints such as length limits or formatting rules for the second parameter.

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?

Specific verb ('post') plus resource ('markdown message to a channel') with scope ('in the active mesh'), so the agent immediately knows the action. It does not name or contrast with the sibling post_chat, leaving the channel-vs-chat distinction to be inferred.

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?

No explicit when-to-use, prerequisites, or alternatives are given. The existence of post_chat, read_channel, and list_channels in the sibling set means an agent needs guidance on choosing among them, which the description does not supply.

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 burden. It usefully discloses that the target is implicitly the 'active mesh's main chat thread' (no target parameter) and that reply_to does threading, but says nothing about permissions, rate limits, error behavior, or editability.

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 tightly written sentences with zero waste; the core action is front-loaded and the parameter note follows efficiently.

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?

A simple two-parameter tool with an output schema (so return values needn't be explained). The description is nearly complete, missing only permission/error context that would round it out.

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 0%, so the description must compensate. It does explain reply_to ('threads it under an existing message UUID'), which clarifies the parameter's purpose, but 'message' is left entirely to the schema.

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

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

States a specific verb ('Post'), format ('markdown message'), and target ('active mesh's main chat thread'). The 'main chat thread' scope implicitly differentiates it from the sibling post_channel, though post_channel is never named explicitly.

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?

No explicit when-to-use or when-not-to-use guidance, and no alternative named. Usage is only implied by the description's specification of target ('main chat thread'), letting the agent infer it from the sibling post_channel.

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?

Annotations are absent, so the description carries full behavioral burden. It discloses ordering ('oldest first') and that the channel lives in the 'active mesh', but says nothing about read safety, pagination, missing-channel behavior, or result window semantics.

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 short sentences, front-loaded with the action and back-loaded with the parameter format note. No filler. Could better order or flag the limit gap, but it is tight.

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?

An output schema exists so return values need not be described. The channel format note is a real addition, but with 0% schema coverage on the ambiguous limit parameter, the definition is only partly complete for a 2-param tool.

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

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

Schema coverage is 0%, so the description must compensate. It explains the channel parameter's accepted forms (name with or without '#', or UUID), which is genuinely useful. The limit parameter (default 20) is left entirely undocumented in both schema and 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 (read) and resource (recent messages from a channel), plus ordering semantics ('oldest first'). It does not explicitly name or differentiate from sibling read_channel/post_channel/read_thread, but the resource is clear enough to distinguish.

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?

No when-to-use guidance, no exclusions, and no mention of alternatives like read_thread or search_chat. The agent gets no signal about when reading recent messages is preferable to those siblings.

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 full burden. It usefully discloses the ordering ('oldest first') and that messages are recent, but says nothing about read-only semantics, auth requirements, pagination/truncation behavior, or what happens when the thread is empty.

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?

A single tight sentence with the resource and ordering front-loaded and no filler. Every clause 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?

An output schema exists, so return values need not be explained, but the lone parameter is undocumented in both schema and description, leaving an agent guessing at the meaning of 'limit'. Adequate but with a clear gap for a tool this simple.

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 0% for the single 'limit' parameter, and the description never explains it — the word 'recent' hints at a window but gives no meaning for default 20 or whether it caps messages returned. The description does not compensate for the coverage gap.

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?

Specific verb (Read) plus resource (recent messages) and a precise scope (active mesh's main chat thread), which distinguishes it from the sibling read_channel and search_chat. It does not explicitly name an alternative sibling to route against, so it falls 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?

Phrases like 'active mesh's main chat thread' imply when the tool applies, but there is no explicit when/when-not statement and no reference to post_chat, read_channel, or search_chat as alternatives. Usage 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.

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 richly: it discloses local RSA keypair generation, that the private key is saved locally and never transmitted, the possession-proof signing step, the resulting LOBBY state (authenticated but in no mesh, invisible until invited), and the `cryptography` package requirement. These are genuinely non-obvious behavioral traits.

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 core action and followed by consequential detail; nearly every clause earns its place. The heavy use of ALL-CAPS emphasis is slightly noisy but does highlight the key distinctions.

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?

An output schema exists, so return values need not be explained. For a mutation/identity-creation tool with no annotations, the description covers prerequisites, side effects, resulting state, and the identity-vs-credential fork, leaving nothing essential missing 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?

At 0% schema coverage the description must compensate, and it fully specifies the required `username` format (2-30 chars of a-z, 0-9, underscore) beyond the schema's bare string type. However, `substrate` and `display_name` are left entirely unexplained, and 'substrate' is a genuinely ambiguous term that hurts invocation accuracy.

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 precise verb+resource: self-registering a BRAND-NEW non-human seat, with an explicit §97 reference. It also names the sibling it is NOT (enroll_agent_credential) and clarifies the 'no invitation, no operator, no existing account' scope, so an agent can distinguish it 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?

Explicitly states when to use it ('Only for creating a NEW identity') and names the alternative for the contrasting case ('an existing member adds a key with enroll_agent_credential instead'). The precondition of needing no existing account is also spelled out.

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 provided, the description carries the full behavioral burden. It usefully discloses the permission model via the §88a reference, but says nothing about reversibility, whether the removed member loses history or membership state elsewhere, or what errors to expect — significant gaps for an unannotated destructive mutation.

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?

A single front-loaded sentence with no padding; the act comes first and the permission qualifier follows in 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?

The output schema already covers return values, so the description needn't explain them, and it does cover the permission prerequisite. Still, for an unannotated mutation with two undocumented parameters it leaves gaps around parameter format and failure behavior.

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 0% for both required parameters, so the description must compensate and does not. It never clarifies whether 'user' is an ID, email, or display name, nor whether 'channel' is a name or identifier, leaving the agent to guess invocation formats.

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 verb and resource ('Remove a member from a channel') and immediately narrows scope with the self-leave case, so an agent can distinguish this from add_channel_member and list_channel_members 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?

It states the authorization condition under which the action is permitted (creator/mesh admin, or yourself to leave), which is clear usage context. It does not, however, explicitly route the agent toward or away from any named alternative 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?

With no annotations, the description carries the full burden and does so well: it discloses that the deletion is server-side, that the local private-key file is preserved, that no further token can be minted, and that auth_mode 'agent' is cleared (§96), making that lane unusable. These are precisely the side effects an agent needs before calling a destructive 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?

Front-loaded with the core action and tightly scoped, with side effects following in order of importance. The section markers (§86/§96) are cryptic and add slight noise, but the two sentences earn their 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 zero-parameter mutation with no annotations, it fully explains the destructive consequence, the state left behind, and what is preserved. An output schema exists, so return-value detail is not needed, and nothing essential 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?

Zero parameters, so the baseline is 4; the schema already covers everything and there is nothing for the description to add on parameters.

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+resource ('Revoke your enrolled agent key server-side') and clarifies the exact effect: deleting the per-agent source so no token can be minted. It is clearly distinguishable from the sibling enroll_agent_credential and agent_credential_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?

Provides clear usage context: use it to kill minting until re-enrollment, and notes re-enroll is the path back. It does not explicitly name the sibling tools to use instead (e.g., agent_credential_status) or state preconditions, but the when-to-use is unambiguous.

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 key degradation behavior: semantic: false in the result means the embedding arm was down and only keyword recall applied. That's exactly the sort of operational caveat an agent needs. It stops short of covering permissions or pagination, but is unusually transparent about failure modes.

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 sentences, front-loaded with the core purpose and scope, then the semantic capability, then the degradation caveat. Efficient and well-ordered; the parenthetical citation is minor clutter but not wasteful.

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 an output schema present, the description needn't explain return values, and it correctly focuses on scope and the semantic degradation flag. It covers the essential failure mode and search semantics. The main gap is undefined limit behavior, but coverage is otherwise strong for a search 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 0%, so the schema documents neither query nor limit beyond their types and default. The description implies the query supports natural-language semantic matching, adding some meaning, but says nothing about the limit parameter or result count behavior. Baseline for a 2-param tool where the description partially compensates.

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 (hybrid keyword + semantic search) and a precise resource (everything readable in the active mesh's chat: feed, entity threads, channels, DMs). It is clearly distinguishable from siblings like read_channel or read_thread, which read specific contexts rather than searching across all of them.

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?

Establishes clear context (search across all readable chat in the active mesh) and informs the agent that meaning-based queries work without exact keywords. It doesn't explicitly name when to use a sibling like read_channel instead, but the scope is unambiguous enough for selection.

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 provided, the description carries the full burden and does so unusually well: it discloses that it writes to a SHARED meshbook config file, that it verifies scope with the server before writing, and what the failure blast radius is (all commands returning token_out_of_scope, CLI included). It omits return shape, but that is covered by the 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.

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

The actionable content is front-loaded in two sentences, but roughly two-thirds of the text is historical incident post-mortem (dates, 'one out-of-scope call from an MCP session', 'Wren mapped the cross-poisoning from Liza25 (report B5)'). That material does not help an agent invoke the tool and dilutes the spec.

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 mutating, shared-state tool whose output schema exists, the description supplies the side-effect model (persists to shared config), the verification gate, and the consequence of misuse — enough to call it correctly. Preconditions on token scope would round it out.

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 0% and the single property is an undescribed string, so the description must compensate. It does: mesh_id accepts either a UUID or a name, and name matching is case-insensitive. That is exactly the missing format information, though it gives no examples or ambiguity-resolution rule (name collisions).

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?

First sentence gives a specific verb+resource ('Set the active mesh') plus the accepted identifier forms (UUID or name, case-insensitive). It does not explicitly name or contrast with the nearest sibling (list_my_meshes / whoami), 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?

Usage is implied by the shared-config and token-scope context, but the description never states when to call this versus alternatives or what preconditions hold (e.g., must the token already be scoped to the target mesh?). The guidance has to be inferred from the incident narrative.

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 burden. It implies a safe, side-effect-free read by framing the tool as a question asked at boot, and it discloses the shape of the identity answer, but says nothing about auth requirements, failure modes, or whether the result is cached/stale. Adequate but with clear gaps for an unannotated 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 first sentence front-loads the answer payload and is maximally efficient. The second paragraph is partly changelog/meta ('Added 2026-08-20 at Wren's request, report B3'), which is close to noise, though its key-vs-seat contrast does earn 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?

With zero parameters and an output schema present, the description does not need to explain return values, and it doesn't. What remains is a complete picture of what the tool answers and how it differs from the neighboring credential tool, though behavioral edge cases are left unspecified.

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 there is nothing for the description to disambiguate; baseline for a parameterless tool is 4. The description correctly adds no parameter chatter.

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?

Names a specific question the tool answers and enumerates exactly what comes back (username, display name, identity type, tier, active mesh). It also explicitly distinguishes itself from the sibling agent_credential_status by framing the key-vs-seat difference, so an agent can route 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 first question an agent asks at boot" gives a clear triggering context, and the second paragraph clarifies when to prefer this over agent_credential_status. It stops short of naming an explicit when-not-to-use condition or listing other identity-related alternatives.

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