There's An AI For That

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered by structured data. The description adds only the scoping qualifier "public," which is useful context but minor; nothing about lookup failure, visibility limits, or rate behavior is disclosed.

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 front-loaded sentence with no filler; the operation and its scoping constraint are stated immediately.

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?

An output schema exists, so return values need not be described, and the lone parameter is fully covered by the schema and annotations. For a simple single-record lookup this is essentially complete, with only the source-of-ID linkage and not-found behavior left implicit.

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% and the single id parameter is well documented as "the numeric ID returned by search_breakthroughs." The description adds no meaning beyond what the schema already provides, so the 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?

States a specific verb (get) and resource (one public AI breakthrough) scoped by ID. It is clearly distinguishable from the entity-getting siblings by resource type, though it does not explicitly name its search counterpart search_breakthroughs as the source of the ID.

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?

"by ID" implies the tool is for retrieving a single known record, and the schema pins the ID to "returned by search_breakthroughs." However, there is no explicit when-to-use statement, no exclusions, and no mention of what to do if the ID is unknown — usage is inferred rather than 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?

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds non-obvious behavior beyond that: results are paginated per collection, and returned URLs must be preserved exactly (an output-handling constraint not carried by any structured field). It does not state auth or rate-limit behavior, keeping it short of a 5.

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, zero filler: the content and scoping come first, followed by the one imperative that is easy to overlook (URL preservation). Nothing restates the title or the annotations.

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?

An output schema exists, so return values need not be described, and the description covers the slug source and paging model. It stops short of naming the search_companies prerequisite explicitly in prose or warning about the section/offset interaction, which would make it fully 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%, so the schema already explains slug, limit, offset, and the section enum. The description adds only the paging framing ('paginated company-page collections'), not format or enum semantics. 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?

Specific verb+resource with the exact payload enumerated (profile, valuation, total raised, paginated collections), and it is keyed by slug. An agent can distinguish it from get_organization/get_investor at a glance because the description names the company-profile content rather than generic 'details'.

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 is implied: the tool needs a slug 'returned by search_companies', which points at the right workflow entry point, and section/limit/offset signal paging. However there is no explicit when-to-use or when-not-to-use statement, and no mention of how it differs from the sibling get_organization or the search_companies alternative.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by characterizing the data as 'public' and instructing the agent to 'Preserve returned URLs exactly' — output-handling guidance not present in 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?

Two short sentences, zero filler, with the resource and its provenance front-loaded before the output-handling caveat.

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?

An output schema exists so return values need not be described, and the single parameter is fully documented in the schema. The only remaining gap is failure behavior for invalid or unknown slugs, which is minor for a read-only lookup.

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 schema already defines 'slug' as the lowercase country code from search_countries. The description only reinforces the provenance of the value and adds no format or edge-case detail beyond the schema, so the 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?

States a specific verb and resource ('Get the public TAAFT country identity for a country code'), and the qualifier 'returned by search_countries' distinguishes it from the search_countries sibling. The phrasing 'TAAFT country identity' is slightly jargon-y but the operation 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?

Explicitly ties the input to a prior step: the code must come from search_countries, which gives the agent clear context for when this tool is applicable. It stops short of stating when not to use it or what happens for an unknown/unsupported code.

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/openWorldHint/destructiveHint, so safety is covered. The description adds genuinely new behavioral context: it only returns 'approved TAAFT partner' deals and instructs the agent to 'Preserve returned URLs exactly', a real handling constraint not present in the structured data.

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 tight sentences with zero filler; the scope constraint and key are front-loaded, and the handling instruction follows.

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 an output schema present, return values need not be explained, and the description covers the key, scope, and an output-handling caveat. Minor gap is the absent explicit routing to search_deals, but the picture is otherwise 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?

Schema coverage is 100% and the single parameter is fully described in the schema. The description restates 'by tool slug' but adds no syntax or format detail beyond what the schema already provides, so the 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?

States a specific verb ('Get'), a precisely-scoped resource ('one approved TAAFT partner deal'), and the lookup key ('by tool slug'). The word 'one' and 'approved' differentiate it from the bulk search_deals sibling.

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 is only implied via 'by tool slug' – the schema (not the description) notes the slug comes from search_deals. There is no explicit when-to-use statement or named alternative in the description itself.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar for added context is lower. The description adds two useful notes ('public details' scope and 'preserve returned URLs exactly'), but omits rate limits, error behavior for bad slugs, and whether any fields are auth-gated.

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 short sentences, front-loaded with the core action, and no filler. The trailing instruction about preserving URLs is terse but contributes actionable information.

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?

