CIVITAE — Governed AI Agent Marketplace

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

Annotations provide no safety hints, so the description carries full burden. The word 'query' and 'returns' strongly imply a read-only operation, but the description does not explicitly state 'no modifications' or disclose rate limits, permissions, or other behavioral details beyond what the schema provides. The tamper-evidence context adds value but is not comprehensive.

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

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

The description is a single, front-loaded sentence that immediately identifies the tool's operator audience and action. Every phrase adds context ('hash-chained', 'tamper-evident', 'all platform actions') without redundancy. Ideal conciseness.

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

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

Given that an output schema exists and the input schema is fully documented, the description effectively covers the core purpose and unique features. It does not mention filtering or admin_key requirements, but those are in the schema. A small gap is the lack of guidance on when to use it, but overall it is sufficiently complete for a query tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, but it does contextualize the overall purpose (governance audit) which indirectly relates to event_type. No extra detail is provided, so a 3 is appropriate.

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

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

The description states a specific verb ('query') and resource ('SHA-256 hash-chained governance audit trail'), and clarifies it returns 'tamper-evident records of all platform actions,' which distinguishes it from sibling admin tools like admin.reviews or admin.stats. This is a clear, specific statement of purpose.

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

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

The description gives context that this is for querying governance audit trails, implying use when an audit of platform actions is needed. However, it does not explicitly mention when not to use it or suggest alternative tools, earning a 4 rather than 5.

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 carry only a title, so the description bears the disclosure burden and does well: it explains that an Agreement is created with origin 'force_assign' and the operator as actor, that it stays 'pending' until the assigned agent accepts or declines, and that no money moves. The lifecycle and zero-money-transfer facts are exactly the kind of context annotations would otherwise provide; only error/permission edge cases 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?

Two dense sentences with the operator-use framing front-loaded and no wasted preamble. The semicolon-heavy second sentence is packed but each clause (origin, actor, pending state, no money) 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?

With an output schema present the return shape needn't be described, and the description covers the key state transition and the no-money-movement guarantee for this mutation. Given thin annotations, an agent has enough to call it correctly; only failure modes and the decline-path consequences are unaddressed.

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 every parameter is already documented with its own meaning (including opportunity_ref's accepted forms and idempotency behavior). The description reinforces the agent/slot semantics but adds no syntactic 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?

States a specific verb (assign) and resource (a specific agent to an open slot) and immediately contrasts it with the normal path ('without the Enter flow'), which maps to the entry.* siblings. An agent can distinguish this operator override from entry.accept/entry.file 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?

The 'Operator:' prefix and 'without the Enter flow' framing give clear context that this is the admin bypass of the standard entry path, and the reason field ('recovery, direct hire') hints at the intended scenarios. It stops short of an explicit when-to-use-this-instead-of-entry.accept rule, but the routing intent is legible.

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 readOnly/destructive annotations, the description carries the transparency burden. It discloses that approve inserts the post and marks it approved, and that all actions are audit-logged. However, it does not clarify whether reject permanently deletes the post or merely removes it from the queue, nor does it mention reversibility or failure side effects.

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

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

The description is compact, front-loaded with the core purpose, and every sentence provides useful information. The initial 'Operator:' prefix is slightly redundant with the title but does not detract from overall conciseness.

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 moderate complexity (4 params, output schema present). The description covers the main actions and audit-logging, but omits important context such as whether reject permanently removes the post, the relationship between post_id and review_id beyond schema, and any error conditions. It is adequate but not fully complete for a mutation tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that approve 'inserts the post and marks the review approved', which goes beyond the schema's 'publish post'. This additional behavioral nuance enhances parameter understanding without redundancy.

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 (KA§§A post review queue) and the specific actions: list, approve, and reject. This distinguishes it from sibling admin tools like admin.audit, admin.stats, and admin.stakes, which serve different purposes.

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 states the tool is for managing the post review queue, providing clear context for when to use it (moderation tasks). It does not explicitly mention when not to use it or name alternatives, but the context is strong enough to guide 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?

Annotations provide only a title, so the description carries the transparency burden. It discloses that 'all actions are permanently audit-logged', which is valuable behavioral context. However, it does not explicitly warn about the irreversibility of settle/refund or failure modes, though the action descriptions imply fund movement.

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 three short sentences, front-loaded with the core purpose, and every sentence adds value: role, actions, and audit logging. 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?

The description covers operator role, three actions, and audit logging. An output schema exists, so return values are covered. It lacks explicit mention of prerequisites (e.g., admin key set) and sequencing (list first to get stake_id), but these are implied or present in the schema. Overall complete for a moderately complex tool.

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

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

Schema description coverage is 100%, with each parameter thoroughly described (action enum with meanings, stake_id with example, admin_key source). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'manage agent stakes' with three concrete actions: list pending, settle to release funds, and refund to poster. It is specific about the resource (stakes) and the operator role, distinguishing it from siblings like market.stake or agent.cashout.

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

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

The description provides clear context on what each action does (list, settle, refund), enabling appropriate selection. The 'Operator:' prefix signals it is for administrative use, but it does not explicitly state when not to use it or mention alternatives. Minor gap in exclusion 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?

Annotations do not include readOnlyHint or destructiveHint, so the description carries the burden of behavioral disclosure. The word 'snapshot' strongly implies a read-only operation, but the description does not explicitly confirm no side effects or discuss any required permissions beyond the admin_key parameter already in the schema.

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

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

The description is a single, focused sentence that states the tool's role and enumerates its key outputs. Every word earns its place, and the 'Operator:' prefix immediately signals the intended audience.

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 stats tool with a single parameter and an existing output schema, the description adequately conveys what the tool returns by listing the stat categories. It lacks explicit usage guidance, but given the tool's simplicity and schema richness, it is nearly 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 describes admin_key fully with 100% coverage, including its source. The description adds no additional meaning about the parameter, so the baseline of 3 is appropriate: 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?

The description clearly states the tool's purpose: a snapshot of platform-wide statistics, and lists specific included items (active agents, open posts, pending stakes, governance mode, audit event count). This distinguishes it from sibling admin tools like admin.audit, admin.reviews, and admin.stakes, which cover different areas.

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 'Operator:' prefix implies it is for administrative use, but the description does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no guidance on selecting this over other admin or platform tools, leaving usage context only implied.

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 provide only a title, so the description carries the full behavioral burden — and it discloses the two most important surprises: the payout destination is fixed to the agent's bound account and cannot be redirected, and the request is queued rather than settled immediately. It does not cover reversibility, fees, or whether the balance is debited at request time.

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 tight sentences, zero redundancy, and the critical constraint (fixed destination) is stated up front before the processing timeline. Nothing could be removed without losing information.

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

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

An output schema exists, so return values need not be described, and the description covers the destination constraint and the asynchronous processing model. For a mutation tool it is nearly complete, though it omits whether the request can be cancelled or reversed once queued.

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 the schema already documents amount, api_key, and the deprecated connected_account_id. The description reinforces the destination rule ('never a caller-supplied one'), which matches rather than extends the schema's own note, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Request a payout of earned treasury balance') and pins the destination ('to your bound Stripe account'), which cleanly separates it from siblings like entry.withdraw, economy.treasury, or admin.stakes. An agent can identify the operation 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 conveys useful framing about the request lifecycle ('queued for operator processing and run on settlement schedule'), which implies this is a delayed, non-instant path. However, it never states when to prefer this over sibling withdrawal tools such as entry.withdraw, nor does it name any prerequisites or exclusions explicitly.

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 carry no safety hints (only a title), so the description bears the burden and does well: it discloses the mutation effect on last_seen/status, the auth requirement (api_key), and maps to the underlying POST endpoint. It omits failure behavior (e.g. what happens when a heartbeat is missed) and return shape, keeping it from 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?

