toolfound

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

With no annotations provided, the description carries the full burden. It states it is non-destructive, 'reports ... RIGHT NOW', and 'Changes nothing'. This fully discloses the tool's read-only, side-effect-free nature, which is more than sufficient.

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 appropriately sized and well-structured. It front-loads the core purpose ('Non-destructive dry run'), provides detailed but necessary specifics in the middle, and ends with a crisp 'Changes nothing'. Every sentence contributes to understanding or usage guidance.

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?

Even without an output schema, the description enumerates the report contents (meta tag found/not found, DNS TXT found/not found, email qualification). It also clearly positions the tool relative to the verification flow, making it fully complete for its simple 1-parameter 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?

Schema coverage is 100% with a detailed description of the token parameter, so the baseline is 3. The tool description does not add specific parameter semantics beyond what the schema already provides, but the context of the dry run makes the token's role clear. The description adds marginal value over 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 is a 'non-destructive dry run of ownership verification' and enumerates exactly what it reports (meta tag, DNS TXT, email qualification). This specific verb+resource scope distinguishes it from the sibling toolfound_verify_submission, which it explicitly names.

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 to use it 'to distinguish my deploy is not live yet from wrong token' and 'before calling toolfound_verify_submission'. This provides clear when-to-use guidance and names the alternative, satisfying the dimension fully.

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 transparency burden. It discloses the verification process (magic link, meta-tag/DNS) and the benefits unlocked after claiming. It does not mention whether claiming is immediate/pending, reversibility, or what the API response looks like, which leaves some behavioral aspects open.

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 concise, front-loaded sentences. The first sentence states the purpose, the second explains verification, and the third lists unlocked benefits. Every sentence earns its place with no fluff or redundant details.

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 and key context (verification required, domain email, benefits), but lacks operational details such as whether claiming is immediate or pending, what happens after the call, or the outcome for already-claimed listings. Since there is no output schema, some of this burden falls on the description, leaving it incomplete.

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% for both parameters (slug and email), and both have clear descriptions. The description's email guidance ('use an address at the product's domain') mirrors the schema's 'ideally at the product's own domain', adding no new information beyond the schema. 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's function: claiming an existing listing as the product's owner with the qualifier '(free)'. It uses a specific verb+resource structure and is easily distinguished from sibling tools like getters, submit, or verify. The purpose 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?

It conveys when to use the tool—when you are the owner of a product and want to claim its listing—and provides context such as email domain requirements and alternative verification methods. However, it does not explicitly compare with alternatives or list exclusion conditions, e.g., 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?

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context about ranking and category, and states the output fields. However, it does not mention any potential limitations such as pagination, rate limits, authentication, or behavior when no alternatives exist. For a read tool, it provides moderate transparency but leaves gaps.

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-loaded with the core function, followed by use cases and output details. No wasted words — every sentence provides 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?

For a simple one-parameter read tool with no output schema, the description covers the key aspects: what it does, how results are ranked, and what data is returned. It is nearly complete, but could slightly improve by noting any constraints like pagination, but overall it is adequate.

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 100% description coverage with a clear explanation of the 'slug' parameter. The description does not add any additional semantics beyond the schema, so it meets the baseline but does not exceed it.

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 ('List') with a clear resource ('alternatives to a given product on toolfound') and specifies the scope ('tools in the same primary category') and ranking logic ('by community votes'). It clearly distinguishes from siblings like search_tools and get_product by focusing on 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 explicitly states when to use the tool: 'Useful for "alternatives to X" and comparison questions.' This gives clear context, though it does not explicitly name sibling alternatives or state when not to use the tool, which is why it does not receive a 5.

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 available, the description carries the burden of disclosing behavior. It reveals that badges deep-link to the listing, the embedder chooses rel freely, and listing status is never conditioned on embedding — useful context beyond a simple 'get'. It doesn't mention authentication or error handling, but for a read-only badge retrieval, this is 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 two sentences, front-loaded with the core action, and every clause contributes context about badge variants, optionality, and embedding implications. There is no fluff or repetition.

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 sufficiently tells the agent what it will receive (three embed snippets) and under what conditions (earned, optional). A note about the exact output format would make it complete, but it's already well-rounded for the tool's simplicity.

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 describes the single `slug` parameter with 100% coverage ('Slug of the listing to get badges for'). The description adds no additional meaning beyond the schema, so the baseline of 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 specific action: 'Get the three copy-paste badge embed snippets' and explicitly names the variants ('live on toolfound', 'verified', 'top 3 this week'). This distinguishes it from sibling tools like get_product or get_launch_status, which serve different purposes.

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 that badges are optional, earned, and do not affect listing status, which helps an agent decide when to call this tool. However, it doesn't explicitly name alternative tools or state conditions when not to use it, so it falls short of a perfect score.

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 full burden and does well: it enumerates output contents, horizon defaults, the suggested launch date, and explicitly assures 'no hidden queues.' It does not explicitly state read-only behavior or error semantics, but the behavioral detail is strong and trustworthy.

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 uses four sentences, each contributing meaningful detail: output contents, horizon and extra fields, a transparency claim, and integration with submit_product. It is longer than minimal but information-dense and front-loaded with the prime output.

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 one optional parameter, no output schema, and no annotations, the description covers the expected return data comprehensively and adds workflow context. It would benefit from stating the exact structure, but an agent can confidently invoke it and interpret the 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 only parameter, horizon_days, is fully documented in the schema with default and max values; the description merely restates that default/max without adding new semantic information. Since schema description coverage is 100%, 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 explicitly states the tool returns the upcoming launch calendar with per-date seat availability, including featured vs taken seats, total daily cap, queued launches, a suggested launch date, and remaining free slots. This goes beyond the title and clearly identifies the resource and what it exposes, distinguishing it from sibling tools like get_launch_status and submit_product.

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 provides explicit usage context: 'Use it to pick a launch date before submitting' and then references toolfound_submit_product for claiming the chosen date. This gives a clear workflow and sequential relationship with a sibling. It does not explicitly state when not to use it or contrast with alternatives, so the exclusion is only implied.

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. It details the return payload (state, queue position, launch date, listing URL) and adds a notable transparency guarantee ('toolfound never hides queue state — what this returns is exactly what everyone sees'). It doesn't cover edge cases, but for a read-only status tool this is sufficient.

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, front-loaded with the action, and every phrase contributes: the first sentence lists the return elements, the second adds a behavioral philosophy. 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?