Output schema exists so return-value explanation is unnecessary, and annotations carry the safety semantics. For a one-parameter read tool, the description is nearly complete; only sibling routing (search_devices) and failure behavior for an invalid slug 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?

Schema description coverage is 100%, so the single slug parameter is already fully documented in the schema including its origin ('returned by search_devices'). The description adds no format, example, or normalization detail beyond 'by slug', so 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?

States a specific verb (get) and resource (public details and specifications for one AI device), with the 'by slug' qualifier distinguishing it from the sibling search_devices listing tool. An agent can tell immediately this is the single-item lookup counterpart to device search.

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 is only implied: fetching a device by a slug the agent already holds. It never names search_devices, gives no when-not-to-use case, and gives no guidance for an unknown/invalid slug. The retrieval-then-fetch workflow is inferable but not stated in the 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 cover the safety profile (readOnly, non-destructive, closed-world). The description adds two things annotations cannot: results are limited to 'public' events, and returned URLs must be preserved exactly (implying they are fragile/possibly signed). That is meaningful behavioral context beyond the structured fields.

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 short sentences, zero filler, with the core action front-loaded and the URL-handling caveat placed as a trailing imperative. Every sentence earns its place.

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 an output schema present, return values need not be explained, and the description correctly covers scope ('public') and the URL-preservation caveat. What is missing is any routing signal relative to search_events, which is the main gap for a low-complexity lookup tool.

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 one parameter and schema description coverage is 100%, so the schema already documents 'slug' and its provenance. The description's 'by slug' adds no syntax, format, or constraint detail beyond the schema; 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?

States a specific verb ('Get') and resource ('public details for one AI event'), scoped by slug. It is clearly the event variant of the get_* family, though it does not explicitly name or contrast with search_events as an alternative.

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 is implied rather than stated: 'by slug' plus the schema note that the slug comes from search_events tells the agent this is a lookup that follows a search. There is no explicit when-to-use/when-not guidance or statement that this is the only way to fetch a single event.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value beyond them: it scopes the response to 'public details' and gives an output-handling instruction, 'Preserve returned URLs exactly,' which the annotations do not convey.

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 short sentences, front-loaded with the core purpose, and no filler. The trailing URL-preservation instruction is a distinct, actionable rule that earns its place.

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 single-parameter read tool with an output schema, so return values need not be explained, and annotations cover the safety profile. The description covers what is fetched and one output caveat; only explicit routing to search_fundraises for the ID is 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?

Schema description coverage is 100% and the single 'id' parameter is fully documented by the schema as the numeric fundraise ID from search_fundraises. The description adds only 'by ID', which restates rather than extends the schema, so 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 names a specific verb (Get) and resource (one AI company fundraising round by ID) and clarifies what content is returned: public details plus participating investors. It does not explicitly contrast itself with search_fundraises or other get_* siblings, relying on the resource noun alone to differentiate.

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 is only implied by the phrase 'by ID', which suggests an ID must first be obtained elsewhere; the schema description supplies the search_fundraises link, not the description. There is no explicit when-to-use or when-not-to-use guidance in the description itself.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds real context beyond them: results are limited to 'public details' for 'verified active' investors, and the instruction to 'Preserve returned URLs exactly' signals URLs are fragile/high-value. It does not describe error behavior or result shape, but the output schema covers returns.

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, zero filler. The core purpose is front-loaded and the URL-preservation caveat is placed second, where it is easy to catch before calling.

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 read tool with an output schema and full annotation coverage, the description supplies scope, key, and a caveat, so an agent has what it needs to invoke it. The only minor gap is that it does not state the failure mode for slugs that are not verified/active.

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 one parameter at 100% schema description coverage, the schema already defines slug and its provenance. The description only restates the key ('by slug'), adding no format or validation detail beyond the schema, so the 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 gives a specific verb (get), resource (investor details and funding activity), scope (one verified active AI investor), and key (by slug). It is immediately distinguishable from search_investors and the other get_* siblings by naming the entity and the single-item lookup mode.

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?

'By slug' plus the schema's note that the slug comes from search_investors implies the search-then-fetch workflow, and 'verified active' hints at a coverage limit. However, the description never explicitly states when to use this versus search_investors or what happens for an unverified/inactive slug, so guidance is implied rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond them: it specifies the data is 'public' (no auth implied) and warns to 'Preserve returned URLs exactly,' which is genuine behavioral guidance about handling the output.

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 tight sentences with zero filler, and the core action is front-loaded before the output-handling caveat.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the action, the input's origin, and an output caveat; only explicit usage routing is thin.

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 single parameter has 100% schema description coverage, and the description adds only that the slug originates from search_mcps. Baseline 3 applies since the schema already documents the parameter fully.

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 a specific verb (Get) and resource (public details for one MCP server), scoped by slug. The mention that the slug comes from search_mcps mildly differentiates it from its large family of get_* siblings, but it does not explicitly contrast the lookup-vs-search split.

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 is implied rather than stated: the slug is 'returned by search_mcps,' which suggests a search-then-fetch flow, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two real behavioral facts beyond that: only public details are returned (scope limitation) and returned URLs must be preserved exactly (fidelity constraint for downstream use).

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 short sentences, no filler. The core operation leads and the URL-preservation caveat follows; both carry information an agent needs.

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?

