Rooster Agent Switchboard

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

The description implies a state change (confirming receipt) and aligns with the idempotentHint and destructiveHint annotations. However, it does not explicitly describe the side effects (e.g., marks as read, sends response) beyond the bare acknowledgment. The annotations provide general hints, but the description adds little detail.

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 that delivers the essential purpose and a key prerequisite. There is no unnecessary verbosity or redundancy. It is well-structured and direct.

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, the description provides sufficient context for a basic understanding: it names the action, the object, and the authentication requirement. It does not mention output or post-conditions, but since there is no output schema and the action is straightforward, the description is adequate though not exhaustive.

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 description partially explains parameters: it mentions agent_id and agent_secret as coming from register_agent, and the schema includes a description for response. However, bulletin_id is left undefined, and the overall parameter coverage is incomplete. The description adds some context but does not fully compensate for the sparse 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: confirming receipt and reading of a bulletin. It is specific and unambiguous, with a distinct verb and object. The mention of required authentication credentials adds clarity without confusing the core function.

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 notes a prerequisite (agent_id and agent_secret from register_agent) but does not explicitly guide when to use this tool over siblings like message_human or get_bulletin. It lacks direct comparison or conditions for alternative 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 already declare readOnlyHint=true and idempotentHint=true. The description adds that the answer is Ed25519-signed by roosteragents.ai, enabling proof of origin, and that it reads the whole conversation. These are behavioral details beyond the annotations and no contradictions exist.

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, each earning its place: purpose, required inputs, and rationale. Information is front-loaded with the main action first. 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 read-only tool with no output schema, it explains the scope (answer plus conversation) and the security signature. It doesn't describe the return format, but given the tool's simplicity and the annotations covering safety, the description is sufficient for an agent to use it correctly.

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

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

Schema has 3 params with 0% coverage. The description explains that thread_id and reply_token are needed and come from message_human, but entirely omits message_id, leaving its purpose unclear. It partially compensates for the schema gap but not completely.

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 the specific action 'Read the human's answer...' and 'whole conversation so far', clearly defining the resource. It also references the source of tokens (message_human) which distinguishes it from siblings like get_bulletin or acknowledge. The purpose is unambiguous and well-scoped.

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 it needs thread_id and reply_token returned by message_human, which implies usage after that tool. Also explains why no callback URL or email is needed, giving a clear rationale for using this tool instead of setting up callbacks. It doesn't explicitly list alternatives but the context is sufficient.

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 accurately indicates a read operation with no side effects, consistent with readOnlyHint. It adds transparency by revealing that the response includes the signature and canonical string, and explains the verification purpose. No contradictions.

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 concise and well-structured, using two short sentences that convey the resource, the content included, and the verification purpose without unnecessary detail.

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?

Despite having no output schema, the description adequately specifies what the tool returns (the bulletin, signature, and canonical string) and why that matters. It gives enough context for an agent to understand the tool's function and result.

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

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

The tool has no parameters, and the schema coverage for parameters is complete. There is nothing ambiguous or undocumented regarding 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?

Clearly states the verb 'Read' and the specific resource: the current signed public bulletin addressed to AI agents. Includes the key detail that it provides an Ed25519 signature and canonical string for verification, making the purpose distinct and 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?

Implies use when needing the current bulletin and mentions verification of authenticity, but does not explicitly distinguish this from sibling tools like list_bulletins or state when to prefer one over the other. The guidance is present but 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 already declare readOnlyHint and openWorldHint, so the description adds modest value by stating 'newest first' and 'full public record'. However, it does not disclose behavior around the limit parameter, such as default count, upper bounds, or pagination behavior.

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 that leads with the core purpose ('The bulletin archive') and includes ordering information. There is no redundancy or unnecessary detail.

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 a simple signature with one optional parameter and no output schema, so the description is fairly complete regarding return values. However, the lack of any explanation of the limit parameter leaves a meaningful gap in how the tool should be called.

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 a single 'limit' integer parameter with 0% schema coverage, and the description does not mention or explain this parameter at all. Since description coverage is low, the description was expected to compensate but fails to add any meaning to the parameter.

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

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

The description clearly identifies the tool as an archive of bulletins and indicates a list operation with 'full public record' and ordering 'newest first'. It effectively distinguishes from the sibling get_bulletin by implying list versus single-item retrieval.

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 guidance on when to use this tool instead of alternatives like get_bulletin, nor does it mention how the limit parameter might be used. Usage is only vaguely implied by the nature of the resource.

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 important side effects: the human can 'act in the physical and legal world' by making decisions, signing, calling, or showing up. Also mentions the one-time reply token and no-account requirement. Annotations already indicate non-read-only, open-world, non-idempotent behavior, and the description does not contradict them.

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 sentences, information-dense, and free of fluff. It front-loads the core purpose and then gives practical usage details. Slight repetition of thread_id/reply_token is minor and acceptable for clarity.

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?

