Cure Cancer With AI

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

No annotations provided, so description carries the burden. It clearly states this is a read operation that returns the full article content. However, it does not mention whether the slug is unique, any error conditions, or rate limits.

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?

Single sentence that is front-loaded with the action and resource. No unnecessary words.

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

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

For a simple fetch tool with one parameter and no output schema, the description explains the output includes full content. Could mention that the slug is required and unique, but overall adequate.

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

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

The only parameter (slug) is described with an example in the schema. The main description also references 'by slug', reinforcing its role. Schema coverage is 100%, so the description adds extra context with the example.

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

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

The description uses a specific verb ('Fetch') and resource ('single blog post') with the identifier mechanism ('by slug') and what's included ('full article content'). It clearly distinguishes from sibling tools like list_blog_posts.

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 explicit guidance on when to use this tool versus alternatives. While the name and description imply it's for fetching a single post by slug, there is no mention of when not to use it or comparison with list_blog_posts.

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

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

No annotations provided; description says 'Fetch' (read operation) and specifies output contents. Does not mention authorization, rate limits, or side effects, but is adequate for a simple fetch.

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?

Single sentence with clear verb and front-loaded information. No wasted words.

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

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

No output schema, but description specifies what is included (eligibility criteria and locations). For a simple fetch with one parameter, this is 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 coverage is 100% with parameter description including example. Description adds no new parameter information beyond 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?

Clearly states it fetches a single clinical trial by NCT id or internal id, and lists included content (eligibility criteria and locations). Distinguishes from sibling 'get_' and 'list_' 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?

Implied usage: use when you need one trial by ID. No explicit guidance on when not to use or alternatives like list_clinical_trials or search 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?

No annotations are provided, so the description must convey behavior beyond purpose. It does not disclose that it is a read-only operation, lacks side effects, or specify behavior if the id is not found. Minimal transparency.

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 sentence that is concise and direct, containing no unnecessary words or 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?

No output schema is provided, and the description does not indicate what fields or structure the returned paper will have. For a fetch tool, this leaves the agent without expectations about the response.

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 schema description for the single parameter is clear. The description repeats that the parameter accepts internal id or PubMed id, adding no new meaning beyond the schema.

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

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

The description clearly states the action 'Fetch', the resource 'a single research paper', and the method 'by its internal id or PubMed id'. It effectively distinguishes from sibling tools like get_blog_post and list_research.

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 when an id is available but does not explicitly state when to use this tool versus alternatives, such as list_research for multiple papers. No guidance on choosing between id types or handling missing results.

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

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

No annotations provided, so description must cover behavioral traits. It mentions 'excerpts' implying partial content, but no details on side effects, auth, rate limits, or if read-only.

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 with no wasted words. Purpose is front-loaded, and key filtering options and sibling guidance are included efficiently.

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 listing tool with 5 optional parameters and no required fields, the description covers output nature (excerpts) and filters. Lacks sorting details but adequate for the 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?

Schema description coverage is 100%, so description adds no new meaning beyond schema. The mention of filtering aligns with schema but doesn't provide additional syntax or format details.

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?

Clearly states action ('List') and resource ('editorial blog articles (excerpts)'). Distinguishes from sibling 'get_blog_post' by noting it provides excerpts, not full 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?

Explicitly directs to 'get_blog_post for full content' and lists filtering options. Lacks broader context on when not to use, but sufficient given sibling tools are mostly clinical.

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

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

With no annotations, the description bears full burden for behavioral disclosure. It only mentions 'public registries' but omits critical details like pagination behavior, rate limits, required permissions, or result format. The agent is left uninformed about side effects or limitations.

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 very short (one sentence) but omits important details, making it under-specified rather than concise. The inclusion of a possibly inaccurate parenthetical reduces clarity. It could be more efficient with better structure.

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

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

Given 5 optional parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the return format, pagination (though limit/offset exist in schema), or how filtering interactions work. The agent lacks essential context for correct invocation.

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

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