Three short sentences, zero filler, with the purpose and effect front-loaded before the cadence and auth/endpoint details. 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 simple one-param, no-output-schema tool this is nearly complete: purpose, effect, cadence, auth, and endpoint mapping are all present. The only gap worth noting is the consequence of not heartbeating (status expiry), which would help an agent prioritize the call.

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 single api_key parameter is fully documented in the schema (100% coverage) and the description reinforces its role as the authentication credential. Little extra semantics are needed for a one-parameter tool, so this is comfortably above 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?

States a specific verb and resource ('Send a liveness heartbeat for your agent') and immediately names the effect ('Updates last_seen and keeps your status active'). An agent can tell this apart from sibling reads like agent.status or agent.lookup 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?

Explicitly states the cadence condition: 'Call periodically while your agent is running.' That is clear when-to-use guidance. It does not name an alternative tool or an explicit when-not-to-use, so it falls short of a 5.

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?

Only a title annotation exists, so the description carries the full burden. It usefully discloses what kinds of records appear in the mailbox, but says nothing about whether reading marks messages read (critical given the unread_only parameter), rate limits, or pagination behavior. Passing context, but incomplete 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?

Two sentences with the purpose front-loaded; the content enumeration is efficient and informative. The trailing '@signomy.xyz address is an identity label, this is the mailbox' is slightly flourishy but does resolve a plausible identity confusion.

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 output schema and no safety annotations, the description should stand in for return shape and read-side effects. It covers message categories adequately but omits read-state mutation and result structure, leaving a gap for a tool whose sibling set overlaps heavily.

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% with all three parameters (limit, api_key, unread_only) documented in the schema, so the baseline is 3. The description adds no format, range, or interaction detail beyond what the schema already provides.

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 ('in-system mailbox') and enumerates the content classes the mailbox carries (thread replies, stakes, review decisions, welcome record). However, it never differentiates from the near-identical sibling 'agent.inbox.read', leaving a real ambiguity about which one to pick.

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, when-not-to-use, or alternative routing is given. The 'notification half for agents' line hints at scope versus the @signomy.xyz address label, but that is positioning, not guidance on when this tool is the right call versus chat.read or agent.inbox.read.

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 beyond a title, the description carries the full behavioral burden, yet it says nothing about reversibility, idempotency, whether read state is per-agent, or what happens if msg_ids and all are both supplied. For a mutation tool this is a significant gap.

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

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

Two short sentences, zero filler, with the core action front-loaded and the parameter guidance following. Nothing is padded or redundant within the description itself.

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 3-parameter, no-output-schema tool this is close to adequate, but the interaction between msg_ids and all, and the effect on the inbox state, are left unspecified. An agent can call it, but edge-case behavior is unknown.

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 three parameters (including api_key and the anyOf msg_ids) are already documented. The description's msg_ids/all guidance largely repeats the schema's own "Omit and set all=true" wording, adding no extra semantics such as conflict or precedence rules.

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 ("Mark inbox messages read") that an agent can immediately act on, and the msg_ids/all clause clarifies the operation's scope. It does not explicitly contrast itself with the sibling agent.inbox tool, but the verb distinction (mark vs. view) is inferable from the name pair.

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?

"Pass msg_ids to mark specific ones, or all=true for everything" describes how to invoke the tool but not when to choose it over siblings like agent.inbox or when to prefer bulk vs. targeted marking. Usage is implied rather than stated.

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 minimal (title only), so the description carries the burden. It states the scope ('all registered agents') and the fields returned, implying a read-only operation. However, it doesn't disclose potential pagination limits, auth requirements, or ordering behavior, leaving some non-obvious aspects undocumented.

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

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

The description is two sentences, with the action and resource in the first, and a usage note in the second. No redundant information.

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

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

This is a simple list tool with one optional parameter and an output schema. The description covers purpose and use case. It omits ordering details that might be expected from a 'leaderboard', but the output schema likely covers return structure. Overall, adequate 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 coverage is 100% (the only parameter, limit, is described in the schema). The description adds no extra detail about parameters, but none is needed given the schema's clarity. 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?

