AI Readiness (hosted)

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes that task descriptions are untrusted text and are never executed, providing valuable safety context for an agent. It also identifies itself as an official read API, confirming a read-only intent, though it omits pagination or error details.

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 only two sentences, with the core purpose front-loaded and the filter list and safety note efficiently appended. Every sentence adds distinct value; there is no redundant or filler 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?

Given the 6-parameter, no-annotation nature of the tool, the description covers the essential purpose, filter dimensions, and an important security guarantee. It does not describe the response shape, but for a browse/read tool, this omission is acceptable; the description still gives enough context for an agent to decide when to use it.

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 maps the main filter dimensions (lifecycle status, mode, tag, text, minimum reward) to the schema parameters, helping the agent understand how status, mode, tag, search, and min_reward_usdc relate. This compensates for the 50% schema coverage by providing organizational context for the filters. It does not explain the `limit` parameter, but that is self-explanatory with its schema default.

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 browses the current public TaskMarket inventory via an official read API, naming the resource (TaskMarket) and the action (browse). It distinguishes itself from siblings by focusing on inventory browsing rather than checking readiness, generating fix packs, planning delegation, or tracking individual tasks.

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 browsing/filtering public tasks but does not explicitly state when to use this tool versus alternatives. It offers no exclusionary guidance (e.g., 'for tracking a single task, use track_taskmarket_task'). The context is clear enough for common use, but the guidance is indirect.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly explains what the tool does (scores multiple facets) and returns (score, grade, fix) without ambiguity. The verb 'Check' implies a non-mutating operation, and the note 'Free' adds a cost context. However, it does not mention potential side effects like rate limits or network requests, though these are not critical for a check tool.

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

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

The description is concise and front-loaded with the primary purpose. It uses two sentences to convey the operation, the specific checks, and the output format. The addition of 'Free' is a minor extra detail, but it does not bloat the description. Structure is clear and scannable.

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 (one input parameter, no output schema), the description provides a complete picture: it checks multiple AI-readiness factors and returns a score, grade, and fixes. It does not describe how to interpret the results in the context of the sibling tool, but that is more of a usage guideline gap. For a standalone check tool, the description covers inputs and outputs sufficiently.

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 already provides a descriptive parameter `url` with an example format (example.com or https://example.com) and 100% schema coverage. The tool description does not add extra semantic detail about the URL parameter beyond what the schema provides, so the 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 'Check whether a website is visible to AI search engines' which is a specific verb-resource pair. It lists concrete aspects being scored (AI-crawler access, JSON-LD, title/meta, Open Graph, sitemap, llms.txt) and outputs (0-100 score, letter grade, specific fix). This distinguishes it from the sibling generate_complete_fix_pack, which implies fixing rather than checking.

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 a diagnostic use case but does not explicitly state when to use this tool versus the sibling generate_complete_fix_pack. There is no mention of exclusions or alternative tools. The context suggests it should be used to assess readiness before generating fixes, but this is only implied, not stated.

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

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

With no annotations, the description carries the full burden and does a good job disclosing the paid nature, license requirement, and that an invalid license returns purchase instructions plus a free starter pack. It stops short of covering rate limits or detailed error responses, but the disclosed behavior is substantial.

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 front-loaded with 'PAID' and a clear enumeration of outputs. It is slightly long due to the checkout URL and purchase instructions, but each sentence contributes necessary context.

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 (paid access, license validation), the description is remarkably complete: it explains the deliverable, the purchase flow, the license requirement, and the no-license fallback. Even without an output schema, the listed fix-pack components give the agent a solid understanding of what to expect.

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 the baseline is 3. The description adds meaningful context by explaining that the license is obtained from a specific Stripe purchase and that omitting it triggers the fallback, going beyond the schema's simple description.

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

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

The description clearly states the tool 'Returns the complete, ready-to-paste AI-readiness Fix Pack' and enumerates its contents, making the purpose specific and identifiable. However, it does not explicitly reference the sibling tool check_ai_readiness to differentiate when to choose this over it.

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 clearly frames the use context: it is a paid tool requiring a license, with a purchase URL and a fallback behavior when no valid license is provided. It does not mention exclusions or direct alternatives, though the paid requirement and fallback imply when it should be used.

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 fully discloses the tool's non-mutating nature by explicitly denying task creation, wallet holding, and fund spending. It also describes the return value as a canonical TaskMarket API payload and approval summary, giving the agent a clear behavioral model beyond simple 'plan'.

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

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

The description is two sentences, front-loading the purpose and then key constraints. No filler words; every clause adds information about use cases, inputs, or behavior, making it concise and well-structured.

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

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

The description covers purpose, use cases, requirements, non-actions, and return value, providing a solid overview. Given the 8-parameter schema and no output schema, it is reasonably complete, though the exact output structure is only vaguely referenced as a 'canonical payload and approval summary'.

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 covers 75% of parameters with descriptions, including reward_usdc, deadline_hours, and acceptance_criteria. The description adds value by emphasizing the maximum-spend ceiling and the bounded nature of the delegation, enriching the max_spend_usdc parameter. However, it does not add significant detail for individual parameters beyond what the schema already provides.

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

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

The description uses a specific verb ('Prepare'), a clear resource ('TaskMarket delegation'), and identifies the bounded scope and supported use cases (research, coding, data collection, benchmarking, verification). It also distinguishes itself from siblings by explicitly stating it does not create a task, hold a wallet, or spend funds.

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 clearly states the use cases and prerequisites (deliverable, reward, deadline, maximum-spend ceiling). It also sets expectations that no funds are spent and no task is created, effectively telling the agent when not to use it for execution, though no explicit alternative sibling is named.

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

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

With no annotations provided, the description carries the full burden and succeeds. It states the operation is read-only, lists the returned data categories, and explicitly states actions it cannot perform. This gives a clear behavioral profile without needing 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?

Two sentences capture purpose, return contents, and non-actions. The content is front-loaded with the core function, and every sentence provides value without 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 a single required parameter and no output schema, the description is complete. It specifies what the tool does, what it returns, and what it cannot do. The rich return list and explicit non-actions provide sufficient context for safe invocation.

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

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

The schema already documents the single parameter (task_id) with a pattern and description. The tool description adds 'public TaskMarket task,' clarifying that the ID must refer to a public task, which is useful context 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 specifies the verb 'Track' and the resource 'one public TaskMarket task' via the official read API. It clearly distinguishes from sibling 'browse_taskmarket_tasks' by emphasizing single-task tracking and explicitly listing non-capabilities.

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 'one public TaskMarket task' provides clear context that this is for tracking a specific task, and the explicit exclusions (cannot create, accept, reject, rate, or refund) imply boundaries. However, it does not explicitly name alternative tools or provide explicit when-not-to-use guidance.

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