An output schema exists so return values need not be explained, and the annotations cover safety. The description supplies the scope caveat ('public details') and the URL handling instruction, leaving little an agent needs missing; only an explicit sibling routing statement is absent.

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?

Single parameter with 100% schema description coverage, so the schema fully documents 'slug' as the value returned by search_models. The description adds no format, casing, or sourcing detail beyond the schema, so 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?

States a specific verb and resource ('Get public details for one AI model') plus the keying mechanism ('by slug'), which cleanly separates it from the search_* siblings. It does not explicitly name an alternative like search_models, so it falls just short of the top band.

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 'by slug' phrasing implies the prerequisite (you must have a slug, which the schema says comes from search_models), but the description itself never states when to use this versus search_models or get_company-style siblings. Usage is inferable rather than stated, which is the definition of minimum viable.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the scope note that items are 'public'; it says nothing about behavior when an ID does not exist or is malformed.

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 nine-word sentence that front-loads verb, resource, and lookup key with zero filler. Nothing could be removed without losing meaning.

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 an output schema present, return values need not be described, and the single parameter plus annotations are self-explanatory. The only minor gap is not stating behavior for a nonexistent or invalid ID.

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 sole parameter (id) is fully documented in the schema, including its provenance from search_news. The description's 'by ID' adds nothing beyond that, making the baseline of 3 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?

States a specific verb ('Get'), resource ('one public AI news item'), and cardinality ('one ... by ID'), which cleanly separates it from search_news and the other search_* siblings. It does not name an alternative explicitly, but the singular/plural resource distinction 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?

Usage is only implied: the 'by ID' framing signals this is a follow-up fetch after a search, and the schema's id description reinforces that the ID comes from search_news. There is no explicit when-to-use statement or exclusion of related 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by scoping the data to 'public details' and warning to 'Preserve returned URLs exactly' when consuming the output.

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 tight sentences with no filler; the scope (one organization, by slug) is front-loaded and the URL-preservation caveat follows immediately.

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?

An output schema exists, so return values need not be explained, and the annotations cover safety. The only minor gap is the absence of any note on behavior for an unknown or invalid slug, which would be useful for a lookup tool.

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?

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics. The description only repeats that lookup is 'by slug' and adds nothing about format or validation, so the 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 names a specific verb (Get) and resource (one AI organization by slug) and enumerates the payload (public details, papers, linked paper authors and companies), which distinguishes it from the sibling search_organizations and from get_company.

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 is only implied: identifying the key as a 'slug' for 'one' organization suggests a post-search lookup, and the schema notes the slug comes from search_organizations. There is no explicit statement of when to use this versus the search tool or 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 readOnly, non-destructive, and closed-world behavior, so the burden is light. The description still adds two pieces of non-structured context: only public/published papers are returned, and returned URLs must be preserved exactly (an output-handling caution) – useful beyond what annotations provide.

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 short sentences with zero filler; the core purpose is front-loaded and the URL-preservation caveat is placed second as an operational note. Nothing is wasted.

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, single-entity read tool with complete schema coverage, safety annotations, and an output schema that documents the return shape, the description covers what is needed. The only thin area is when to prefer this over the search tools, but that is minor at this complexity.

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 100% schema description coverage, the schema already explains both 'id' and 'slug' and the oneOf requirement, so the baseline is 3. The description repeats 'by ID or slug' without adding format, precedence, or fallback guidance 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?

States a specific verb and resource ('Get public details for one published AI research paper') with scope qualifiers ('public', 'published', 'one'), which distinguishes it from the search_papers sibling in the adjacent set. It does not explicitly name the sibling tool in the description, so it falls short of a 5.

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 is only implied: the parameter descriptions note the ID and slug come 'returned by search_papers', which suggests the search-then-fetch workflow. There is no explicit when-to-use/when-not statement or naming of alternatives, so this is minimum-viable rather than strong 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description still adds real context beyond them: the scope restriction to *public* details and the non-obvious instruction to preserve returned URLs verbatim. Auth requirements and rate limits are not mentioned, keeping it short of a 5.

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 short sentences, zero filler, with the core purpose and the lookup keys front-loaded before the output caveat. Every clause earns its place.

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 an output schema present the return shape need not be described, and annotations cover safety, so the description's remaining job is scope and lookup semantics — both addressed ('public details', slug or ID). Missing only not-found/empty-result behavior for a lookup-by-key tool.

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 both properties are already documented in the schema (including the oneOf requirement structure). The description restates the two lookup forms but adds no syntax, format, or precedence detail beyond what the schema provides, 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?