Schema coverage is 100% with each parameter having a description. The description adds some context by naming filters but also mentions an unsupported 'intervention type' filter, which could mislead. Overall, the description adds minimal value beyond what the schema already provides.

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

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

The description clearly states the tool lists clinical trials from public registries and mentions filtering by condition, status, or keyword. This distinguishes it from siblings like get_clinical_trial. However, it also mentions 'intervention type' which is not a parameter in the schema, causing slight confusion.

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 guidance on when to use this tool versus alternatives like get_clinical_trial or list_blog_posts. The description does not provide any when-to-use or when-not-to-use context, leaving the agent to infer purpose from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses the content (scored on -4 to +4 scale) and purpose, but does not mention whether it requires authentication, rate limits, or the exact return format. Adequate for a read-only list tool.

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

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

The description is a single, focused sentence that communicates the tool's purpose and key details without any wasted words. It is perfectly concise and front-loaded.

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

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

Given the tool has no parameters, no output schema, and is simple, the description covers the essential: what it returns and its use case. It could mention it is a reference tool, but for a list operation, it is mostly complete.

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

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

The tool has zero parameters, so the description correctly focuses on the output. It adds meaning by explaining the scoring scale and relationship to search_compounds, which is beyond what the empty schema provides. Baseline 4 is appropriate.

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

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

The description clearly states it lists compound characteristics that serve as preference keys in search_compounds. The verb 'list' and resource 'compound characteristics' are specific, and it distinguishes from sibling list tools by tying directly to search_compounds.

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

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

The description explicitly says these characteristics are used as preference keys in search_compounds, providing clear context. It lacks explicit when-not or alternatives, but for a simple reference list, the guidance is sufficient.

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

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

With no annotations, the description carries the burden. It states the output includes key fields but does not disclose pagination behavior, sorting, data freshness, or error handling. The schema covers limit/offset, but the description adds no behavioral context beyond listing.

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

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

The description is a single, concise sentence that front-loads the main purpose and key fields. It is efficient but could be slightly more structured (e.g., separating output description from filtering).

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 list tool with 6 parameters and no output schema, the description mentions the output fields but omits pagination details, sorting order, and behavior for empty results. It is adequate but not fully complete given the lack of annotations.

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 baseline is 3. The description repeats that filtering is possible by cancer type, keyword, or approval date, but adds no new semantic meaning beyond what the schema already provides.

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

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

The description explicitly states the tool lists FDA-approved oncology drugs with specific fields (indication, company, approval date, label links). The inclusion of 'oncology' differentiates it from general drug tools, and the filtering options are clearly listed.

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 mentions filtering by cancer type, keyword, or approval date, implying usage for list exploration. However, it does not explicitly state when to use this tool versus siblings like search_oncology or list_clinical_trials, nor does it provide when-not or alternative 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?

No annotations provided, so the description carries full burden. It mentions 'curated' and 'trusted sources' hinting at quality, but does not disclose ordering, pagination behavior beyond schema, rate limits, or any side effects. Adequate for a read-only list tool but leaves gaps.

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

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

Two sentences, 15 words, front-loaded with purpose. Every word earns its place; no fluff or repetition. Very efficient while covering key functionality.

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 list tool with 6 optional parameters and no output schema, the description is fairly complete: it explains the source (curated, trusted) and filter dimensions. However, it does not describe what fields each article contains (e.g., title, summary) or default sort order, which would help an agent anticipate results.

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% with all 6 parameters described. The description redundantly mentions filtering by cancer type, keyword, or published date, which aligns with schema but adds no new meaning beyond the schema itself. 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?

Clearly states it lists curated cancer news articles, distinguishing it from sibling tools like list_blog_posts and list_clinical_trials. The verb 'list' and resource 'cancer news articles' are specific and unambiguous.

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

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