The tool is simple (two optional params, no output schema), and the description fully covers the primary return values and behavior. It doesn't mention error handling, but that is a minor gap for a status lookup. The description is self-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% for both parameters, so the bar is baseline 3. The description adds the 'by submission id or product URL' alternative relationship, but this is also implied by the schema's url description ('Or the product URL you submitted.'), adding minimal new meaning.

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 opens with a specific action ('Check the status of a toolfound submission') and enumerates the exact data returned (state, queue position, launch date, listing URL). This clearly differentiates it from siblings like toolfound_check_verification and toolfound_get_launch_calendar.

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 provides a clear use case: checking launch status by submission id or product URL. It does not explicitly name alternatives or when not to use it, but the context is unambiguous and aligns with the tool's title.

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 of behavioral disclosure. It states that every launched listing is ownership-verified and lists the verification methods, adding context beyond a plain 'fetch.' However, it does not disclose error behavior for invalid slugs, potential pagination limits, or any side effects. It is a read operation, but the description does not mention read-only status or rate limits, leaving some uncertainty.

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 compact and front-loaded with the core purpose. It uses three sentences: the first lists the full scope of return fields, the second provides important ownership-verification context, and the third clarifies the inclusion of alternatives. Every sentence adds meaningful information with no fluff or repetition.

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 there is no output schema, the description reasonably covers the important return fields and gives background on ownership verification. It also mentions the canonical URL and inclusion of alternatives, which are likely useful for the agent. It could be more complete by specifying behavior for not-found slugs or whether the alternatives list is exhaustive, but for a simple getter 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?

The input schema has 100% description coverage for the only parameter 'slug', including an example and source context ('from search results or the listing URL'). The tool description adds only 'Fetch by slug' which is redundant. There is no additional semantic value beyond what the schema already provides, so the 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 uses the specific verb 'Fetch' and clearly identifies the resource as 'the full toolfound listing for a product by slug.' It enumerates the exact fields returned (description, tagline, pricing model, tags, socials, vote count, launch date, ownership-verification status, canonical URL), which differentiates it from siblings like get_badge (badge-only) or get_alternatives (alternatives-only). The scope is precise 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?