States a specific verb and resource ('Get public details for one AI repository') and names both lookup keys (owner/repository slug or numeric ID). It is clear it fetches a single entity, but it never names the sibling search_repositories as the bulk alternative, so differentiation is left implicit.

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 when-to-use, when-not-to-use, or alternative routing is given in the description itself; the only hint that search_repositories is the companion tool lives in the schema property descriptions. The 'Preserve returned URLs exactly' line is an output-handling instruction, not selection 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the details are 'public' and that returned URLs should be preserved exactly, which is useful context beyond annotations, but it does not cover missing-slug behavior or other operational 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?

Two short sentences, with the core action front-loaded and no wasted wording. The second sentence is a compact instruction about preserving returned URLs.

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 and has an output schema, full parameter description coverage, and clear read-only annotations. The description covers purpose and a notable output-handling constraint, so it is nearly complete; only minor edge-case behavior is left unstated.

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%, and the schema already explains that slug is the identifier returned by search_robots. The description only restates 'by slug' and adds no syntax, format, or validation detail beyond the schema. Baseline 3 is appropriate when the schema carries the 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 states a specific verb (Get) and resource (robot details/specifications) with a clear lookup key (slug). It distinguishes a single-record fetch from list/search tools by saying 'one robot by slug', though it does not explicitly name search_robots as the sourcing alternative.

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 is implied: fetch one robot using a slug, and the schema notes the slug comes from search_robots. There is no explicit when/when-not guidance or alternative routing in the description itself. The 'Preserve returned URLs exactly' sentence gives downstream handling guidance but not selection 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond that: results are 'public' only, and returned URLs must be preserved exactly. It still says nothing about error behavior or lookup failure, so it is additive but not rich.

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 short sentences, zero filler, with the core purpose front-loaded and the output-handling caveat second. Every sentence earns its place.

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?

An output schema exists, so return values need not be described, and the annotations cover the read-only safety profile. For a single-parameter lookup tool the description is nearly complete; only the missing usage guidance keeps it from a 5.

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% and there is only one parameter, so the schema fully documents 'slug' as 'the task slug returned by search_tasks.' The description adds no format or validation detail beyond that, which is the expected baseline when the schema does the work.

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 a specific verb and resource ('Get public details for one TAAFT task category by slug'), so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from the many sibling get_* tools (get_tool, get_company, etc.) beyond the 'task category' resource name, but the resource 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 gives no when-to-use or when-not-to-use guidance and names no alternative. The only workflow hint ('slug returned by search_tasks') lives in the schema, not the description, so the agent gets no routing help from the prose.

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 this a safe, non-open-world read, so the bar is lower. The description nonetheless adds real behavioral context: deal details appear only conditionally (approved partner offer), and callers are told to 'Preserve returned URLs exactly' — a non-obvious constraint on how the output must be handled.

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 short sentences, front-loaded with the core action and the conditional deal content, then the URL handling note. Tight and readable; 'TAAFT' is repeated a few times, which is minor padding.

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?

An output schema exists, so return values need not be enumerated, and annotations cover the safety profile. The description is complete enough for a single-parameter lookup, highlighting the two URL fields and the conditional deal block an agent should 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 description coverage is 100% and the single slug parameter is already documented as 'The tool slug returned by search_tools', which the description merely echoes with 'by slug'. Baseline 3 is appropriate since the schema carries the parameter semantics entirely.

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?

Names a specific verb and resource ('Get public details for one TAAFT AI tool by slug') and scopes the payload ('including deal details when an approved TAAFT partner offer exists'). It does not, however, clarify how it relates to the sibling get_deal, which an agent could reasonably consider an alternative for the deal portion.

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 is only implied: the schema notes the slug comes from search_tools, and the description assumes the agent already has a slug. The two sentences about url/website_url concern interpreting returned fields, not when to pick this tool over search_tools or get_deal, and no exclusions or prerequisites are 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety and scope are largely covered. The description adds that results are restricted to 'public' breakthroughs and explains empty-query behavior, but says nothing about pagination, result caps, or ordering beyond what the schema shows.

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 tight sentences with the scope and filter axes front-loaded and the empty-query rule trailing. No filler, no repetition of the title or schema.

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?