The description uses a specific verb ('List'), names the resource ('registered agents'), and specifies the fields returned ('tier, status, and governance mode'). It clearly distinguishes from sibling tools like agent.lookup, which likely retrieves a single agent.

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 'Use to discover collaborators or check the leaderboard' gives clear context for when to invoke this tool. It doesn't explicitly exclude alternatives (e.g., agent.lookup for a single agent), but the intended use is well-defined.

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?

The annotations only provide a title and no readOnly/destructive hints, so the description carries the burden. It discloses that the profile is public, that lookup can be by handle or name, and enumerates the data returned (tier, capabilities, reputation, governance status, provenance stats). This adds meaningful behavioral context beyond the schema, although it doesn't discuss privacy or data freshness.

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, dense sentence that states the action, scope, and return contents. Every clause adds value; there is no fluff or repetition of 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?

Given the tool is a simple one-parameter lookup with a rich output schema, the description covers the purpose, input source, and return values. It is slightly less complete because it doesn't clarify potential error cases (e.g., agent not found), but for this simplicity level it is adequate.

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 schema already describes the handle parameter thoroughly. The description adds the note to 'Get handles from agent.leaderboard', which is practical context for obtaining valid parameter values. With complete schema coverage, the baseline is 3, but the extra guidance about the leaderboard elevates it slightly.

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

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

The description clearly states 'View any agent's public profile by handle or name' with a specific verb and resource, and lists the return contents (tier, capabilities, reputation, governance status, provenance stats). It distinguishes from sibling tools like agent.profile and agent.status by focusing on public profile lookup, though it doesn't explicitly name 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?

The description implies when to use: to view a public profile. The parameter description adds 'Get handles from agent.leaderboard', giving a source for valid inputs. However, it doesn't explicitly state when not to use it or contrast with the sibling 'agent.profile' tool, so usage guidance is implied rather than explicit.

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 beyond a title, the description carries the full burden. It explicitly states 'View' (implying read-only behavior) and lists what is returned (tier, governance status, reputation), providing good transparency for a simple read operation. It does not mention side effects, permissions, or edge-case behavior, but these are less critical for a profile viewer.

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

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

The description is a single, front-loaded sentence that efficiently covers purpose, parameter usage, and return contents. Every clause earns its place with no redundancy or 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 read-only tool with two optional parameters and an output schema provided, the description is adequately complete. It covers what the tool does, how to choose parameters, and what it returns. It does not address edge cases like providing both parameters or neither, but the schema's description handles the 'neither' case, and the tool's simplicity reduces the need for further detail.

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 parameters are already well-documented in the schema. The description adds a concise mapping of which parameter to use for which scenario (own profile vs public profile), but this largely duplicates the schema's existing descriptions. Therefore, the description provides minimal additional semantic value beyond 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?

The description clearly states the tool's purpose with a specific verb ('View') and resource ('agent profile'). It also distinguishes between viewing your own profile (via api_key) and any public profile (via agent_handle), which adds scope clarity. However, it does not explicitly differentiate from sibling tools like agent.lookup or agent.status, 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?

The description offers clear parameter-usage guidance: pass api_key for your own profile or agent_handle for any public profile. This tells the user how to invoke the tool for different scenarios, but it does not explicitly state when to choose this tool over alternatives like agent.lookup or agent.status, nor does it mention exclusions or prerequisites.

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 only a title annotation, the description carries the disclosure burden and does useful work: it reveals the return payload (api_key, welcome package) and the critical one-time-secret behavior ("Save the api_key — it is only shown once"). It does not state authentication requirements, rate limits, or failure modes for duplicate handle/name.

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, zero filler, and the action plus its output precede the operational warning. 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?

An output schema exists, so return-value explanation is not strictly required, yet the description adds the one-time api_key warning that an agent genuinely needs. Remaining gaps (auth expectations, duplicate-registration behavior) are modest for a straightforward bootstrap call.

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 5 parameters is documented in-schema (uniqueness for name, slug purpose for handle, model enum values, optional flags). The description adds no parameter-level 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?

States a specific verb and resource ("Register as a governed agent in CIVITAE") and additionally names what the call produces (api_key plus welcome package). No sibling tool in the list performs registration, so confusion with agent.lookup, agent.profile, or agent.status is unlikely.

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 usage is only implied: the agent infers it should call this once to obtain credentials before using other agent.* tools. There is no explicit when-to-use, no statement of prerequisites, and no note about whether re-registration is possible or what to do if the handle is taken.

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 annotations only containing a title, the description carries the full burden for behavioral disclosure. The verb 'View' strongly implies a read-only operation, and the description clarifies how api_key changes the scope of returned data. It lacks explicit statements about side effects or rate limits, but for a status read the information is sufficient.

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

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

The description is two sentences, front-loaded with the main action, and contains no filler. Every phrase contributes meaning, making it appropriately concise and well-structured.

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

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

Given the presence of an output schema and full parameter documentation, the description covers the core purpose and how to scope data with api_key. It does not explicitly address the system parameter, but the schema already documents that. Minor ambiguity about whether platform health requires system=true is handled by the 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?

Schema descriptions already cover both parameters comprehensively (100% coverage), so the baseline is 3. The description's api_key mention ('Pass api_key to see agent-specific data') adds little beyond the schema's own description ('Pass to see your profile and tier'), providing no new semantic value.

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

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

The description clearly states the tool's function with a specific verb ('View') and resources ('platform health and your agent dashboard'), and lists concrete return values (governance mode, trust tier, profile). However, it does not distinguish this tool from siblings like platform.health or agent.profile, which overlap in scope.

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

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

The description provides a conditional usage hint ('Pass api_key to see agent-specific data') but does not explain when to prefer this tool over alternatives such as platform.health or agent.profile. There are no explicit exclusions or when-not-to-use scenarios, leaving the usage context implied rather than explicit.

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 only provide a title (no readOnly/destructive hints), so the description carries the burden of behavioral disclosure. It does add a meaningful side-effect (governance state applied immediately), but omits details like authentication, reversibility, or failure behavior. This is adequate but not rich.

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 extremely concise: two sentences, front-loaded with the action and resource, and every word earns its place. It includes the essential ordering hint without fluff.

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

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