Implicitly indicates usage for retrieving aggregated news with filtering options, but lacks explicit guidance on when to use this tool over alternatives such as list_blog_posts or list_clinical_trials. No when-not-to-use or prerequisites mentioned.

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

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

No annotations are provided, so the description carries the full burden. It states the tool lists papers with specific fields but omits behavioral traits like pagination (limit/offset exist in schema) or default ordering. The description does not cover mutation safety or rate limits.

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 with no superfluous words. The main action and key filtering capabilities are front-loaded, achieving maximal clarity with minimal length.

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 list tool with 7 parameters and no output schema, the description covers the source, content fields, and filter options. Minor gaps include pagination behavior and result order, but overall it is 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%, earning a baseline of 3. The description adds value by specifying that 'search' applies to title and abstract and giving examples for 'cancerType', going beyond the schema's generic descriptions.

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

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

The description clearly specifies a specific verb ('list'), resource ('research papers'), and scope ('oncology, ingested from PubMed'). It distinguishes this tool from siblings like 'get_research_paper' (single paper) and 'list_clinical_trials' (different resource).

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 guidance on when to use this tool versus alternatives like 'search_oncology' or 'list_news'. There are no explicit when-to-use, when-not-to-use, or alternative mentions, leaving the agent to infer context.

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

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

With no annotations, the description must disclose behavior. It adds 'No API key required', but lacks details on side effects, rate limits, or other behavioral traits. Adequate but minimal.

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 purpose, no superfluous words. Every sentence adds value.

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

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

For a zero-parameter health check tool without output schema, the description is complete: purpose, auth requirement, and usage hint are all provided.

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?

No parameters exist, and schema coverage is 100%, so the description need not add parameter details. Baseline 4 applies.

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

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

The description clearly states the verb 'Check' and the specific resource 'IBM MAMMAL prediction model health'. It distinguishes itself from sibling predict_* tools by explicitly mentioning to call it before them if a prediction timed out.

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

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

Provides clear context: 'No API key required' and recommends calling before predict_* tools after a timeout. However, it lacks explicit when-not-to-use or alternative tools.

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

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

No annotations provided, so description carries full burden. It discloses CPU-bound nature and time cost (up to 60s) and output format, but does not mention side effects, prerequisites, or error handling. Adequate but not exhaustive.

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

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

Two concise sentences: first states purpose and output, second states performance. No filler, front-loaded, efficient.

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?

Tool is simple (1 param, no output schema, no annotations). Description covers purpose, output, and performance. Minor gaps: missing input validation info, error states. Still fairly complete for its 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?

Single parameter 'smiles' has schema description 'Compound structure in SMILES notation.' Tool description adds no extra meaning beyond that. With 100% schema coverage, baseline score 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 states a specific verb ('predict'), resource ('clinical-trial toxicity for a compound'), and model ('IBM MAMMAL'). It distinguishes from siblings like predict_dti and predict_ppi by specifying the prediction domain.

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?

Implied usage through domain specificity (clinical-trial toxicity vs. other predictions) and a performance note (CPU-bound, up to 60s), but no explicit when-to-use/when-not-to-use or direct alternatives.

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

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

With no annotations, the description bears full burden. It discloses that inference is CPU-bound and may take up to ~60s, which is useful. However, it does not mention requirements (e.g., model availability), error behavior, or side effects. Some behavioral context is provided, but not comprehensive.

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

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

The description is two sentences, front-loading the core purpose and key behavior. Every sentence adds value: the first defines purpose, the second provides behavioral context. No unnecessary words.

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

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

For a tool with 4 parameters and no output schema, the description explains the output concept (pKd) and mentions the model. However, it does not describe the return format or data structure, which is a gap given the lack of output schema. Additional context like validation rules or typical values would improve completeness.

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

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

The schema already describes all 4 parameters with 100% coverage. The description adds minimal new semantic detail beyond the schema; it mentions the model (IBM MAMMAL) but does not clarify optional parameters (norm_y_mean, norm_y_std). Baseline 3 is appropriate.

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

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

