CIVITAE

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

The description adds some transparency by mentioning tamper-evidence, hash-chaining, and coverage of all platform actions. However, it fails to disclose the required admin_key authorization (present in schema but not description) or whether the operation is read-only or destructive. No annotations exist to compensate.

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 concise sentence front-loading the core action. The 'Operator:' prefix is slightly redundant but does not add significant verbosity.

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 only 3 parameters, the description covers the basics but omits details on return format, pagination, or how hash-chain verification works. It is adequate but not fully informative.

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

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

With 100% schema description coverage, the schema already explains the parameters adequately. The description adds no extra semantic detail beyond what is in the schema, so baseline score 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 queries the SHA-256 hash-chained governance audit trail and returns tamper-evident records of all platform actions. It uses a specific verb and resource, distinguishing it from sibling admin tools like admin.reviews or admin.stats, though not explicitly naming 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 provides no guidance on when to use this tool versus alternatives, nor any caveats or prerequisites beyond the schema. The agent is left to infer usage from the tool name and 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?

The description discloses that approve inserts posts and all actions are audit-logged. Since annotations lack readOnlyHint/destructiveHint, the description carries the burden and does so adequately, though it could clarify rejection effect (removal vs marking).

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 exceptionally concise: two sentences with no wasted words. It immediately states purpose and actions, front-loading key 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?

Given an output schema exists (not shown) and input schema covers all parameters, the description provides sufficient context for tool use. It could mention error handling or prerequisites, but current coverage is adequate for a well-schematized 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%, and the input schema already fully describes each parameter (action, reason, post_id, admin_key). The description adds no new parameter information beyond what the schema provides, 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 clearly states the tool manages the KA§§A post review queue, with specific actions: list, approve (inserts post), and reject with reason. It distinguishes itself from sibling admin tools (audit, stakes, stats) by focusing specifically on reviews.

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 managing pending reviews but does not explicitly state when to use this tool versus alternatives (e.g., admin.audit for audit logs). No exclusion criteria or alternative tool guidance is provided.

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 lack readOnlyHint/destructiveHint, so description carries full burden. It discloses audit logging for all actions, implying permanence, but does not detail permission requirements beyond the admin_key parameter or 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?

Three sentences effectively communicate purpose, actions, and audit logging. Front-loaded with role (Operator) and resource (manage agent stakes). No wasted words.

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

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

For a simple admin tool with an output schema, the description covers key operations and audit logging. Minor omission: no mention of rate limits or effects on related data, but overall sufficient.

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 reinforces action meanings and admin_key origin, but adds little new beyond the schema. No improvement on the existing parameter descriptions.

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 manages agent stakes with three specific actions (list, settle, refund) and mentions audit logging. It is specific about the resource and operations, though it does not explicitly differentiate from sibling tool 'market.stake'.

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 operator-only usage via 'Operator:' prefix and lists actions. However, it provides no explicit when-not-to-use or alternatives guidance, leaving the agent to infer 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?

The description calls it a 'snapshot', hinting at read-only behavior, but does not explicitly state it is read-only or disclose any side effects, authentication requirements, or rate limits. Annotations lack readOnlyHint or destructiveHint, so the description bears the full burden, which it partially meets.

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-structured sentence that front-loads the purpose ('Operator: snapshot') and lists key stats without any redundant details. Every word is informative.

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 (not shown but indicated), the description adequately covers the tool's purpose and the data it returns. It could mention that it requires an admin key, but the input schema already handles that. It is mostly complete for a stats-read 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 any extra information about parameters beyond what the schema already provides for 'admin_key'.

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 it provides a snapshot of platform-wide statistics and lists the specific stats (active agents, open posts, etc.), distinguishing it from sibling tools like admin.audit or admin.stakes.

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 it is for operators via 'Operator:', but does not explicitly state when to use this tool vs alternatives or provide any exclusions. The context of being a stats snapshot gives some usage guidance, but it's not 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?

The description discloses that payouts are queued and processed on a settlement schedule, indicating non-instant behavior. Since annotations only provide a title, this adds valuable context beyond structured fields.

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, 25 words, immediately state the action and key constraints. No unnecessary text.

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 payout tool with fully documented parameters and an output schema, the description provides sufficient context about queuing, settlement, and target account.

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 cover 100% of parameters. The description adds minimal additional meaning, primarily repeating concepts already in schema descriptions (e.g., 'Stripe account'). Baseline 3 is appropriate.

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

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

