Arca Life Sciences

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the payload is the 'full indexed text' versus the search excerpt, which is useful. It says nothing about behavior for a missing recordId, response size limits, or whether the text is truncated, all of which matter for an open-world 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?

Two short sentences, front-loaded with the action and scoped by the parameter and the usage condition. No filler, no restatement of the title.

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-value shape need not be explained, and the tool is a one-parameter read with a clear precondition. The only remaining gap is failure behavior for an unknown or expired recordId in an open-world corpus, which is minor but real.

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 parameter is documented in the schema with length bounds, so the schema does the heavy lifting. The description adds provenance ('returned by search_medical'), reinforcing where a valid recordId comes from, but nothing about format or validity beyond that. 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 ('Read the full indexed text of one record'), names the corpus, and pins the lookup key to recordId. It is clearly distinguishable from the search/list siblings because it retrieves a single known record rather than querying a collection.

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 names the preceding tool ('Use after search when the excerpt is not enough'), which both gives the when-to-use condition and implies when-not (if the excerpt already answers the question). The alternative, search_medical, is named in the same sentence.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that the response is descriptive metadata about lanes and mirrored datasets, which is useful context, but says nothing about size, freshness, or whether lanes differ per server configuration.

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 key fact (which lanes this server supports) comes first. The trailing clause about mirrored datasets is dense but carries real information, so nothing is clearly 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?

This is a trivial no-parameter read tool with an output schema, so the description needn't explain return values. Still, it could be clearer that the result enumerates valid sourceTypes values for search_medical and whether search_papers shares those lanes, which matters for routing between siblings.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. It does mention sourceTypes, but that parameter belongs to search_medical rather than this 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?

States a concrete job: describe the corpus the server searches, specifically the source lanes accepted by search_medical's sourceTypes and the mirrored datasets beneath each. That is more specific than the title's generic 'List the indexed datasets' and ties the tool to a named sibling, though the verb 'describe' vs. 'list' leaves the exact output shape slightly fuzzy.

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 naming search_medical's sourceTypes, it hints you call this before search_medical to learn valid lane values. There is no explicit 'use this when' or any exclusion against fetch_source_record or search_papers, so the agent must infer the ordering.

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/idempotent/non-destructive, and the description still adds real context: the corpus is a mirror of already-published records, no submission capability exists, and results carry recordId and a citable source URL. It does not mention result ranking, pagination, or latency, which keeps 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?

The operative guidance is front-loaded, but the long comma-chained inventory of source databases is a catalogue dump that consumes most of the sentence without changing how an agent calls the tool. It is informative but bloated relative to the two or three rules that actually matter.

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 the description covers scope, safety boundaries, result handles, and source-lane selection. For a four-parameter search tool with fully documented schema, this is close to complete; only ranking/pagination expectations are 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 coverage is 100% and the facets (dateField semantics, DINS/NDC preservation, decision codes) are documented in the schema itself. The description adds one useful piece of strategy—prefer sourceTypes over whole-corpus search—and points at list_datasets for the lane list, but adds nothing about numResults or the 50-value filter budget. 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 mechanism ("hybrid keyword + semantic search") over a concretely named corpus (FDA labels, MAUDE, 510(k)/PMA, ClinicalTrials.gov, VAERS, etc.), which lets an agent distinguish it from search_papers and fetch_source_record immediately.

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?

Gives an explicit when-not ("do not call it for requests to file or submit a report") and a positive routing rule ("when the question names a record type, pass the matching sourceTypes rather than searching the whole corpus"), plus names fetch_source_record as the consumer of returned recordIds.

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, idempotent, openWorld and non-destructive, so the safety profile is carried structurally. The description goes beyond that by disclosing the ranking mechanism (Arca index fused with PubMed Best Match) and the external enrichment sources (OpenAlex), which tells the agent why result order may differ from a plain PubMed query. What is missing is any note on latency, rate limits, or what happens when OpenAlex metadata is unavailable for a record.

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 identifying verb phrase, and the second sentence is a compact enumeration of returned fields rather than prose padding. The result-field list is arguably redundant given the output schema exists, which is the only thing keeping it off 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 and annotations covering the safety profile, the description need not restate return shapes or side effects, and it correctly spends its words on ranking provenance instead. For an eight-parameter search tool with full schema coverage, that is close to sufficient. The remaining gap is routing guidance against search_medical, which no structured field 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 100%, so every one of the eight parameters is already documented in the input schema with bounds and defaults. The description only gestures at the filterable dimensions by naming citation count and open-access status among the returned fields, adding no format guidance, interaction effects, or semantics beyond the schema. Baseline 3 is the right landing point when the schema does all the parameter 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?

The description opens with a specific verb and resource ("Ranked PubMed literature search") and explains what makes the result set distinctive: a fusion of Arca's paper index with PubMed Best Match, enriched with OpenAlex citation and open-access data. An agent knows exactly what corpus is being searched. It stops short of distinguishing itself from the sibling search_medical, which is the one ambiguity a reader would still have.

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 statement and no exclusion or alternative named, despite search_medical sitting right beside it as an obvious candidate for similar queries. The reader must infer from the name and the mention of PubMed that this is the biomedical-literature search path. No prerequisites or fallback guidance are given.

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