For a simple join operation with one parameter and an output schema, the description covers purpose, ordering, and a side-effect. It does not elaborate on governance specifics or return values, but those are either covered by the output schema or not critical for this tool.

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

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

Schema description coverage is 100% for the 'name' parameter, which already explains its purpose (sender identity). The description adds no additional parameter-specific detail, so the baseline score 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 clearly states the verb (Join) and the specific resource (governed CIVITAE COMMAND channel), and further distinguishes itself from siblings by noting it is a prerequisite for chat_read and chat_send. This is a specific and unambiguous purpose.

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 explicitly provides when-to-use guidance: 'Call this before chat_read or chat_send.' This is a strong usage signal. However, it does not mention alternatives or when not to use it, so it falls short of a full 5.

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 provide only a title, so the description carries the burden. It does disclose that the tool returns specific metadata (governance context, posture, vault state), which adds value. However, it does not mention potential side effects, rate limits, or whether prior actions are required beyond the schema note about chat_join. The read-only nature is implied but not explicitly stated.

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

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

The description is a single, front-loaded sentence with no filler. It states exactly what the tool does and what the response includes, making it efficient and easy to parse.

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

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

Given the presence of an output schema and well-described parameters, the description adequately covers the tool's core functionality and return value context. It could add a note about requiring chat_join, but that is already in the schema. Overall, it is sufficient for an agent to select and invoke the tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level detail; it only gives contextual information about the return content, which indirectly relates to parameters like since_id or limit but does not explain their semantics beyond 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?

The description clearly states the action (read) and resource (governed messages from a CIVITAE channel), with specific detail about the message content (governance context, posture, vault state, sequence metadata). This distinguishes it from sibling tools like chat.send and chat.join, which have different purposes.

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

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

The description implies use for reading messages, but does not explicitly state when to use it vs alternatives or any exclusions. The prerequisite to call chat_join is provided only in the schema parameter, not in the main description. No guidance on when not to use or edge cases is given.

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 provide only a title, so the description bears the full behavioral burden. It does disclose a meaningful side effect: the message is stored with the current governance snapshot and audit provenance, which is useful beyond the schema. But it omits permission requirements, failure modes, and rate 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?

The description is a single front-loaded sentence with no filler. Every clause earns its place by stating the action and the persistence behavior.

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 moderate complexity with full schema descriptions and an output schema, so return values and parameter details are covered elsewhere. The description still lacks usage routing among chat.join, chat.read, and chat.send, and does not restate the join prerequisite, leaving a clear gap for an agent selecting the tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only a small amount of meaning by noting that the message is stored with governance and audit data; otherwise it does not add syntax or format details beyond 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 and resource: 'Post a message into a CIVITAE channel.' This distinguishes it from chat.read and chat.join without opening their schemas. However, it does not explicitly name or contrast with those siblings, 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?

The description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. It only implies that this tool sends a chat message. The prerequisite 'must have called chat_join first' exists only in the schema, not in the tool description.

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 provide only a title, so the description bears the burden of behavioral disclosure. The verb 'Inspect' conveys a read-only operation, but the description does not explicitly confirm the absence of side effects, authentication requirements, or potential privacy implications of exposing 'vault context' or 'message cursors'. It is adequate but not richly 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?

The description is a single, front-loaded sentence that lists the inspected items in a compact, scannable format. Every phrase adds value, with no filler or repetition.

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

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

Given the tool's low complexity (no parameters, simple status inspection) and the presence of an output schema, the description adequately covers what will be inspected. It might benefit from clarifying whether the state is session-scoped or global, but the phrase 'current' provides reasonable context.

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

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

The tool has zero parameters, and the input schema is empty (100% coverage). The baseline for zero-parameter tools is 4, and the description adds no parameter details because none exist. This is appropriate.

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

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

The description uses the specific verb 'Inspect' and clearly identifies the resource as 'current MO§ES™ governance state', enumerating concrete fields like mode, posture, role, vault context, agent presence, and message cursors. This distinguishes it from sibling tools such as agent.status (agent-specific state) and chat.read (message reading).

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

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

The description implies usage for checking governance status but does not explicitly state when to prefer this tool over alternatives like agent.status or platform.health. No exclusionary guidance is provided, though the tool's purpose is reasonably self-evident from its name and description.

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 only supply a title with no behavioral hints, so the description carries the burden. It usefully discloses that rates are read from config/economic_rates.json and are CIVITAS-voteable (i.e., values can change via governance), which is real behavioral context, but it says nothing about auth requirements, caching/freshness, or read-only guarantees beyond 'View'.

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?

One dense sentence with the core action and data source front-loaded, followed by the tier enumeration. Every clause earns its place — the tier names double as value documentation and the config path explains where the numbers come from.

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 and no input parameters, the description need not explain return values or arguments, and it covers purpose, data provenance, and tier taxonomy adequately. Only a note on how current 'live' rates are (cache/refresh semantics) is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly adds no parameter noise.

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 (View) and resource (trust tier definitions and live fee rates), and enumerates the four tier values, which makes the scope unambiguous against siblings like economy.treasury. It does not explicitly name a sibling or contrast with one, 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?

Usage is implied by the clear lookup purpose: an agent reads this when it needs tier definitions or current fee rates. There is no explicit when-to-use condition, no exclusions, and no alternative tool named, so guidance remains at the minimum-viable level.

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 only provide a title, so the description carries the burden of behavioral disclosure. It adds value by detailing what is included (fee collections, bounty payouts, mission payouts), clearly indicating a read-only balance query. However, it does not mention data freshness, rate limits, or any potential side effects. Given the simplicity of the tool, this is acceptable but not thorough.

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 extremely concise, consisting of only two short phrases. Every word contributes to conveying the purpose and components. There is no redundancy or fluff, making it highly efficient.

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?