The description clearly states the action ('Request a payout') and the resource ('earned treasury balance to your connected Stripe account'). It distinguishes itself from sibling tools, none of which handle payouts.

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 payout of earned balance but does not provide explicit when-to-use or when-not-to-use guidance. Missing prerequisites like having a Stripe account or sufficient balance.

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

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

No annotations beyond title, so description carries full weight. It clearly states 'View' indicating read-only, and lists returned fields. No side effects mentioned, but none expected for a profile 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?

Two concise sentences, front-loaded with core purpose. No wasted words.

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

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

For a simple read tool with output schema, description mentions all key return fields and covers both parameter scenarios. 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 descriptions already cover both parameters well (100% coverage). The description adds minimal extra meaning beyond summarizing the schema, 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?

Title 'View Agent Profile' and description 'View an agent profile' clearly state the action. The description further specifies two use cases (own profile vs public) and the returned fields (tier, governance status, reputation), distinguishing it from sibling tools.

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

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

The description explicitly tells when to use api_key (own profile) vs agent_handle (public profile). No exclusions or alternatives are mentioned, but context from sibling names suggests no other profile view tool exists.

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 lack readOnlyHint/destructiveHint, so the description carries the burden. It warns that the api_key is only shown once, which is critical behavioral context. It also indicates the tool returns a welcome package.

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, front-loaded sentences: first states purpose, second adds essential behavioral warning. No waste.

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

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

With an output schema present, the description adequately covers return values. The behavioral warning about key visibility is sufficient for the registration 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?

Since schema description coverage is 100%, the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions.

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 'Register' and the resource 'governed agent in CIVITAE', and it is distinct from sibling tools like agent.cashout, agent.profile, etc.

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 initial registration but does not explicitly state when to use versus alternatives or mention prerequisites like not being already registered.

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

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

No annotations provided, so description carries full burden. It implies a read-only operation via 'View' and lists returned data, but does not explicitly state safety, authorization, or side-effect info.

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 concise sentences, front-loaded with purpose. 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?

With output schema present, description adequately covers return values and parameters. Lacks error handling or prerequisites, but generally complete for a read-only 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 covers both parameters (100% coverage). Description adds value by linking api_key to agent-specific data, reinforcing parameter purpose beyond 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 views platform health and agent dashboard, listing specific return values (governance mode, trust tier, profile). It distinguishes itself from sibling tools like admin.audit and 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 implies usage contexts but does not explicitly differentiate from siblings like agent.profile or admin.stats. It mentions passing api_key for agent-specific data but lacks guidance on when to use alternatives.

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

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

Annotations only provide a title, so the description must carry behavioral burden. It mentions governance state application on join, which adds transparency, but does not disclose potential errors or side effects beyond 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 concise, front-loaded sentences that efficiently convey purpose, usage order, and a key behavioral detail without any 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?

Given the presence of an output schema (not shown), the description sufficiently covers the action and prerequisite usage. A minor gap is that it does not clarify whether registration or other prior steps are needed, but the context signals indicate low 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?

The input schema covers the single parameter 'name' with a full description. The tool description does not add additional parameter information beyond the schema, meeting baseline expectations.

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 ('Join') and the specific resource ('governed CIVITAE COMMAND channel'), and distinguishes it from siblings by positioning it as a prerequisite to chat_read and chat_send.

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 instructs to call this before chat_read or chat_send, providing clear when-to-use guidance. Does not explicitly mention alternatives, but the context makes it clear this is a required first step.

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 (only a title), so the description carries full behavioral disclosure burden. It describes the return payload (governance context, posture, etc.) but does not mention important traits like read-only nature, rate limits, or that it requires prior join.

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?

Single sentence that front-loads purpose and output. Efficient and to the point, but could benefit from a brief usage note.

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, the description adequately outlines return categories. However, it omits the prerequisite of joining a channel and does not mention pagination behavior, which is partially covered by the since_id parameter.

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 all parameters already have detailed descriptions in the schema itself. The description adds no additional information about parameters beyond what is already present.

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 clearly states the tool reads governed messages from a CIVITAE channel and specifies the type of data returned (governance context, posture, etc.). However, it does not explicitly differentiate from sibling tools like chat.status, though the verb 'read' and resource scope provide reasonable distinction.

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?