The description does not explicitly state when to use this tool versus alternatives. It mentions that the tool includes top alternatives, which could be confused with the dedicated get_alternatives sibling, but provides no guidance on which tool to choose for specific needs. There are no exclusions or conditions. The usage context is only implied through the resource 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, the description must carry the transparency burden. It adds useful context about community-vote ranking and ownership verification, but it omits return format, result limits, and pagination details, leaving transparency partial.

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 add value: definition, platform context, and usage suggestion. There is no fluff, and it is appropriately concise for the tool's simplicity.

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 with one enum parameter and no output schema. The description covers purpose, usage, and platform context, but because there is no output schema, it should explain return value characteristics, which it does not. Thus it is adequate but incomplete.

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 covers the only parameter 'period' with an enum of day/week/month and a description, and the tool description also references these windows. Since schema coverage is 100%, the description adds no new parameter semantics, warranting a baseline 3.

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 a leaderboard of top products launched within day/week/month windows, ranked by community votes. It is specific and unambiguous, effectively distinguishing it from sibling tools like search or calendar, though it does not explicitly contrast them.

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 recommends it for 'what launched recently' and 'trending tools' questions, giving clear context. It does not mention when to avoid it or name alternatives, so it falls short of a 5.

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 discloses what the tool returns (every category, product counts, curated intros) and implies a safe read-only operation. There are no hidden side effects or surprising behaviors to flag.

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-loaded with the core purpose and followed by a clear use-case directive. Every word earns its place, with no redundancy or extraneous 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, zero-parameter listing tool, the description fully covers what it returns and when to use it. The absence of an output schema is compensated by explicitly mentioning the included data (product counts and curated intros).

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 zero parameters, and the schema has no properties. The description adds no parameter-specific meaning, but none is required. Baseline for 0 params is 4.

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 lists every category in the toolfound directory, including product counts and curated intros. This specific verb+resource+scope distinguishes it from sibling tools like search_tools or get_trending.

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 usage context: use it to browse the index or map a user's need to the right category before searching. It implies the alternative of searching afterward but does not explicitly exclude other uses or name alternative tools.

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 of behavioral disclosure. It describes the returned data (taglines, pricing model, vote counts, canonical URLs) and notes the URLs can be cited or opened, which adds useful context. It does not mention pagination or error behavior, but for a read-only search tool this is 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 two sentences, front-loaded with the core purpose, followed by return value details and usage guidance. Every sentence earns its place, with no wasted words or repetition.

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 single-parameter search tool with no output schema, the description is complete enough: it states what is searched, what is returned, and when to use it. It could mention pagination or sorting, but the core use case is covered. Sibling differentiation is also addressed through the search 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?

The input schema already provides a detailed description for the 'query' parameter (100% coverage), including examples. The tool description adds 'by name, tagline, or tag,' which aligns with the schema's 'product name, problem, or tag' but does not introduce new meaning or constraints. 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 searches toolfound.com for SaaS products and developer tools by name, tagline, or tag, which is a specific verb, resource, and scope. It distinguishes itself from siblings like get_product or get_trending by emphasizing the search/discovery use case.

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 'Use this when a user asks to find, compare, or discover a tool for a job,' providing clear when-to-use guidance. It does not explicitly name alternative tools for exclusion, but the usage context is strong enough to differentiate from siblings.

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 it delivers: it discloses mandatory ownership verification, the three verification methods, returned fields (submission ID, queue position, launch date, free-slots counter), idempotency for known URLs, and content behavior around description word count and search indexing. This is unusually rich behavioral disclosure for a submission 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 dense and information-packed, with important details front-loaded and a clear AGENTS: section for practical guidance. It earns most of its length, but the marketing phrase 'the launch platform where the whole launch runs agent-native, end to end' adds no operational value, and the paragraph could be slightly tighter.

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 no output schema, the description explains what the response contains and how to proceed with verification, which is critical for this complex tool. It covers idempotency, calendar usage, verification methods, and return values. Given the tool's 9 parameters and mandatory verification flow, this description is sufficiently complete for an agent to call 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 description coverage is 100%, so the baseline is 3. The tool description adds extra useful semantics beyond the schema: description length recommendations (100–200 words, 100+ words qualifying for indexing) and idempotent behavior tied to the URL parameter. This raises it above baseline, though most parameter meaning still comes from 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 identifies the tool's action ('Submit a product to launch'), the target resource (toolfound.com), and the overall outcome: creating a submission that returns an ID, verification instructions, queue position, and launch date. It also distinguishes itself from sibling tools by presenting this as the entry point for the launch flow, with idempotent resubmission behavior.

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 strong contextual guidance: agents are told they don't need inbox access, that verify_token works with meta_tag/dns_txt via toolfound_verify_submission, that toolfound_check_verification dry-runs checks, and that the calendar tool should be used for preferred dates. It does not explicitly state when not to use this tool or name alternatives like claim_listing, but the workflow context is 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?

No annotations provided, so description carries full burden. It discloses that verification checks on-demand token methods and that success queues the launch at a transparent position. It doesn't mention failure behavior or idempotency, but provides sufficient context for a verification action.

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, front-loaded with the core action, and includes both the 'why' (trustworthiness) and the outcome. 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?

For a one-parameter tool with no output schema, the description explains the required input, the verification methods, and the success effect. It doesn't describe failure messages, but the overall purpose and usage are clear.

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 token parameter with 100% coverage. The description adds context about the token's origin (email magic link, meta tag, DNS TXT record) and that it's checked on demand, enriching the schema's brief 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 verifies ownership of a toolfound submission using a token, and explains the successful outcome (queuing the launch). This distinguishes it from sibling tools like check_verification and submit_product, which have different roles.

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 explains the token can come from the email magic link or from meta tag/DNS TXT record, and that this call checks them on demand. It also states that verification is mandatory for launched products, implying this should be used before launch. However, it doesn't explicitly name alternatives like check_verification.

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