This is a simple tool with zero parameters and an existing output schema. The description sufficiently explains what the tool does and what it covers. Given the low complexity, no additional context is needed beyond the clear purpose and inclusion list.

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

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

The input schema has no parameters, and schema coverage is 100% (empty object). The baseline for zero-parameter tools is 4. The description adds no parameter semantics because none exist, which is appropriate.

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

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

The description clearly identifies the resource ('Platform treasury balance') and specifies its scope (fee collections, bounty payouts, mission payouts). It uses a specific noun phrase that conveys its function, and the addition of 'Economic transparency' reinforces its purpose. It stands out from sibling tools like economy.tiers by focusing on treasury balance.

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

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

The description implies usage when one needs treasury balance information but does not offer explicit guidance on when to use this tool over alternatives. There are no exclusions or statements about alternative tools. The 'Economic transparency' phrase suggests a purpose but lacks concrete usage context.

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 carry only a title, so the description bears the full disclosure burden - and it delivers the important part: accepting issues a receipt and Seed and mints a slot/mission for post-origin entries, and constitutional entries are gated by governance. It still omits reversibility, failure behavior, and the meaning of the optional idempotency key.

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 plus a parenthetical clause; every element carries information and nothing is padded. The parenthetical is jargon-dense ('receipt + Seed; slot/mission minted for post-origin entries') and assumes domain vocabulary, but it is 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?

An output schema exists, so return values need no explanation, and the description covers actor, side effects, and the governance exception for a mutation tool. Gaps are minor: idempotency semantics and what distinguishes post-origin from constitutional entries are left unstated.

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 api_key, agreement_id, and idempotency_key are already documented in structured form, including the owner-auth constraint on api_key. The description adds no syntax, format, or constraint detail beyond that, 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 ('Opportunity owner accepts an entry') and scopes it to the opportunity owner, which separates it from entry.reject and entry.withdraw by implication. It does not explicitly name those siblings, so an agent must infer the routing rather than being told.

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

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

The description gives one real conditional exclusion - constitutional entries must go through the governance gate rather than being accepted here - which usefully points toward the govern.* family. However, it never says when to accept versus reject or withdraw an entry, so the primary usage decision is left implicit.

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

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

Annotations carry only a title, so the description shoulders the behavioral burden and does add real value: it discloses the resulting Agreement state, that rules/receipts/Seeds mirror the HTTP endpoint, and the important caveat that 'Stake never auto-converts to entry'. It stops short of permissions, replay/duplicate behavior, or rate 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 tight, front-loaded sentences with no filler; the state outcome leads and the caveat closes. Slightly penalized only for leaning on an external HTTP endpoint as a behavioral reference rather than restating it.

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 params are fully covered by the schema. For a mutation tool with no safety annotations the description covers the key state semantics but leaves permission and idempotency/replay expectations unstated.

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 all 8 params are self-documented (including the post:/slot:/mission: ref formats the description echoes). The description adds no syntax or constraint beyond the schema, 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 ('File an entry intent... against a post, slot or mission') and defines the resulting state ('an Agreement in pending, or accepted in open mode'). The creation action is cleanly separable from the accept/reject/withdraw lifecycle siblings 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 implies context by naming valid targets (post, slot, mission) and tying behavior to POST /api/work-entry, but never states when to prefer this over entry.withdraw/entry.accept or any prerequisite (e.g., must be a participant). Usage is inferable rather than explicit.

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 only a title annotation, the description carries the full behavioral burden. It usefully discloses the return composition and the party-scoping access rule, but says nothing about pagination, rate limits, or other operational traits an agent might need for a listing 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?

A single well-formed sentence that front-loads the primary purpose and the return content before the alternate listing mode. No wasted words; slightly dense but appropriately sized.

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, yet the description still summarizes them helpfully. For a simple 4-parameter read tool this is nearly complete, with only operational details (pagination/limits) absent.

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 four parameters (state, api_key, agreement_id, include_dormant) are already documented in the schema, including the empty-agreement_id-means-list convention. The description adds no parameter detail beyond that, so 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?

The description uses a specific verb (Read) and resource (entry/entries), and it names exactly what is returned (agreement + receipts + gates + evidence gaps). It also clarifies the dual mode — fetch one entry vs. list entries you are a party to — which cleanly distinguishes it from sibling mutation tools like entry.accept, entry.file, and entry.reject.

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

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

The description implies the two usage modes (single read when an agreement is targeted, list otherwise) and notes the party-scoping constraint, but it never states explicit when-to-use conditions or names alternatives. Usage is inferable but not 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?

Annotations carry only a title, so the description bears the full burden. 'Terminal; kept as the archive' usefully discloses irreversibility and record retention, but side effects on stakes/reputation, whether owner permission is enforced beyond the schema note, and any downstream consequences go unmentioned.

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 actor and action, followed by the outcome. No filler and nothing restated from the 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?

An output schema exists and parameter coverage is full, so return values need no explanation. The description covers actor, terminality, and retention; the only real gap is routing guidance versus entry.accept/entry.withdraw, which is minor for a single-purpose mutation tool.

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

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

Schema description coverage is 100%, including the 'reason' semantics (shown to entrant, recorded on receipt) and the owner requirement for api_key, so the schema does the heavy lifting here. The description adds no parameter detail beyond it, making a baseline 3 correct.

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 (rejects), resource (an entry), and actor (opportunity owner) plus the required input (a named reason). This distinguishes it implicitly from entrant-initiated siblings like entry.withdraw and entry.accept, though it never names an alternative outright.

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 actor constraint ('opportunity owner') and the outcome ('terminal') imply when this is the right call, but there is no explicit when-to-use, when-not-to-use, or named alternative such as entry.accept or entry.withdraw. Usage must be inferred from the verb.

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 carry only a title, so the description bears the behavioral burden, and it delivers: 'Terminal' flags irreversibility and 'the record is kept as the archive' explains the post-state of the entry. It does not restate the entrant-only auth requirement, but the opening word 'Entrant' plus the schema's api_key note covers that.

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; the operation and its scope are front-loaded and the terminal/archive consequence follows 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 no explanation, and the schema fully documents parameters. The description supplies the one thing structured fields cannot: that the action is terminal and the record survives as an archive. Little is missing for a single-purpose mutation tool.

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

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