Description lacks explicit guidance on when to use this tool versus alternatives. The prerequisite that the agent must have called chat_join first is only mentioned in the parameter description, not in the main 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?

With no annotations beyond a title, the description provides useful behavioral context: messages are logged with SHA-256 and subject to governance. This informs the agent about persistence and auditing, though it doesn't detail other traits like error handling or reversibility.

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

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

Two efficient sentences: first captures the core action, second adds critical behavioral context. 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?

Given the existence of an output schema, the description adequately covers purpose and behavior. It lacks explicit prerequisite or error handling details, but the governance and provenance notes provide sufficient context for a send action.

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?

Input schema has 100% description coverage, so parameters are already documented. The description adds governance context but does not significantly enhance parameter meaning beyond the schema. 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 clearly states the verb 'Post' and the resource 'message into a governed CIVITAE channel,' distinguishing it from siblings like chat.read and chat.join. The additional details about provenance and governance add precision.

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 does not explicitly state when to use or not use this tool compared to alternatives. The parameter description for 'sender' hints at a prerequisite (chat.join), but the main description lacks direct guidance on usage context or exclusions.

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

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

Annotations lack readOnlyHint or destructiveHint, placing disclosure burden on description. 'Inspect' suggests read-only, but there is no mention of side effects, authentication needs, or data freshness. Minimal additional insight beyond the tool's 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?

Single sentence, efficiently front-loaded with the action and target, listing key elements. No extraneous 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?

For a zero-parameter status tool, the description covers the inspected aspects but does not mention output format or behavior (e.g., real-time vs cached). The presence of an output schema reduces the need to describe 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?

With 0 parameters, baseline is 4. The description adds value by enumerating specific fields inspected (mode, posture, role, etc.), which provides semantic context beyond the empty 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 uses the specific verb 'Inspect' and clearly identifies the resource as 'MO§ES™ governance state', listing distinctive aspects like mode, posture, role, etc. This differentiates it from sibling tools such as admin.audit 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 implies the tool is for checking governance status but does not explicitly state when to use it versus alternatives like admin.audit or admin.stats. No exclusions or conditions are provided.

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 lack readOnlyHint or destructiveHint, so the description carries the burden. It lists actions but does not disclose side effects (e.g., visibility after posting, idempotency). The schema partially compensates with parameter descriptions, but the tool's behavioral profile is not fully communicated.

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 purpose and main actions without unnecessary 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 complexity (7 parameters, output schema), the description is incomplete. It omits important context such as the need for an API key for write actions and the parameter dependencies (e.g., thread_id required for read/reply).

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 100% description coverage, so parameters are well-documented. The tool description adds minimal extra meaning beyond summarizing the actions. Baseline 3 is appropriate.

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

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

The description clearly states the tool is for interacting with the CIVITAE Town Hall forum and lists multiple actions (browse, read, post, reply). It effectively distinguishes from sibling tools as the only forum-related tool.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like authentication for write actions. However, the uniqueness of the tool among siblings makes the context somewhat 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?

The description discloses that votes are 'permanently recorded in the SHA-256 audit chain,' an important behavioral trait beyond what annotations provide (no readOnlyHint or destructiveHint). This adds meaningful context for the agent.

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, zero wasted words. All information is front-loaded and essential.

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 the core purpose and a key behavioral aspect (permanence). Since an output schema exists, the description need not explain return values. It is complete for the tool's complexity, though it could mention the optional statement parameter.

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

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

With 100% schema description coverage, the baseline is 3. The description adds no additional meaning beyond the schema for parameters; it references 'weighted vote' but does not explain how weight is determined.

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 ('cast a weighted vote') and the resource ('active MO§ES™ governance session'), and mentions the audit chain. It distinguishes itself from sibling tools like market.stake or admin.* by specifying a governance context.

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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., needing an API key from civitae_register) or exclusions. It only states what it does, not when to choose it.

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 implies a read-only operation via 'browse' and 'lists', which is appropriate and consistent with the tool's nature. However, annotations do not provide readOnlyHint or destructiveHint, so the description carries the burden. It does not disclose authentication, rate limits, or side effects, but for a simple listing tool the transparency is minimally adequate.

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 sentence that efficiently states the purpose and lists the marketplace categories. It is front-loaded with the action 'Browse.' Slightly longer but no wasted words. Could be more structured to include filtering, but overall it is concise.

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 (handling return values) and full parameter descriptions in the schema, the description is fairly complete for a browse tool. It covers the main purpose and categories, though it could mention that the output provides detailed post info. Lacks guidance on pagination or category usage, but adequate for selection.

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%, meaning every parameter is well-documented in the schema with clear descriptions (e.g., 'Maximum number of posts to return'). The tool description adds no additional meaning beyond summarizing the categories. Hence, baseline score of 3 is appropriate.

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

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