An output schema exists, so return values need not be described, and the annotations carry the read-only profile. The description adequately covers the primary filtering intent for an 8-parameter search tool, with only the ordering/limit controls left to the schema.

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 63%, so a baseline of 3 is appropriate. The description usefully maps filter concepts to parameter groups (keyword, time frame, topic, source, importance), but leaves 'sort' and 'limit' unaddressed and adds no syntax detail beyond the schema's own YYYY-MM-DD / 24h / 7d examples.

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 (search) plus resource (public AI breakthroughs) and enumerates the filter axes, so the core purpose is unambiguous. It stops short of differentiating itself from adjacent siblings such as search_papers or search_news, which an agent could reasonably confuse for AI-related content.

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 is only implied by the filter list; the single explicit rule is that an omitted or empty query lists all matching items. There is no guidance on when to reach for this tool over a sibling search, and no stated prerequisites or exclusions.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral fact — exact company-name matches rank first — which is not derivable from the schema. It says nothing about pagination behavior or result size beyond what the schema implies.

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 tight sentences with no filler; the ranking behavior is front-loaded alongside the primary capability. Efficient, though its brevity is partly the cause of the coverage gaps.

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 an output schema present the description needn't explain returns, but for a 16-parameter, 19%-documented tool it is far too thin: no usage routing, no pagination/sort semantics, and most filters unexplained. An agent would likely miss or misuse the numeric-range and boolean filters.

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 19% across 16 parameters, so the description carries most of the burden, yet it names only four filterable dimensions (name, description, industry, products). Key params like sort, limit/offset, country, ai_native, profitable, and the valuation/headcount/total_raised ranges go undocumented anywhere.

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 a specific verb ('search and filter') and resource ('public TAAFT companies'), and enumerates the primary searchable fields. It does not differentiate itself from the many sibling search_*/get_* tools, nor from search_organizations, which an agent might reasonably confuse it with.

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 statement of when to use this versus get_company (for a known company) or search_organizations. No exclusions, prerequisites, or routing guidance at all — the agent must infer that this is the discovery path for companies.

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, destructiveHint=false, and notably openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of result shape, pagination, or what 'activity' data is returned. Nothing contradicts the annotations, but the description contributes no behavioral context of its own.

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 short sentence that is front-loaded with the verb, so there is no waste or padding. It loses a point only because the brevity comes at the cost of the clarity noted elsewhere.

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?

An output schema exists, so return values need not be explained. However, for a search tool with an undocumented limit parameter, no usage routing among 27 siblings, and a vague scope ('AI companies and activity'), the definition leaves an agent without enough to invoke it confidently.

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 only 50%: 'query' is documented in the schema, but 'limit' (default 20, max 50) has no description anywhere. The description mentions no parameters at all, so it does not compensate for the coverage gap or explain how country-name matching works (partial, exact, aliases).

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 a verb and resource ('search TAAFT country pages for AI companies and activity'), but the object is muddled — it is unclear whether this returns companies, aggregate activity stats, or country pages themselves. It does not distinguish itself from sibling search_companies or get_country.

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 when-to-use guidance, no exclusions, and no routing to alternatives. With 27 siblings including search_companies and get_country, the agent has no signal on why it would pick this tool over those.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine provenance context — results are drawn from the same approved offers as the public deals page — which tells the agent the data set is curated rather than arbitrary. It stops short of disclosing pagination, default ordering, or result-size 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?

Two sentences, front-loaded with the core action and resource, followed by return-content context. No filler or repetition; every clause carries information about what the tool does or what it returns.

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?

An output schema exists, so the description is not obligated to enumerate return fields, making the field list somewhat redundant. Against that, an 8-parameter filter tool with 50% schema coverage and no description-level guidance on filters, defaults, or result capping leaves the agent under-equipped to construct correct queries.

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% across 8 parameters, and the description contributes no parameter-level meaning at all — it never mentions query, sort, task, feature, pricing_model, or the discount thresholds. Fields like sort, pricing_model, and the two min_discount parameters are documented only by their names and enums, leaving a real gap for a filtering-heavy tool.

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 ('List or search') and resource ('TAAFT partner deals'), making the operation unambiguous. It hints at the sibling relationship with get_deal via 'List or search' versus a single-deal lookup, but never names it explicitly, so differentiation is inferred rather than stated.

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 dual framing 'List or search' implies two usage modes (browse everything vs. keyword search), and the note that results mirror the public deals page gives some context. However, there is no explicit guidance on when to use this over get_deal, nor on how filters should be combined or when to omit parameters.

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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds only that filtering and sorting are supported; it does not disclose the anyOf requirement, the max page size of 50, or any result-volume behavior. No contradiction 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?