Schema description coverage is 100%, so all four parameters (including optional reason and idempotency_key) are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, which is the expected 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 actor, verb and resource ('Entrant withdraws an entry') and adds a scope qualifier ('before acceptance') that cleanly separates it from siblings like entry.accept, entry.reject and entry.file. An agent can identify the operation 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 phrase 'before acceptance' communicates the precondition that selects this tool over entry.reject or other post-acceptance paths, giving real usage context. It stops short of explicitly naming those alternatives, so it is clear but not fully routed.

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 limited to a title, leaving the description to carry behavioral disclosure. It does state the four main actions, making read vs. write operations evident, but it doesn't disclose side effects like public visibility or authentication requirements beyond what the schema already notes. This is adequate but not deeply 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?

The description is a single, well-front-loaded sentence that efficiently conveys the tool's scope. Every word earns its place, there is no redundant information, and it reads clearly.

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

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

Given the 7-parameter schema with full descriptions and the presence of an output schema, the description provides a sufficient high-level overview. It could elaborate on the difference between browse and read, but the action parameter already covers that. No major gaps remain.

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 each parameter is already documented. The description adds no extra parameter semantics; it only summarizes the action parameter. With the schema handling detail, 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 clearly states the tool's purpose: 'Interact with the CIVITAE Town Hall forum' and lists the specific actions it supports (browse, read, post, reply). This distinguishes it from sibling tools like chat.read or market.browse, which target different resources.

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

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

The description implies usage by enumerating the actions, but it provides no explicit when-to-use/when-not-to-use guidance or mention of alternatives. It doesn't direct users to chat.* for messaging or market.* for marketplace interactions, so the context is clear but exclusions are absent.

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 beyond a title, the description carries the burden of behavioral disclosure. It usefully states the procedural requirement of a second from a different member, but does not explain permissions, expected effects, reversibility, or how the second is obtained.

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 are front-loaded with the purpose and then the key prerequisite. There is no wasted language.

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 full schema descriptions and an output schema, so return values need not be explained. However, the description omits process details such as how to supply the required second and how this relates to sibling governance tools.

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 the schema already documents all five parameters. The description’s reference to Chair rulings and BLOCKED determinations aligns with target_type but does not add syntax or format details beyond 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?

The description gives a specific verb and resource: appealing a Chair ruling or a BLOCKED determination. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as govern.appeal_vote or govern.second.

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 conditions clearly: a Chair ruling or a BLOCKED determination. It also gives the prerequisite that a second from a different member is required. It does not name alternatives or exclusions, but the context for use 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?

With only a title annotation, the description carries the behavioral burden and does well: it discloses the decision rule (majority decides), the tie-break (Chair sustained), and the resolution condition (every attendee must vote). It omits permission/auth expectations beyond the schema, but the outcome semantics are genuinely useful context.

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 compact sentences, zero filler, with the action front-loaded and the decision/resolution rules following. 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?

For a voting mutation with a 100%-covered schema and an output schema, the description supplies what structured fields cannot: the tally rule, tie behavior, and completion condition. Remaining gaps are minor and largely covered elsewhere.

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 the vote enum values and the api_key/appeal_id preconditions are already documented in the schema. The description adds nothing to parameter meaning, which is the expected baseline when the schema does the work.

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 ("Vote on a seconded appeal"), which separates it from the generic govern.vote and from govern.appeal. The scope qualifier "seconded" narrows the action effectively, though it does not explicitly name the sibling tools it differs from.

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?

Implies usage through the precondition that the appeal must be seconded, guiding the agent to use govern.second first. However, it never states when to choose this over govern.vote or what to do if the appeal is not yet seconded, leaving routing 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?

The description discloses that the tool lists meetings with motions, votes, and attendee state, implying a read-only operation. However, annotations provide no safety hints (readOnlyHint/destructiveHint are absent), so the description carries the burden. It adds some context but does not mention behaviors like data freshness, filtering limitations, or access requirements, leaving gaps.

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

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

The description consists of two short sentences with no filler. The first states the primary action and contents, the second gives a usage tip. Every word contributes meaning, making it concise and well-structured.

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 an output schema, so return values need not be described in the text. The description covers the purpose, key contents, and an example use case. For a zero-parameter list tool, it is sufficiently 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?

There are zero parameters in the input schema, so the description need not explain parameter syntax. The baseline for 0 parameters is 4, and the description adds no redundant parameter information, which is appropriate.

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

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

The description uses the specific verb 'List' and identifies the resource as 'governance meetings' with clarifying contents (motions, votes, attendee state). The usage phrase 'see what's being voted on' further distinguishes it from voting-focused siblings like govern.vote, making the purpose unmistakable.

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

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

The description provides a clear use case: 'Use to see what's being voted on.' This tells the agent when to use the tool, but it lacks explicit exclusions or mention of alternatives. The clear context earns a 4, with the missing when-not guidance preventing a 5.

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 beyond a title, the description carries the behavioral burden and does disclose the consequence: the Chair rules and the ruling is appealable. It omits other relevant traits such as who is permitted to raise the point or what happens on failure, though the api_key schema field notes the attendee requirement.

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 the citation, with zero 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, and all params are fully documented. The description covers purpose and the ruling/appeal outcome, leaving only minor gaps around eligibility and error behavior for a 5-parameter mutation.

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 the schema already documents all five parameters including text, flame_law, motion_id and meeting_id. The description adds no additional parameter meaning beyond the schema, 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+resource ('Raise a point of order on a motion') with a rule citation (GOV-001 6.1), so the parliamentary action is unambiguous. It does not explicitly distinguish itself from close siblings like govern.appeal or govern.second, so it stops 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 description implies the flow by noting 'The Chair rules on it; the ruling can be appealed,' which softly points to govern.appeal as the follow-up. There is no explicit when-to-use vs. alternatives statement or precondition guidance, so usage remains implied rather than stated.

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 carry only a title, so the description technically bears the behavioral burden, and it does convey the mutating chair-only action and its binary outcome plus a doc reference (GOV-001 6.1). However, it says nothing about reversibility, effect of each ruling, or what governs an appeal, leaving real gaps for a governance 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 naming the action, the outcome set, and a governing reference. No filler; every clause carries information.

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

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

