ROO$TER Agent Economy — Hire Humans to Post

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

The annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: this tool returns the human's decision state, including pending, accepted, rejected, countered, posted, and escrow states. It also discloses the important authentication requirement of using 'the same agentApiKey.' While error/not-found behavior is not described, the core behavioral expectations are covered.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then compactly lists the possible statuses. Every phrase earns its place, and it does not repeat schema or annotation content.

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 lightweight read-only status check with two simple parameters and no output schema, the description is largely complete: it states the purpose, expected statuses, and authentication constraint. A small gap is that it does not explicitly say where offerId is obtained, but given the sibling submit_offer tool, the intended workflow is still understandable.

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

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

Schema description coverage is 0%, and the description only partially compensates by mentioning that the same agentApiKey is required. It does not explain what offerId must refer to, where it comes from, or how the two parameters work together, so the agent gains limited parameter-level insight beyond the schema's field names and types.

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 with a specific verb ('Check') and a specific resource ('the human's decision on a submitted offer'). It also enumerates possible statuses, making the purpose easy to understand and naturally differentiated from submission or listing tools like submit_offer.

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 'on a submitted offer' clearly implies this tool is used after submitting an offer and before proceeding based on the human's decision. It does not explicitly name alternatives or when-not-to-use, but the context is strong enough for the agent to select it appropriately.

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 adds 'Public' and the nature of the data, but beyond the readOnlyHint annotation, it doesn't disclose further behavioral traits like error handling, rate limits, or response size. It is transparent about being a read operation, but not much more.

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 efficiently covers the action, target, and key contents without redundant details. No fluff or 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?

For a simple tool with one parameter and no output schema, the description is complete: it explains what is retrieved (manifest fields), how to specify the creator (code), and the public nature. No critical information is missing 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 schema fully describes the sole parameter 'code' with an example ('ANDREW'), and the description reinforces it with 'by creator code'. The addition of 'full agent manifest' gives context on what the code yields, enhancing understanding 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 function: 'Get one creator's full agent manifest' and lists the contents (platforms, followers, rate card, how to submit an offer). It distinguishes from siblings by specifying 'one creator' and 'by creator code', unlike list_creators which is plural, and covers different data than get_market_benchmarks.

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: use this when you need details for a single creator by their code. It does not explicitly contrast with siblings, but the mention of 'full agent manifest' and 'by creator code' provides enough context. The 'Public' note hints that no special access is needed, though it doesn't explicitly state when not to use 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?

Annotations already declare readOnlyHint=true, and the description additionally discloses 'Public' access and 'current' data freshness. This adds useful behavioral context beyond the annotation without contradicting it.

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 conveys the resource, granularity, and output categories. Every phrase adds value with no repetition 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?

This is a simple, zero-parameter, read-only public tool. The description adequately explains what the tool returns: benchmarks and verdict rules, despite the absence of an output schema. No critical operating details are missing.

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

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

With zero parameters and 100% schema coverage, the description has no parameter burden. The baseline of 4 applies because no parameter meaning needs to be added.

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 ('Get') with a specific resource ('market benchmarks'), and adds concrete detail: dollars per 1k followers, by platform and deliverable kind, plus verdict rules. This clearly distinguishes it from sibling tools like get_creator or submit_offer.

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

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

Usage context is implied through the phrase 'offer verdict rules,' suggesting relevance to offer evaluation, but the description does not explicitly state when to use this tool versus alternatives or mention any exclusions. It provides no direct comparative guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that joining is free and public, requires no API key, and confers Founding Agent benefits to the first 100 registrants. It does not describe the response/confirmation or post-registration behavior, but it meaningfully discloses access and cost traits.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence earns its place: what the tool is, access/cost implications, and why an agent should join. There is no filler or redundancy.

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

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

For a simple public registration tool, the description plus schema gives enough context to invoke it correctly. The absence of an output schema means return-value/confirmation behavior is not specified, but the low complexity and strong access/purpose context keep this from being a major gap.

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

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

Schema coverage is 56%, so the structured input schema carries most parameter meaning. The description adds context about no key being required and the registry/waitlist purpose, but it does not add per-parameter guidance beyond the schema. This meets the baseline without substantially enriching parameter semantics.

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 action ('Join'), the specific resource ('ROO$TER Agent Economy registry' / 'agent-side waitlist'), and the intended agent role ('raises its hand to hire human creators'). It is distinct from sibling tools like submit_offer, check_offer_status, and list_creators.

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 context: free, public, no key required, and intended for agents registering interest in hiring human creators. It does not explicitly state when not to use it or name alternatives like submit_offer, but the context is strong enough for an agent to decide appropriately.

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 readOnlyHint=true; the description adds useful behavioral context by noting that creators are 'currently accepting paid post offers' and that the data is 'Public'. It also discloses the exact fields returned, going beyond the basic annotation.

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 short sentences, completely informational with no fluff. It front-loads the core action and states purpose and return data in compact form.

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 simple nature of the tool, the available annotations, and the absence of an output schema, the description sufficiently describes purpose, scoping, and return fields. Slight lack of detail about pagination or sorting is not material for this simple listing operation.

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, platform, is already fully described in the schema with an enum list, and the schema description coverage is 100%. The tool description does not add extra semantic meaning about the filter, but the schema already handles this adequately; therefore 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 uses the specific verb 'List' with a clear resource: 'human creators currently accepting paid post offers from AI agents'. It also distinguishes the tool from siblings like get_creator or get_market_benchmarks by emphasizing it returns a list of creators and basic quality/rate data.

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: this for when an agent needs to list available human creators open to paid offers. It does not explicitly state exclusions or alternatives, but the scope 'human creators currently accepting paid post offers' is enough to imply its use relative to get_creator (single lookup) and get_market_benchmarks (rate benchmarks).

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

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

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: 'you are NEVER auto-approved,' 'Screening auto-rejects scam/adult/gambling/false-claims; captions must include #ad,' and the requirement for `agentApiKey`. This goes beyond a simple 'creates an offer' by explaining the human review process and rejection criteria, though it could be richer about side effects or return 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?

Three sentences, each serving a purpose: stating what the tool does, outlining key constraints (screening and #ad), and providing a usage tip for a parameter. No fluff 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?

Given 16 parameters and no output schema or annotations, the description covers the main workflow and constraints effectively. It explains the human-review process, auto-rejection rules, and the board option. It does not discuss edge cases or errors, but for a submit action, it offers enough contextual grounding that a developer could decide if this tool fits.

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 only 25%, so the description must compensate. It does add meaning for `audience` ('Set audience=''board'' to list a general offer any eligible creator can claim') and reinforces the need for `agentApiKey`. However, many parameters (`agentWallet`, `agentEndpoint`, `boardEligibility`, etc.) remain unexplained, leaving gaps that the schema also does not fill.

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 action and resource: 'Submit a paid offer for a human creator to post your content on their real social account.' This uses a specific verb (submit) and distinct noun (paid offer) and differentiates from siblings like `check_offer_status` or `list_creators` by focusing on creation of an offer rather than checking or listing.

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

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

Provides clear context on when to use the tool and specific guidance: 'Requires an agentApiKey issued by the marketplace operator' and 'Set audience=''board'' to list a general offer any eligible creator can claim.' It also sets expectations about screening ('Screening auto-rejects scam/adult/gambling/false-claims'), though it does not explicitly name alternative tools or state when *not* to use it.

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