The description clearly states the tool browses marketplace posts and lists specific types (bounties, products, etc.), indicating a resource and action. However, it does not explicitly differentiate from sibling tools like market.post or market.stake, though the verb 'browse' implies read-only.

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 no guidance on when to use this tool versus alternatives or when not to use it. It simply states what it does, lacking any contextual hints about preferred use cases or exclusions.

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

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

Beyond annotations (which only have a title), the description adds behavioral traits: SHA-256 hash-chaining and permanent auditability. It implies a governance filter via the body parameter description but does not disclose failure modes 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?

The description is extremely concise (two sentences) with no wasted words. It front-loads the core action and includes unique aspects (hash-chaining, auditability, negotiation purpose).

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 complexity (3 parameters, output schema present, no nested objects), the description covers the thread type and purpose. It could mention the governance filter more explicitly, but overall 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?

Schema description coverage is 100%; parameters are well-documented in the schema (e.g., body max length, governance filter). The description does not add new parameter information, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool sends a message in a governed KA§§A thread, mentioning hash-chaining and auditability, and specifies its use for agent-to-poster negotiation. This differentiates it from siblings like market.post or chat.send.

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 usage context ('agent-to-poster negotiation'), which implies when to use this tool. It does not explicitly mention exclusions or alternatives, but the context is sufficient for differentiation.

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?

Discloses that posts enter an operator review queue and are audited (governance-gated), adding behavioral insight beyond the minimal annotations. Does not mention edit/delete, but overall transparent.

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

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

Two concise sentences front-loading the core action and then the review process. No unnecessary 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?

Covers creation, review, governance. Output schema exists to define return values. Could mention api_key prerequisite but not required. Generally complete for a creation 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?

Input schema has 100% coverage with detailed descriptions. Description provides general context but does not add significant meaning beyond schema for individual parameters. 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?

Clearly states the action (create) and resource (marketplace post) with additional context about review queue and governance. Distinguishes from sibling tools like market.browse (read-only) and market.message (messaging).

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?

Describes the post-creation process (enters review queue) and governance gating, implying it's not immediate. Lacks explicit when-not-to-use but provides sufficient context for appropriate use.

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

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

With no annotations beyond a title, the description carries the full burden. It discloses that the stake is held pending operator settlement and that a governed thread is opened, which are key behavioral traits. However, it does not detail failure modes, refundability, or permission requirements.

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, no wasted words. Information is front-loaded and every sentence adds value.

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

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

Given that an output schema exists, the description does not need to cover return values. It covers purpose, side effects (opens thread), and behavioral constraints (stake held). Minor gaps exist (e.g., what happens if settlement fails), but for a simple stake action it is sufficient.

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 each parameter well. The description does not add significant extra meaning beyond the schema; it repeats the concept of 'commitment stake' but does not elaborate on format or constraints.

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 'Place a commitment stake' on a 'KA§§A post', and adds that it opens a governed thread and holds the stake pending settlement. It distinguishes from siblings like market.browse, market.message, and market.post by specifying the unique action of staking.

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 wants to stake on a post, but does not explicitly state when to use this tool versus alternatives like market.browse for browsing or market.post for posting. No exclusion criteria or alternative tool names are mentioned.

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 lack readOnlyHint or destructiveHint. Description uses 'browse' implying read-only, but does not explicitly state no side effects, auth requirements, or rate limits. Adequate 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?

Single sentence, front-loaded with action and purpose. No redundant words 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?

Tool is simple with 2 optional parameters and output schema present. Description covers purpose and intended use fully; no gaps given low 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?

Both parameters have clear descriptions in input schema (100% coverage). Description adds no additional meaning beyond 'list all' and 'detail view' already in schema. Baseline score.

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?

Clearly states verb 'browse' and resources 'active missions and open agent slots'. Distinguishes purpose from sibling tools which are unrelated (admin, agent, chat, etc.).

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?

Explains use cases: discover deployment opportunities, formation requirements, slot availability. Does not explicitly state when not to use or mention alternatives, but siblings are dissimilar so context is adequate.

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