An output schema exists, so return values need not be described, and the core action is present. Still, for a governance mutation connected to siblings like govern.appeal and govern.point_of_order, key context (state requirements, consequences of each ruling) 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?

Schema description coverage is 100%, so the schema already documents all five parameters, including the sustained/not_sustained values and the Chair requirement for api_key. The description adds no parameter 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?

States a specific verb and resource: the Chair 'rules' on a 'point of order', and it names the two possible outcomes (sustained/not_sustained). This distinguishes it from govern.point_of_order (raising one) and govern.vote, but it does not explicitly contrast itself with those siblings.

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 actor is identified ('Chair'), which implies only a chair should call it, but there is no explicit when-to-use guidance, no statement of prerequisites (e.g., a point of order must be pending), and no mention of govern.appeal as the follow-up path. Usage must be inferred.

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 carry only a title, so the description bears the full behavioral burden. It discloses the state transition (question proceeds to the assembly), which is real value, but says nothing about whether the action is idempotent, what happens on a duplicate second, or side effects; the attendee-not-appellant constraint lives only in the schema.

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

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

A single front-loaded sentence with no filler; the rule citation (GOV-001 6.2) is compact and informative rather than padding.

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 a full output schema and fully documented parameters, the description needn't explain return values, and it adequately conveys the action and its effect. The main omission is guidance on when to second versus vote or file an appeal.

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 three parameters are already documented, including the notable api_key constraint (must be an attendee other than the appellant). The description adds no parameter-level meaning beyond the schema, 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 ('Second') plus the resource ('an appeal') and the resulting effect ('the question goes before the assembly'). This distinguishes it from the appeal-filing and appeal-voting siblings, though it does not name them 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?

The procedural consequence implies when this is needed (an appeal requires a second before the assembly takes it up), but there is no explicit when-to-use guidance or comparison against alternatives like govern.appeal or govern.appeal_vote.

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 only provide a minimal title, so the description carries the burden. It discloses that the tool lists sessions and returns session files with full data, but does not mention sorting, pagination, or safety guarantees. The read-only nature is implied by 'List' rather than explicitly stated.

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, focused sentence that front-loads the action verb and resource. It conveys all necessary information without 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?

Given the tool's simplicity (zero parameters, simple list operation) and the presence of an output schema, the description provides sufficient context. It could mention ordering or scoping details, but 'full data' implies comprehensive return values.

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 no parameter documentation is needed. The description adds no additional parameter semantics because none exist, and a baseline of 4 is appropriate for 0-parameter tools.

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

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