The description clearly states the tool predicts drug-target binding affinity as pKd, a specific metric. The verb 'Predict' and resource 'drug-target interaction' are explicit. It distinguishes from sibling tools like predict_clintox (clinical toxicity) and predict_ppi (protein-protein interaction).

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 lacks guidance on when to use this tool versus alternatives such as predict_clintox or predict_ppi. No when-to-use or when-not-to-use information is provided, leaving the agent without context for selection.

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

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

No annotations are provided, so the description carries the burden. It discloses CPU-bound inference and up to 60s latency, which is helpful. However, it does not state whether the tool is read-only or has side effects, nor does it mention idempotency or authentication requirements.

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

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

Three concise sentences with front-loaded purpose. No redundant information; every sentence adds value (purpose, output format, performance note).

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 2-parameter tool with no output schema, the description adequately covers purpose, input constraints, output meaning, and performance. Could mention sequence length limits or error handling, but overall 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 baseline is 3. The description adds minor context beyond the schema (e.g., 'no FASTA header'), but does not provide additional value such as length limits or format examples beyond single-letter codes.

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

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

The description clearly states the verb 'predict' and the resource 'binding-affinity class for a pair of proteins', and specifies the output labels. It distinguishes from sibling tools like 'predict_clintox' (clinical toxicity) and 'predict_dti' (drug-target interaction).

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 mentions CPU-bound nature and time, implying it's for offline use, but does not explicitly state when to use vs alternatives or when not to use. No exclusions or alternative tool names are provided.

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

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

With no annotations provided, the description carries full responsibility. It discloses fuzzy matching for examples and the -4 to +4 scale for preferences, but does not describe the return format, ordering, pagination, or other behavioral traits. Essential behaviors are communicated, but gaps remain.

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 exceptionally concise, consisting of two sentences that front-load the core functionality. Every sentence serves a distinct purpose, with no redundant or unnecessary words.

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

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

Despite the lack of an output schema, the description mentions the include_characteristics parameter affecting results. However, it does not specify what data is returned (e.g., compound IDs, names). Given the context signals (4 params, no output schema), more detail on return values would improve completeness.

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% (baseline 3). The description adds meaningful context beyond the schema, such as clarifying that examples are fuzzy-matched and that preference names come from another tool. This enhances understanding of parameter usage.

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

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

The description clearly states the tool's purpose: finding pharmaceutical compounds via two distinct methods (fuzzy-matched examples or characteristic preferences). It uses specific verbs and resources, and distinguishes itself from sibling tools like list_compound_characteristics by referencing them for supplementary information.

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

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

The description explicitly instructs to provide exactly one of `examples` or `preferences`, and directs users to list_compound_characteristics for available preference names. This provides clear guidance on when to use each mode, though it lacks explicit exclusion of other sibling tools like search_oncology.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions results are grouped by type but does not address pagination, rate limits, case sensitivity, error handling, or read-only nature. For a search tool, these are significant gaps.

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

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

The description is two sentences, no fluff, and front-loaded with the action and purpose. Every word 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 no output schema, the description should hint at return format. It says 'results grouped by type' but does not specify structure, pagination, or error cases. It is adequate for a simple search tool but could be more complete, especially regarding return details.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context about grouping results and fetching single records, but does not clarify the types parameter format beyond what the schema provides. No additional semantics for individual parameters.

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

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

The description clearly states 'Search a keyword across every Cure Cancer With AI dataset at once' and lists the specific dataset types, using a specific verb and resource. It distinguishes itself from siblings by advising to use this first for broad discovery and then fetch a single record, implying it is a cross-dataset search tool.

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

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

The description provides explicit usage guidance: 'Use this first for broad discovery, then fetch a single record by id/slug/nctId for full detail.' This tells when to use this tool and when to use the sibling get_* tools. However, it does not explicitly contrast with other search tools like search_compounds.

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