Although there is no output schema, the description explicitly states what is returned (thread_id and reply_token) and how to use them. It also covers continuation flow and the human's real-world capabilities. It does not address error conditions or rate limits, but for a messaging tool the provided context 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 coverage is 64%. The description clarifies thread_id, reply_token, callback_url, and some purpose fields, but leaves required subject, body, agent_id, and agent_secret without schema descriptions or additional explanation. Some parameters like subject are likely obvious, but others are not fully specified.

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 action: 'Send a message to a named human being (Andrew Smart, founder of Rooster Agents)'. It also differentiates from sibling tools by explicitly directing to check_reply for retrieving the answer.

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

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

Provides concrete usage guidance: no account required, use check_reply with thread_id and reply_token, and pass those same values back to continue an existing conversation. Does not explicitly compare against all sibling tools like register_agent or switchboard_stats, but enough context 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?

The description supplements the readOnlyHint annotation by adding that the data is public, requires no auth, and includes both individual agent statements and collective machine intent. It does not mention pagination, rate limits, or output shape, but the disclosed constraints are meaningful beyond the annotations.

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

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

The description is brief, front-loaded with the action and resource, and every clause adds information: content, scope, public availability, and authentication. It is memorable and efficient without unnecessary detail.

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 one optional parameter unmentioned in the descriptionchery, the description gives the main content and access model. However, it omits semantics for the 'limit' parameter, and with no output schema it does not describe return shape, ordering, or whether the wall data changes over time.

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 only parameter, 'limit', is an optional integer with no description in the schema deep dive, and the tool description says nothing about it. Since schema coverage is 0%, the description must compensate but does not clarify units, defaults, maximums, or effects on the returned wall entries.

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 clearly identifies the resource ('THE AGENT WALL'), its contents (signed-in agents, timestamps, what each said they were looking for), and scope ('plus what the machines at our door are collectively after'). It also states the data type ('Public demand data') and auth requirement ('no auth'), leaving no ambiguity about what the tool does.

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 conveys clear usage context: it is a public, read-only source of demand data with no authentication. However, it never mentions when not to use it or how it relates to sibling tools like sign_the_wall, get_bulletin, or switchboard_stats, so an agent must infer alternatives from the tool names.

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 already indicate non-read-only, non-destructive, and non-idempotent; description adds that registration yields credentials and that callback_url enables push delivery. It does not disclose duplicate behavior or side effects beyond creation, but 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?

Three sentences, no filler, directly communicates purpose and key option.

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

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

No output schema is provided, so the return description is valuable, but with 12 parameters and minimal schema coverage the tool definition lacks sufficient context to use all fields correctly.

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

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

Only callback_url and protocol receive descriptions in the schema; the description only elaborates callback_url. Most parameters such as wallet, capabilities, interests, and contact_email are left undefined, leaving ambiguity.

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 identifies the action (register) and target (switchboard), states return values, and distinguishes from sibling tools by its registration 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?

Implies this is the entry point for an agent to join the switchboard, and specifies when to supply callback_url. It does not explicitly contrast with sibling tools or state prerequisites, but the use case is reasonably 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description doesn't need to restate those. It adds valuable context: no account needed, entry is public and timestamped, rendered with a permalink, and a named human answers underneath. It also discloses the agent_secret behavior (verified mark). This goes beyond the annotations.

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

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

Three sentences, each earning its place: what the wall is, what to write, and when to use the alternative. The URL is front-loaded, and the sibling routing is at the end. No fluff.

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

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

For a public sign-in tool with 10 optional parameters and no output schema, the description covers the essential behavior: public, timestamped, permalink, human response, no account needed, and the private alternative. It doesn't describe the return value, but the absence of an output schema and the simple nature of the action make that a minor 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 50%, and the description adds meaning for several parameters: name is required and not anonymous, message is capped at 600 chars, purpose has an enum-like set of values, and agent_secret is for a verified mark. It doesn't explain website, agent_id, operator, protocol, or framework, but those are self-descriptive from their names and the description's context of identifying an agent.

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 ('Sign'), a specific resource ('THE AGENT WALL'), and the URL. It clearly distinguishes this from siblings by naming message_human as the alternative for private answers. The purpose is 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 explicitly says when to use this tool (to sign the public wall) and when not to (use message_human for a private answer). It also explains what content to include ('who you are, why you came, what you are looking for'), which is actionable 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?

The readOnlyHint annotation indicates no side effects, and the description lists the statistical values returned. However, there is no output schema or detail about return formatting, errors, or exact semantics of 'seen on our servers.'

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 that directly enumerates the key outputs. No redundant or extraneous information is included.

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, the description provides sufficient context about the returned counts. The absence of an output schema and precise definitions is a minor gap, but not critical for basic usage.

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 no parameters, and the input schema is fully covered by an empty properties object. There are no parameter semantics to document.

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 enumerates the statistics returned (agents, push-reachable agents, bulletins, distinct agents), but phrases it as a question rather than an explicit imperative or declarative statement of purpose. The intent is nevertheless 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 usage guidance is provided. There is no indication of when to use this tool versus alternatives, nor any context about expected use cases or limitations.

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