Two tight sentences, capability first, supporting detail second, with no filler. It is well front-loaded, though the second sentence is thin enough that it could have carried the missing constraint instead of just restating filter support.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. However, the schema's anyOf (at least one of query/device_type/form_factor/availability/use_case/price/country/date/task required) is nowhere in the description, leaving a real risk of a parameter-less call error given zero required fields.

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 85%, so nearly every parameter is self-documenting with enums, ranges, and formats; baseline 3 applies. The description's list of searchable facets loosely maps to the properties but adds no syntax, matching rules, or combination semantics beyond what the schema states.

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?

Clear verb+resource ('Search and compare AI devices') with an enumeration of searchable facets (name, description, specifications, type, use case, maker, linked task). It does not differentiate this from the sibling get_device (fetch a single device), so an agent gets the intent but not the search-vs-fetch distinction.

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 when-to-use, when-not-to-use, or alternative routing is given; get_device exists as an obvious sibling but is never mentioned. 'Supports hardware filters and sorting' hints at how to narrow results but states no preconditions, and it omits the critical rule that at least one filter/query field must be supplied.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the catalog scope ('TAAFT catalog') and query target ('by name'), but gives no behavioral details such as pagination, rate limits, or result ordering.

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 efficient sentence with the key scope and purpose front-loaded. Every word earns its place and there is 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?

For a simple search tool with an output schema, the description is minimally adequate: it names the catalog and the search key. However, it omits usage guidance against siblings and does not cover the undocumented limit parameter, leaving some practical context 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?

Schema description coverage is 50%, with the required query parameter described in the schema and limit left undocumented. The description adds little beyond the schema for query and says nothing about limit semantics, so it does not compensate for the coverage gap.

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 and resource: search the TAAFT catalog for AI events. It is clear enough to distinguish this from get_event by the use of 'search' and 'by name', though it does not explicitly name sibling tools or contrast with get_event.

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?

There is no guidance on when to use this tool versus get_event or other search_* siblings. The only implied usage is looking up events by name, which is not sufficient for an agent choosing among many similar 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope context ('public AI company' rounds) but says nothing about result volume, default page size behavior, or pagination, so it adds only modest value beyond the structured fields.

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 compact clauses, front-loaded with the verb and resource, followed by the filtering and sorting capabilities. No filler sentences, though the sorting note is mildly redundant with the schema's sort/order parameters.

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?

An output schema exists so return values need not be described, and annotations carry the safety profile. With 88% schema coverage across 8 optional parameters, the description's coverage of scope and filters is adequate; only the lack of sibling routing guidance keeps it from being fully 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?

Schema description coverage is 88%, so the schema already documents every parameter including the wildcard/empty-string behavior for query and the enum values. The description restates the filterable dimensions (company name, round type, date, investor slug) without adding format, matching, or precedence semantics beyond what the schema 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?

States a specific verb (search/list) and resource (public AI company fundraising rounds), which cleanly separates it from the singular get_fundraise and from search_deals. It enumerates filterable dimensions, but never names the sibling tools it competes with, so differentiation relies on the agent knowing the sibling set.

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 by listing available filters, but gives no explicit when-to-use versus get_fundraise or search_deals, and no exclusions. The only cross-tool hint ('investor slug returned by search_investors') lives in the schema, not the description, so the routing guidance is implicit rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that only verified, active investors are returned, which is useful filtering context, but it does not disclose pagination behavior or anything beyond what annotations and the output schema already imply.

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 tight sentences with the purpose front-loaded and no filler. The second sentence listing returned fields is partially redundant given an output schema exists, which keeps it short of a 5.

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 an output schema present, the description need not explain return values, and the scope statement is adequate. It is still missing the search-vs-get routing that matters in a catalog with 30+ sibling tools, leaving the agent to guess which entry point to use.

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 67% (sort and query are documented in-schema, limit is not), which is above the 50% threshold where the baseline of 3 applies. The description adds no parameter-level detail such as query matching semantics or sort tie-breaking beyond what the schema already states.

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 gives a specific verb (search or browse) plus a well-scoped resource (verified active investors in AI companies), and the 'verified active' qualifier tells the agent what subset is returned. It does not, however, distinguish itself from the sibling get_investor, which an agent must infer from naming convention alone.

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?

'Search or browse' hints at the two modes but the schema already documents that query is optional. There is no explicit guidance on when to use this over get_investor or any of the other search_* siblings, and no stated preconditions or exclusions.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that query is optional and the tool is a directory browser, consistent with the closed-world annotation but without detail on result shape, pagination, or recommendation ranking 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?

