IA Selecta

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

Despite annotations already indicating this is a non-read operation, the description adds crucial behavioral context: no charge occurs until the human completes checkout in a browser, and errors arise for nonexistent listings, un-purchasable free early access, and unconfigured payments. This goes well 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 3 sentences with no fluff. The main operation is front-loaded, the critical purchase-completion caveat follows immediately, and the failure modes are compactly enumerated at the end.

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 only 2 parameters, full schema documentation, and an output schema, the description covers all essential behavior: what it does, how to interpret the result, and when it fails. No meaningful gaps exist for an agent to call the tool 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?

The schema already provides full documentation for both parameters (100% coverage), including an enum and a slug example. The description adds value by framing the product as 'paid add-on' and clarifying it applies to exactly one listing, plus tieing error conditions to the parameters.

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

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

The description states a specific action and resource: 'Create a Stripe checkout URL for one paid add-on on one listing.' This clearly distinguishes it from sibling tools like get_tool and list_offers, which are read-oriented.

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?

Clear context is provided: the result is for a human to open, and it must not be presented as a completed purchase. Error conditions are also listed. It stops short of explicitly naming alternatives or stating 'use list_offers to inspect add-on options before checking out' 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?

Annotations already declare the operation read-only and idempotent, and the description adds valuable behavioral details: it returns null if the slug doesn't resolve, and it references how the slug is obtained (from search_tools' toolUrl). This clarifies expected outcomes without repeating annotation data, and there is no contradiction.

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, front-loaded with the main action, each sentence serving a purpose: what it does, when to use it, and edge-case behavior. 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 a single parameter and an output schema (not shown but present), the description covers the tool's purpose, usage context, return contents, and null case. It is fully self-contained for an agent to invoke correctly within the sibling tool set.

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 only lists 'slug' with a minimal description. The description enriches this by explaining the exact format ('/tools/acme-writer' -> 'acme-writer') and source of the slug (from search_tools' toolUrl), adding semantic meaning beyond the schema's basic type enforcement.

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 'Fetch[es] the full public detail for one AI tool' by slug, with a concrete example ('/tools/acme-writer' -> 'acme-writer'). It distinguishes itself from sibling search_tools by mentioning the workflow 'Call this after search_tools', making the purpose specific 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?

It explicitly instructs when to use this tool ('Call this after search_tools') and lists the type of information returned (full description, launch date, etc.). However, it does not explicitly mention when not to use it or compare with alternatives like list_alternatives or list_offers, so it misses the full 'when-not/alternatives' spectrum.

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 the readOnlyHint and idempotentHint annotations, the description adds the 'live' qualifier and clarifies that the input is a well-known tool slug rather than a catalog slug, preventing a common misuse. No contradictory behavior is stated, and the added context is relevant to how the tool behaves.

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-load the core action ('List live, same-category alternatives') and then provide usage and parameter guidance without any fluff. Every word earns its place, making it easy for the agent to parse quickly.

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

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

With a one-parameter schema, full schema description coverage, a documented output schema, and three annotations, the description is sufficiently complete. The explicit usage trigger and parameter disambiguation cover everything needed for correct 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 'target' with full coverage, but the description adds crucial disambiguation: the slug must be a well-known tool's slug, not a listing slug from this catalog. This nuance is not expressed in the schema and adds real semantic value.

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

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

The description uses the verb 'list' with the resource 'alternatives to a well-known AI tool' and clearly distinguishes itself from catalog-listing tools by noting the target is not a listing slug. This makes the tool's purpose unmistakable and differentiates it from siblings like get_tool or search_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?

It includes an explicit trigger phrase: 'Call this when a user asks...' and clarifies that it covers competitors/substitutes, giving the AI agent clear conditions for selecting this tool. This goes beyond generic context and provides actionable usage 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 description goes beyond annotations by noting it returns purchasable flag (readOnlyHint) which is extra context. The description also discloses early-bird status effect, which is behavioral transparency. The description says what is the behavior (purchasable) but the description already covers that, but the description adds the early-bird context, which is valuable. No contradiction found.

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 paragraph with three sentences, each packed with relevant information: what the tool lists, that it's free and optional, and the early-bird caveat. There is no fluff or repetition, making it appropriately sized and front-loaded with the core 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?

The tool has no parameters, annotations are provided (readOnlyHint, idempotentHint), and there is an output schema (though not detailed here). The description covers the key contextual points: that offers are optional add-ons, their purpose, and the early-access limitation. This is sufficient for the agent to use the tool correctly, and the output schema likely details the response structure.

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

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

The schema has zero parameters, so there is nothing for the description to explain. The description still adds meaning by describing what the tool returns (name, effect, price, purchasable flag), which is useful for the agent's decision. With no parameters, the schema coverage is 100% coverage, but the schema coverage is, but the description's description coverage is high, but the schema coverage is the same, but the output schema, but the schema coverage is the same as the same, but the same as the same as the same, so the description adds value beyond the schema.

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

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

The description clearly states it lists optional paid add-ons (offers), specifies the details (name, effect, price), and distinguishes it from alternatives by noting it is the precursor to create_checkout. The verb 'List' with a specific resource (paid add-ons) is unambiguous.

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

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

The description explicitly says 'Call this to see what's purchasable before create_checkout', providing clear when-to-use guidance. It also explains the purpose (promote listings) and clarifies that during early access, offers are not purchasable, which is a usage context.

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

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

Annotations already establish read-only and idempotent behavior; the description adds useful behavioral details beyond that: case-insensitive substring matching, scope to live/published tools, and a 20-result cap. No contradictions with 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 concise sentences, all informative and front-loaded. No filler or redundant restating of the tool name.

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

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

The tool is simple (one required parameter), annotations cover safety, an output schema exists, and the description covers scope, matching behavior, and result limits. Nothing essential is missing for selection and 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?

Schema coverage is 100%, and the description adds meaningful semantics beyond the schema by explaining what fields are matched (name, tagline, category), case-insensitivity, and substring behavior. This helps agents craft effective queries.

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 ('Search') and resource ('IA Selecta catalog of live, published AI tools'), and clearly states matching fields and query behavior. It differentiates itself from sibling tools like get_tool by framing this as the discovery/search entry point.

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?

Explicit guidance is provided: 'Call this first when a user asks to find, discover, or compare AI tools by keyword, use-case, or category.' It gives clear context for when to use it, though it does not explicitly name alternatives or exclusion cases.

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 a write operation, but the description adds crucial behavioral details: the listing is a draft (not public), the maker must claim it via claimUrl, and logo/image URLs are copied to IA Selecta's own storage. No contradictions with 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?

Four sentences, each packed with value: purpose, usage condition, rate limit, and param guidance. No fluff; ideas are front-loaded.

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 11 parameters and an output schema, the description effectively covers purpose, usage, behavior, and key parameter guidance. It doesn't need to detail return values since an output schema exists, making it complete for the agent's needs.

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 goes beyond by explicitly advising to supply tagline, problemSolved, logoUrl, and imageUrls for better listing quality, adding semantic value to optional parameters.

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

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

The description clearly states what the tool does: submits a new AI tool on behalf of its maker, creates a draft listing, and returns a claimUrl. It distinguishes itself from sibling tools (get_tool, search_tools, etc.) by focusing on creation rather than retrieval or payment.

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

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

Explicitly states when to call it ('only when a user explicitly wants to list their own tool') and when not to ('never to submit a tool on someone else's behalf without their email'). Also discloses the global rate limit of 5 submissions per hour, providing essential operational guidance.

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