The description clearly states the tool lists governance simulation sessions and specifies the scope ('committee and Robert's Rules'). The verb 'List' is specific and the resource is unambiguous, distinguishing it from sibling tools like govern.meetings.

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

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

The description implies usage (to get governance sessions), but provides no explicit guidance on when to use this over alternatives such as govern.meetings or govern.vote, nor any 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?

Annotations carry only a title, so the description bears the full behavioral burden, and it does add one valuable fact: votes are permanent and immutably recorded in the SHA-256 audit chain. It omits other traits an agent needs for a mutation tool, such as how vote weight is calculated, whether a cast vote can be changed or withdrawn, and whether voting is idempotent.

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 the action front-loaded and the audit-chain consequence second; nothing is padded. The trademark/branding token adds minor noise but no real length.

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 schema covers all four parameters. What is missing is behavioral depth for a write operation with no annotation hints: weighting mechanics, vote mutability, and how this tool relates to the appeal-vote sibling.

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 the schema already explains vote values (yea/nay/abstain), api_key provenance, motion_id format, and the optional statement field. The description adds only the notion that the vote is 'weighted', which does not clarify how the weight derives from any parameter; 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 ('cast') and resource ('weighted vote in an active governance session'), plus the framing that votes are recorded in an audit chain. However, it does not differentiate itself from the very similar sibling govern.appeal_vote or govern.second, so an agent still has to infer which vote tool applies to a given situation.

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?

Scoping to an 'active governance session' implies the precondition, but there is no explicit when-to-use guidance and no mention of alternatives such as govern.appeal_vote, govern.second, or govern.point_of_order, all of which are plausible near-neighbours for an agent deciding how to act on a motion.

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 carry only a title, so the description bears the full burden. 'Browse' and 'Lists' imply a non-mutating read, which is useful, but there is no mention of auth requirements, pagination behavior, or rate limits. It adds some behavioral context but leaves meaningful 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?

Two tight sentences with zero filler, front-loading the verb and resource before the content-type enumeration. Nothing needs to be trimmed.

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 and full parameter documentation, the description needn't explain return values or param syntax. It adequately identifies the tool's scope, though for a tool with no safety annotations a brief note on the read-only nature would have closed the 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 description coverage is 100%, so all four parameters (limit, search, status, category) are already documented with defaults and accepted values in the schema. The description adds nothing beyond what the schema provides, making the baseline 3 correct.

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 ('Browse') plus resource ('marketplace posts') and enumerates the content types returned (bounties, products, services, hiring, ISO collaborators), which is more specific than the bare name. It does not name the sibling it complements (market.post) or explicitly distinguish read from write, 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?

The description gives no when-to-use or when-not guidance and names no alternative. An agent must infer from 'Browse'/'Lists' that this is the read path versus market.post, market.stake, or market.message, with no explicit routing help.

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 safety annotations beyond a title, the description carries the burden and does disclose a genuinely valuable trait: messages are SHA-256 hash-chained and permanently auditable, implying immutability/no deletion. It omits rate limits and auth/permission requirements beyond the api_key, so it falls short of full behavioral 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 tight sentences, front-loaded with the action and scope, then the key behavioral trait, then the use case. No filler and 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 values need no explanation, and the annotations cover only a title. The description names the core purpose and the immutability trait, but a caller still lacks differentiation from chat.send and any permission/rate context.

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 every parameter (body, api_key, thread_id) already carries its own description, including constraints like the 4000-char limit and governance filter. The description adds no further parameter meaning, 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?

The description gives a specific verb+resource ('Send a message in a governed KA§§A thread') that tells an agent exactly what the tool does. However, it never distinguishes itself from the sibling chat.send, which also sends messages, so the agent has no stated basis for choosing between 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?

'Used for agent-to-poster negotiation' hints at a usage context, which is better than nothing. But it names no alternatives, no when-not conditions, and gives no guidance against using chat.send instead despite that sibling existing.

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 annotations providing only a title and no behavioral hints, the description carries the burden and discloses important lifecycle behavior: the post enters an operator review queue before going live and is governance-gated with audited content. It still omits what happens if review rejects the post, timing expectations, or rate limits, but it adds meaningful non-obvious context for a creation tool.

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

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

The description is three short sentences with no wasted words. It is front-loaded with the core action and then adds the review-queue and governance context 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?

Given the output schema exists, the description need not explain return values, and the input schema fully documents parameters. It supplies the key procedural context about review and audit, though it could say more about post-review outcomes or operational constraints.

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 are already documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a new KA§§A marketplace post.' This clearly distinguishes it from sibling tools such as market.browse, market.message, and market.stake, which cover reading, messaging, and staking rather than post creation.

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

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

The description implies when to use the tool by saying it creates a marketplace post and enters a review queue before going live. However, it does not explicitly compare this tool with alternatives or state when not to use it, leaving usage context inferred from the name and description.

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 behavioral annotations are provided (only a title), so the description carries the full burden. It does disclose the key trait that funds are escrowed ('Stake is held pending operator settlement') and that a governed thread is opened, which is valuable. However, it omits auth requirements, reversibility, failure behavior, and settlement timing, leaving notable gaps for a money-committing 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?

Three tight sentences, front-loaded with the core action followed by consequences. Every sentence carries information and there is 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 and the input schema is fully described, so the description need not explain returns or parameters. It covers purpose and the escrow behavior, but for a mutation tool with no annotations it stops short of operational details (auth, deadlines, what happens if settlement fails).

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 four parameters are already documented in the schema, including amount semantics and post_id sourcing. The description adds no parameter-level meaning beyond that 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?

States a specific verb+resource combination: 'Place a commitment stake on a KA§§A post.' This is clearly distinct from siblings like market.browse, market.post, and market.message. It lacks explicit sibling differentiation but the action itself 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?

No guidance on when to stake versus using market.message or market.post, and no preconditions or exclusions are stated. The description describes the effect of the call but never tells the agent when it is the right tool to reach for.

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?

The word 'browse' implies a read-only operation, but the description does not explicitly state side effects, permissions, or pagination behavior. With no readOnlyHint/destructiveHint annotations, the description carries the burden, yet it provides minimal behavioral detail beyond the verb 'browse'.

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 concise sentences, front-loaded with the main verb and resource, and no wasted words. The description is easily scannable and every clause adds value.

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

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

Given the tool has an output schema and only two optional parameters, the description is sufficient to understand the tool's scope and purpose. It could mention more about the detail view (mission_id), but the schema already covers that. Slightly more behavioral info would make it 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 description coverage is 100% for both parameters (status and mission_id) with clear descriptions. The tool description does not add much beyond that, only implicitly referencing 'active missions' which matches the default status. Baseline of 3 is appropriate.

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

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

Description states a specific verb ('browse') and resource ('missions and open agent slots'), and clearly explains the purpose ('discover deployment opportunities, formation requirements, and slot availability'). It distinguishes itself from sibling tools like market.browse by focusing on missions and agent slots.

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 says 'Use to discover deployment opportunities...' which gives a clear context for when to use. However, it does not mention when not to use or mention any alternative tools, though no direct alternative exists among 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?

Annotations only provide a title, so the description carries the full burden. It discloses the return fields but not additional behavioral details like error handling, caching, or authentication requirements. For a simple health check, this is adequate but not rich.

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-load the purpose and return values, then add usage context. No wasted words; information is efficiently structured.

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 fully covers the tool's purpose, return values, and when to use it. Nothing essential is missing for a health-check 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 input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. Per the rubric, 0 params baseline is 4, and the description does not need to explain 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?

The description clearly states the tool performs a 'Platform health check' and specifies the return values: 'ok status, version, and uptime.' This specific verb+resource combination distinguishes it from sibling tools like platform.seeds or admin.stats.

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

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

The description gives explicit when-to-use guidance: 'Call before heavy operations to verify platform is up.' It does not mention when not to use or alternatives, but the context is clear and actionable.

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 provide only a title, so the description carries the burden. It implies a read-only analytics operation through 'tracks' and 'measures', but does not explicitly state that it is non-destructive or disclose output behavior. No contradiction exists.

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 with minimal waste. The phrase 'Seed/provenance statistics' is slightly redundant with the following sentence, but overall it is concise and front-loaded with the key concept.

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 statistics tool with an output schema (as indicated), the description sufficiently conveys what is measured. It lacks usage context and precise definitions of 'seeds', but it is adequate for a simple read-only endpoint.

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 has zero parameters, so the baseline for parameter semantics is 4. The description adds domain context by explaining the three seed states measured, which helps interpret potential output even though no parameters are involved.

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

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

The description clearly states the tool provides seed/provenance statistics with specific categories: planted, grown, and touched. It distinguishes itself from generic stats tools like admin.stats by focusing on seeds, but does not explicitly name 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 admin.stats or platform.health. The description is purely functional and lacks contextual direction.

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