Two short sentences, front-loaded with purpose and closing with the query-optional constraint. Every clause carries information; nothing is padding.

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 8 all-optional params, an output schema, and 88% schema coverage, the description only needs to explain the search-vs-browse split, which it does. It could mention that filters combine conjunctively or that limit caps at 50, but those gaps are minor given the structured fields.

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 88%, so nearly every parameter is already documented in the schema (including the default-relevance/popularity behavior of sort). The description restates the optional-query semantics without adding format, slug syntax, or filter-combination guidance 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?

States a specific verb pair (search/recommend) and resource (MCP servers), then enumerates the searchable dimensions (name, capabilities, company, task, category), which clearly separates it from get_mcp and search_tools. It never names a sibling explicitly, so differentiation is inferred from the field list rather than stated.

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 query is optional; use filters or sort to browse the directory" gives clear context for two distinct modes: relevance search vs. faceted browsing. There is no explicit when-not or pointer to get_mcp for single-server lookup, which would have made it 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the search is scoped to the TAAFT catalog and by model name, but does not disclose result limits 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 front-loaded sentence with no wasted words. It efficiently communicates the core action and scope.

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 search tool with an output schema, the description covers the basic search scope. However, it omits guidance on when to prefer this over get_model and does not explain the limit parameter, leaving some gaps for an agent.

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 50%: the query parameter is documented in the schema, but the limit parameter has no description. The description only repeats that search is by model name and adds no meaning beyond the schema for either 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 states a specific verb (search) and resource (AI models) within the TAAFT catalog and even names the search key (model name). It is clearly distinct from sibling search tools by resource type, though it does not explicitly contrast with get_model.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as get_model. The intended use is only implied by 'search by model name.'

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are public AI news and clarifies the empty-query behavior, but says nothing about pagination, result caps, or ordering beyond what the schema fields imply.

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 tight sentences, front-loaded with the action and resource followed by the empty-query edge case. No filler, though the second sentence is slightly terse in phrasing.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. The description adequately covers the main filter axes and the zero-required-params behavior, leaving only minor gaps like sort/limit defaults that the schema already supplies.

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 63% and the schema already documents most filters well. The description summarizes keyword, time frame, topic, source, and importance — recapping schema content rather than adding syntax or format detail — and omits sort and limit entirely. 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?

States a specific verb (Search) and resource (public AI news) and enumerates the filter dimensions it supports, so the agent knows the scope precisely. It does not explicitly distinguish itself from the many sibling search_* tools, though the resource name 'news' makes the target clear.

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 by listing filter dimensions and notes that an omitted or empty query lists matching items, which is genuinely useful guidance. It gives no when-not guidance and never names an alternative (e.g., get_news for a specific item), leaving usage largely 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context about ranking (exact names, short names, derived acronyms rank first), but says nothing about pagination or result limits for a search 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?

Two tight sentences with zero waste; the purpose and ranking behavior are front-loaded ahead of the filter/sort 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?

An output schema exists, so return values need not be described, and the description covers the filter and sort surface. The main gap is the lack of sibling disambiguation, which matters given many adjacent search_* tools.

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 67% and the description names several parameters (type, country, industry, sort) plus sort values. It adds little beyond the schema and omits the query and limit parameters, so 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?

States a specific verb and resource ('Search and browse AI organizations') with a clear scope. It does not, however, differentiate itself from siblings like search_companies or get_organization, which an agent must disambiguate on its own.

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 by naming the available filters and sort options, but never states when to choose this over search_companies or get_organization, nor any exclusions or prerequisites.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral constraint ('Preserve returned URLs exactly'), but says nothing about pagination, result ordering behavior, or rate limits beyond what annotations provide.

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 compact sentences with the core purpose front-loaded and no filler. The trailing URL-preservation instruction is short and earns its place as a behavioral note, though it could be slightly better integrated.

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 ten optional filters and 90% schema coverage plus an output schema, the description needn't explain returns, but it should at least hint at the rich date/venue/author filtering available. It undersells the tool by implying only title and organization filtering, leaving the agent's mental model 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 90%, so the schema itself documents nearly all ten parameters, making a baseline 3 appropriate. The description only names title and organization filtering, adding no meaning beyond the schema for sort, since/until, venue, author, company, or limit.

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 a specific verb (search) and resource (published AI research papers in the TAAFT catalog), which clearly distinguishes it from the singular sibling get_paper. However, 'by title' understates the tool, which actually filters on venue, author, company, dates, and featured status.

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 notes that an organization slug may optionally be supplied, giving a hint of usage context, but never states when to choose this search tool over get_paper for a known paper or over sibling searches. No exclusions or alternatives are offered.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds genuine behavioral information beyond that: default ranking prefers relevant, popular, and official repositories unless a sort is explicitly selected. It still omits result-set shape and pagination, but that is largely covered by the output schema.

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, zero filler, with the searchable scope front-loaded and the ranking caveat second. Every clause carries meaning.

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 an output schema present, return values need no explanation, and the description covers what is searchable and how results are ordered. The main omission is guidance on whether query is required and how this differs from get_repository, but for a 9-parameter read-only search tool this is close to 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?

Schema description coverage is 78%, so the schema already documents most parameters (owner, company, query, license, language, min_stars, updated_after). The description's field list loosely maps to the query parameter's semantics but adds no syntax, format, or matching-behavior detail 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?

States a specific verb (Search) plus resource (AI repositories) and enumerates exactly which fields are searched (name, description, README, topics, owner, linked TAAFT company). This clearly separates it from the get_repository sibling and from other 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?

Usage is implied by the search_* naming family, but the description never says when to use this versus get_repository for detail, nor whether a query is required to get results (query is optional in the schema). It does note that sort changes the ranking behavior, which is a partial hint.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that hardware filters and sorting are supported; it does not disclose result paging, default/max limits, or the anyOf constraint requiring at least one filter, which is a genuinely useful behavioral detail it omits.

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, zero filler, with the core capability front-loaded before the secondary note about filters and sorting. Every clause carries information.

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?

An output schema exists and annotations cover the safety profile, so return values and read-only semantics need not be restated. The description is nearly complete for a filtered search tool, missing only the mandatory-criterion rule and pagination behavior, both of which an agent would benefit from knowing up front.

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 85%, so the schema already documents nearly every parameter with enums, defaults, and formats. The description's facet list loosely maps to those parameters (type, use case, maker/query, task) but adds no syntax, matching semantics, or range behavior beyond what the schema states; 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 names a specific verb (search and compare) and resource (robots) and enumerates the searchable facets: name, description, specifications, type, use case, maker, and linked task. It is clearly distinct from get_robot, but it never names or contrasts with the search_* sibling family, so sibling differentiation is left to the name alone.

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?

"Search and compare robots" implies retrieval usage but gives no when-to-use conditions, no indication of when to prefer get_robot for a single lookup, and no note that at least one filter criterion is mandatory. Usage is inferable from the tool name rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that — no note on result ordering, pagination, or scope limits to complement 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?

A single compact sentence with the resource front-loaded and no filler. It is efficient, though that efficiency comes partly from omitting needed 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?

An output schema exists, so explaining return values is unnecessary, and this is a simple two-parameter read tool. Still, it omits guidance on the limit parameter and on when to prefer it over the singular get_task sibling, leaving a modest 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 only 50%: 'query' is documented in the schema but 'limit' (default 20, max 50) is not, and the description mentions no parameters at all. It neither adds syntax/format guidance nor compensates for the undocumented limit 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?

States a specific verb (search) and resource (TAAFT task categories) plus the domain of what is searched (capabilities/jobs users want AI tools to perform). It distinguishes itself implicitly from the singular sibling get_task, but never names a sibling explicitly.

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 when-to-use guidance is given. The agent is not told when to search tasks versus calling get_task for a known ID, nor how this relates to search_tools in the sibling list. Usage is only implied by the verb 'search'.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: results may include deal details when an approved partner offer exists, one field is the internal TAAFT URL and another is the external site URL, and URLs must be preserved exactly. It does not discuss pagination or result ordering 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?

Four short sentences with no filler, and the core purpose is front-loaded before the URL-handling instructions. Efficient, though the URL sentences are slightly operational detail that could be tightened.

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?

An output schema exists, so return values need not be spelled out, and annotations cover safety. Still, with only one of four parameters documented and no guidance on how sort/type/limit shape the search, the definition is adequate but leaves noticeable gaps for an agent choosing filters.

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% — only 'query' carries a schema description — and the description never mentions sort, type, or limit. The enum values are self-explanatory for sort/type and limit has a default and bounds, but the description does no work to explain what those options mean or how they affect results.

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 a specific verb and resource ('Search the TAAFT directory for AI tools that match a query'), which clearly separates it from sibling searches like search_companies or search_papers by domain. It does not explicitly name an alternative, but the resource is unambiguous enough for selection.

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 is implied by the query phrasing, and there is useful operational guidance about which URL field to use for TAAFT pages versus external sites. However, there is no explicit when-to-use/when-not guidance and no mention of siblings such as get_tool for retrieving a single known tool.

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