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

With no annotations, the description carries the full burden. It usefully discloses the change taxonomy (new_notice, meeting_date_change, ...) and the ISO-date input requirement, which is real behavioral context. However, it says nothing about what happens when the date is far in the past, whether results are paginated, or any auth/rate-limit traits.

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 resource and the temporal constraint come first. Brevity is efficient but borders on under-specification given the undocumented `watch` parameter.

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 needn't be explained, and the changed-field taxonomy is a nice touch. But for a tool in a crowded sibling set with an undocumented optional parameter and no routing guidance, an agent still has gaps before calling 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 description coverage is 0% with 2 parameters. The description clarifies `since` as an ISO date, but `watch` — a nullable string with default null — is completely unexplained in both schema and description. Half the parameter surface is opaque, so compensation is only partial.

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+resource: detecting FDA advisory committee changes, with example change types (new_notice, meeting_date_change) and a temporal qualifier. An agent knows exactly what domain and operation this covers. It does not differentiate from close siblings such as fda_changes_since, changes_feed, or snapshot_adcom, so it stops 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?

"Since an ISO date" implies a delta/refresh use case, but there is no explicit statement of when to use this versus snapshot_adcom (current state) or changes_feed (aggregated feed) — both present in a 21-tool sibling list. No prerequisites, exclusions, or alternatives are named.

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 disclosure burden. It reveals the output serialization (JSON Feed 1.1 vs RSS 2.0), which is genuinely useful, but says nothing about the default lookback window when 'since' is omitted, what 'watch' scopes to, how many items a feed contains, or whether the feed is idempotent/pollable.

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 lines with the core purpose front-loaded and zero filler. The second line, a bare 'tool: a | b | c' fragment, is somewhat telegraphic and reads like a schema note rather than prose, but it is 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?

An output schema exists, so return values need no explanation. But for a 4-parameter cross-source tool with zero annotations and zero schema descriptions, the definition leaves critical call-shaping questions unanswered: the default time window, the meaning of 'watch', and how this relates to the per-source change 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 description coverage is 0% and there is no enum on 'tool', so the description does real work by enumerating the accepted tool values (trials, fda, grants, papers, sec, ema, adcom) and mapping json/rss to JSON Feed 1.1 / RSS 2.0. However, 'since' and 'watch' — half the parameters — receive no explanation at all in either the schema or the description.

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

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

States a specific verb+resource: a digest of detected changes rendered as a feed document, with the two serialization formats named. The 'as a feed document' framing implicitly separates it from the structured * _changes_since siblings, but it never names them, so the differentiation is left to inference.

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, or alternative is stated. An agent cannot tell from the description whether to call changes_feed instead of paper_changes_since or adcom_changes_since when it wants change data, or whether this is meant for feed readers / polling only.

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

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

With no annotations, the description carries the full burden and does disclose important behavior: alias-resolved sponsor matching, the basic=True shortcut, preprint_days=0 to skip preprints, and that SEC PDUFA candidates are UNVERIFIED. It omits cost/latency expectations for an aggregation tool and how ambiguous company names are resolved.

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?

Front-loads 'Merged company view' and packs the source list and caveats into two dense sentences. Slightly run-on, but every clause carries information and 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 complex multi-source aggregation with no output schema and 0% parameter coverage, the description gives a good source inventory and key caveats. However, it leaves the output structure and two parameters undocumented, which is a meaningful gap for a tool this broad.

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 0%, so the description must compensate. It documents company (name or ticker with examples), basic, and preprint_days (including the 0=skip sentinel), but never explains recent_days or include_collaborations, leaving two of five parameters ambiguous.

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 resource and scope: a merged company view combining ClinicalTrials.gov, FDA, NIH, PubMed, preprints and SEC data. This distinguishes it clearly from the many single-source siblings such as search_trials or fda_approvals.

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 'Merged company view' and the basic=True switch that trims enrichment sources, but there is no explicit guidance on when to call this versus the individual source tools. An agent must infer that this is the overview tool and siblings are for targeted queries.

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 does add real value by naming the change categories that can surface, but it says nothing about pagination, auth, deduplication, or whether results are bounded — gaps that matter for a change-feed 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?

One front-loaded sentence with no filler; the resource and temporal qualifier come first. The trailing '(...)' enumeration is slightly ragged but efficient overall.

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 needn't be explained, but the ambiguous 'watch' parameter and the absence of any routing guidance against the many sibling snapshot/change tools leave real holes for a two-parameter delta 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 description coverage is 0%, so the description must compensate. It adds the 'ISO date' format hint for 'since', but the 'watch' parameter is never mentioned, leaving a required semantic entirely undocumented.

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 resource (EMA changes) and enumerates the change types detected (new_medicine, status_change, ec_decision_date_change), which lets an agent distinguish this from ema_medicines or snapshot_ema. It is clear without naming 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?

There is no statement of when to use this versus snapshot_ema, snapshot_watch, or changes_feed. The 'since an ISO date' phrasing implies incremental/delta polling, but the agent must infer that, and no exclusions or prerequisites are given.

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 supplied, so the description carries the full burden. It does disclose useful traits: results are ordered newest-event-first, the data source is EMA, and EMA must be cited. It does not state that the operation is read-only, does not explain max_results truncation or pagination behaviour for a default-100 result cap, and does not describe what an empty filter set 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?

Front-loaded with the resource and scope, then filters, then ordering, then source/citation. Every clause carries information; no filler sentences.

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 filter set is well covered. But with 11 parameters, zero annotation coverage and zero schema descriptions, the gaps around 'rank', 'exclude', and result-limit behaviour leave the agent guessing on parameters it will actually have to set.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it clarifies drug matching (name/INN/substance), holder/applicant, keyword scope (indication or therapeutic area), status with concrete example values ('Opinion', 'Authorised', 'Refused'), and the since/until format (YYYY-MM-DD date window). Three of eleven parameters remain unexplained — notably 'rank' and 'exclude', whose semantics are not inferable from their titles.

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 resource (EMA centrally authorised human medicines) and enumerates the record types it covers: CHMP opinions, EC authorisations, refusals, withdrawals, suspensions. It is clearly a filtered search over that dataset, which implicitly separates it from snapshot_ema / ema_changes_since, but it never names those siblings to make the distinction explicit.

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 through the available filters (holder, drug, keyword, status, date window, orphan/PRIME), so an agent can infer this is the query tool for arbitrary EMA medicine lookups. There is no explicit when-to-use guidance or exclusion against sibling tools like ema_changes_since (incremental deltas) or snapshot_ema (bulk capture), which is exactly what the agent must decide between here.

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

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

With no annotations, the description carries the full burden and does well: it discloses that agenda=True 'costs one request per notice' (a real cost/rate signal), gives default windows and the default tobacco exclusion, and warns to check the notice and fda.gov for late changes. It stops short of describing result ordering, pagination, or whether results are cached, which keeps it off 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?

Front-loaded with what the tool returns, then filter semantics, then source/caveat, so an agent can stop reading early. Dense but nearly every clause carries information; the parenthetical examples ('e.g. a drug or company') are slight filler but genuinely disambiguate keyword.

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 9-parameter, annotation-free tool with an output schema (so return shape needn't be explained), the description covers source, defaults, filter meaning, cost, and data-freshness caveats. The uncovered exclude and max_results parameters are the only meaningful omission 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 0%, so the description must compensate and mostly does: it supplies the YYYY-MM-DD format and default window for since/until, enumerates the area values (drugs, biologics, devices, tobacco, other) and their default, explains keyword's match fields, and explains upcoming and agenda's cost. Two of nine parameters — exclude and max_results — get no mention anywhere, which is the remaining 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?

States the concrete resource (FDA advisory committee meeting notices from the Federal Register) and enumerates exactly what comes back: committee, meeting date, notice kind, and parsed NDA/BLA numbers and sponsors. An agent can tell it is a filtered listing tool, but the description never names the close siblings (snapshot_adcom, adcom_changes_since) that do the baseline-save and diff jobs, 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?

Usage is implied rather than stated: 'upcoming=True keeps meetings dated today or later' and 'keyword matches title/agenda/sponsor' hint at the retrieval scenarios, and the stated 365-day default tells an agent it must widen scope explicitly. However, there is no explicit when-to-use/when-not framing and no pointer to the snapshot/change-feed alternatives in the sibling list.

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, and it does disclose useful traits: record ordering (newest first), inclusion of originals plus supplements, and sponsor alias resolution. It omits permission/auth notes, pagination/max_results truncation behavior, and what the result set looks like beyond what the output 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?

Three dense, front-loaded clauses with no filler; the source and scope lead, parameter hints follow. Slightly telegraphic but every fragment 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 so return values needn't be explained, but with 0% schema coverage and six parameters, two parameters (max_results, application_number) are undocumented anywhere. For a read-only listing tool that is adequate but not 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 0%, so the description must compensate, and it does for four of six parameters: sponsor (alias-resolved, with examples), since/until (status date, YYYY-MM-DD), and novel_only (original NME/BLA only). max_results and application_number are left undocumented, but the semantic value added is substantial.

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 resource (Drugs@FDA submissions/approvals), source (openFDA), and scope (ORIG + supplements) with ordering (newest first). This is enough to distinguish it from the change-feed siblings like fda_changes_since, though it never explicitly contrasts with them.

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

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

Implied usage is clear — query approvals filtered by sponsor and date, or restrict to novel approvals. However, there is no explicit when-to-use versus alternatives such as fda_changes_since or sponsor_pipeline, so routing between siblings is left to inference.

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

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

With no annotations, the description carries the full burden, but it does add real behavioral context: changes are 'detected' (i.e., derived from watch snapshots) and the source is fdawatch watches, and it names what counts as a change. It says nothing about result ordering, limits, or whether an empty result is possible when no watches exist, which are meaningful gaps for a no-annotation 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?

A single compact sentence with the resource and the key parameter constraint front-loaded; no filler or restatement of the tool name.

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

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

An output schema exists, so return values need not be explained, and the required parameter's format is covered. What remains missing is the semantics of the optional 'watch' filter and any ordering/pagination expectation — modest but real gaps for a 2-parameter listing 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 description coverage is 0%, so the description must compensate. It correctly pins 'since' to ISO date format, which is the highest-value detail for the required param. The optional 'watch' parameter is only obliquely referenced via 'from fdawatch watches' — no format, no statement that it filters to a single watch, and no indication of what happens when omitted.

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 ('List') plus resource ('detected FDA changes') and enumerates the change types (new submissions, approvals, label revisions), which differentiates it from grant_changes_since, trial_changes_since and ema_changes_since by domain. It does not explicitly address the cross-domain sibling changes_feed, so differentiation is strong but not fully spelled 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?

The parenthetical 'from fdawatch watches' implies this only surfaces changes covered by configured watches, which is useful scoping context. However, there is no explicit statement of when to prefer this over changes_feed or the other *_changes_since tools, and no when-not 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?

With no annotations, the description carries the full behavioral burden. 'Get' implies a read operation and 'normalized' indicates the returned record is transformed, but details such as missing-ID behavior, data freshness, or response shape are not 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?

The description is a single front-loaded sentence with no wasted words. It states the action, cardinality, resource, and key in one pass.

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

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

For a simple one-parameter lookup with no output schema, the description covers the core purpose but leaves the expected response content and error behavior underspecified. 'Normalized trial record' is useful but not fully concrete.

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 0%, so the description must compensate. It clarifies that the sole parameter is an NCT ID used to identify a single trial, but it does not provide expected format or validation 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?

The description uses a specific verb ('Get') and resource ('one normalized trial record') and states the lookup key ('by NCT ID'). This clearly distinguishes it from plural search tools like search_trials and change-oriented siblings like trial_changes_since.

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 phrase 'by NCT ID' implies the tool should be used when a specific trial identifier is already known, but the description does not explicitly say when to use this versus search_trials or trial_changes_since. Usage 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It reveals the kind of changes returned but does not state whether the operation is read-only, whether it requires specific permissions, how results are ordered or paginated, or what 'watch' does.

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 is concise, though the extreme brevity contributes to missing usage and parameter details, which are better captured 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 described. However, with no annotations and 0% schema description coverage, the description is critically incomplete for the unexplained 'watch' parameter and lacks any behavioral context an agent would need to invoke the tool reliably.

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 0%, so the description must compensate for both parameters. It explains that 'since' expects an ISO date, but the optional 'watch' parameter is completely undefined, leaving half the parameters semantically opaque.

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 resource (grant changes) and lists example change types (new_award, award_amount_change), making the tool's purpose clear. However, it does not explicitly distinguish itself from siblings such as search_grants or snapshot_grants, leaving the agent to infer that it is a change-feed 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 phrase 'since an ISO date' implies when to use the tool, but there is no explicit guidance on when to choose it over siblings like trial_changes_since or changes_feed, nor any exclusions. The optional 'watch' parameter is also left unexplained.

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 present, so the description carries the full behavioral burden. It implies a read-only time-scoped delta, but discloses nothing about result caps, ordering, whether it requires an existing watch/snapshot baseline, or rate limits — all material for a change-feed tool with a 'watch' parameter.

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 or redundancy. It is efficient, though the brevity here leans toward under-specification rather than true conciseness.

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 (2 params, 1 required) and an output schema exists, so return values need not be explained. Still, with no annotations and an undocumented 'watch' parameter, an agent lacks enough context to invoke it confidently when a watch is involved.

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 0%, so the description must compensate. It adds useful format semantics for 'since' (ISO date), but the 'watch' parameter is completely unexplained — the agent cannot tell whether it is a watch identifier, a name, or a filter, and it is the only optional parameter on the 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 specific verb-phrase and resource: 'New papers/preprints detected since an ISO date.' An agent immediately knows this is a delta/change-detection query over papers. However, it does not differentiate itself from adjacent siblings such as search_papers, snapshot_papers, or changes_feed, which look similarly relevant to an agent choosing a 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?

There is no guidance on when to use this versus search_papers (search by query), snapshot_papers (baseline capture), or the umbrella changes_feed. Nothing tells the agent whether a prior snapshot_watch/snapshot_papers call is a prerequisite, or what happens if no baseline exists.

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 disclosure burden, and it does disclose non-obvious result behavior: newest award notice first, future-dated awards flagged and sorted after current ones, exclude drops any grant mentioning a term, and rank reorders by relevance. It says nothing about truncation behavior beyond max_results, rate limits, or error conditions.

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 dense paragraph with no filler — nearly every clause maps to a parameter or a behavioral trait. It is somewhat cramped and semicolon-chained, which makes scanning harder than a short bulleted mode summary would be, but no sentence 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 12-parameter tool with zero annotation coverage, the description covers behavior and most parameters well, and an output schema exists so return values need no explanation. However, the two undocumented parameters (max_results, fiscal_years) mean an agent still cannot call the tool fully informed from this definition alone.

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 0%, so the description must carry all parameter meaning, and it does for roughly ten of twelve: PI formats and pi_exact, org wildcard and org_exact, keyword syntax, the since/until YYYY-MM-DD window, exclude, rank, and include_future. max_results and fiscal_years are never mentioned, leaving the fiscal_years integer list completely unexplained.

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+resource ('NIH RePORTER grants') and enumerates the searchable dimensions (org, PI, keyword, award date), so the tool's purpose is unmistakable. It never names or contrasts the sibling snapshot_grants or grant_changes_since, so an agent must infer the search-vs-monitor split 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?

Usage conditions are stated explicitly for each mode: wildcard matching 'unless org_exact', the two accepted PI name formats with 'pi_exact for strict', quoted phrases and OR in keyword, and include_future=False to drop future awards. What's missing is any guidance on when to choose this tool over the sibling change-tracking tools, which is left implicit.

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 and does meaningful work: it discloses multi-source aggregation, Europe PMC keyword search with bioRxiv API fallback, and DOI/PMID deduplication. 'Metadata + links only' usefully bounds the return payload. Missing: pagination/truncation behavior relative to max_results, and any rate-limit or auth notes.

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?

Highly compact and front-loaded: source scope, dedup, then a walk through the filters in roughly schema order. The telegraphic, semicolon-chained fragments cost some readability but almost 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 9-parameter, fully optional, annotation-free tool with no output schema, this covers the source list, dedup, filter combinatorics, date format and return shape. The gaps are the two integer parameters and any result-count/pagination caveats.

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 0%, so the description must compensate and largely does — it defines the sources enum values, OR semantics for affiliation/drug, raw query syntax for keyword, YYYY-MM-DD for since, title-term dropping for exclude, and relevance sorting for rank. Only max_results and preprint_days are left unexplained, which keeps it from a 5.

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?

Opens with a specific verb+resource ('Papers from PubMed, Europe PMC and bioRxiv/medRxiv preprints') and names the retrieval mechanism plus DOI/PMID dedup. It does not explicitly contrast itself with siblings like snapshot_papers or paper_changes_since, so it stops 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?

Filter semantics (OR'd lists, raw query syntax, exclude, rank) imply how to shape a query, but there is no explicit 'use this when you want X, use snapshot_papers when you want Y' guidance. The agent must infer selection from the sibling names 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?

With no annotations, the description carries the full behavioral burden. It does disclose two non-obvious behaviors: that exclude drops trials based on title/conditions/interventions matching, and that rank sorts by relevance to the query. It says nothing about result volume/pagination, default behavior when all filters are omitted (a 9-param all-optional tool), or upstream rate limits, so the picture is only partially filled in.

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 dense sentences, no filler, with the core action front-loaded before the parameter notes. The compressed semicolon style is efficient, though it reads more like shorthand notes than a structured brief, which slightly hurts scannability.

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. But for a 9-parameter, all-optional, annotation-free tool, the description leaves the four string filters (sponsor, condition, intervention, max_records) and the no-filter default behavior entirely to inference, which is a meaningful gap for an agent constructing a query.

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 0%, so the description must compensate, and it partly does: it supplies value formats and examples for phases (["PHASE2","PHASE3"]), statuses (["RECRUITING"]), and changed_since (YYYY-MM-DD), plus the semantics of exclude and rank. However, sponsor, condition, intervention, and max_records (including its default of 50 and whether it caps results) get no explanation anywhere, leaving nearly half the parameters undocumented.

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 ClinicalTrials.gov." This clearly separates it from the sibling search_grants, search_papers, and ema_medicines tools without needing to name them. It stops short of explicitly distinguishing search_trials from get_trial or trial_changes_since, which keeps it from 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?

The description never says when to choose search_trials over get_trial, trial_changes_since, or sponsor_pipeline, and it gives no prerequisites or exclusions. Usage is only implied by the word "Search" and by parameter examples, so the agent must infer the routing decision.

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 does real work: it discloses that candidates are regex extractions, that they are unverified, that best=True marks the date nearest each mention, and that source links are returned for checking. It omits operational traits such as how many documents are scanned by default (max_docs exists in schema but is unexplained) or any rate/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?

Two dense sentences with the scope and output shape front-loaded and the data-quality caveat immediately after. No filler or restatement of the tool name.

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

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

An output schema exists, so return values needn't be explained, and the company-identifier flexibility is covered. However, the date-range and document-count parameters remain semantically undefined and there are no annotations to convey safety or cost profile, leaving meaningful gaps for a document-scanning 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 description coverage is 0%, so the description must compensate. It does clarify the required `company` parameter accepts a name, ticker or CIK, which is genuinely additive, but says nothing about `since`/`until` (date format? inclusive?) or what `max_docs` bounds, leaving three of four parameters to inference.

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: it returns SEC EDGAR 8-K documents mentioning 'PDUFA' for a named company, along with candidate dates and source links. This is clearly separable from structured-data siblings like fda_approvals or fda_adcom_meetings, since this tool mines filings text rather than returning curated events.

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 resource description rather than stated: an agent can infer this is the tool for PDUFA hints buried in filings, but the description never says when to prefer it over fda_approvals or how to combine them. The 'UNVERIFIED regex extractions' caveat hints at a verification workflow but doesn't spell out when/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?

No annotations exist, so the description carries the full burden. It does disclose a meaningful side effect (persisting notices into the local DB) and enumerates the change categories returned (new meetings, amendments, postponements, cancellations), but says nothing about write/permission requirements, idempotency, or how many records come back.

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 dense sentence front-loads the action and the return payload, with the data source appended. No filler, though the return-value clause is long enough to strain readability.

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, no annotations, and zero schema coverage on five parameters, the description should clarify filtering behavior and the snapshot lifecycle; it covers only the high-level purpose and the kind of changes returned.

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?

Five parameters at 0% schema description coverage, and the description mentions none of them — area, since, keyword, committee, and the required name are entirely unexplained. Even 'since' is ambiguous because the text refers to the snapshot delta rather than the 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?

Names a specific verb (snapshot) and resource (FDA advisory committee notices), and states what the call returns: new notices and meeting-date changes. It is distinguishable from the read-only sibling fda_adcom_meetings, though it does not explicitly contrast with adcom_changes_since.

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 phrase 'since the previous snapshot' implies an incremental-refresh workflow, but the description never states when to choose this over fda_adcom_meetings or adcom_changes_since, nor whether a first run must precede it.

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

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

With no annotations at all, the description carries the full burden, and it does disclose two important traits: the operation writes persistent state ('into the local DB') and the diff is scoped to four specific change categories. It does not disclose whether snapshots are overwritten or versioned, what identity the snapshot is keyed by, or any auth/rate constraints.

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 action, zero filler. The parenthetical list of change types is dense but each item adds information about what the diff covers.

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 stateful, six-parameter tool with no annotations and no output schema, the description covers the action and the return categories but leaves parameter meaning, snapshot identity/naming, and repeat-run semantics unexplained. An agent could not confidently construct a correct first call, particularly for the required 'name' parameter.

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 0% across six parameters and the description explains none of them: 'name' is required but never defined (snapshot identifier vs. query label), and 'drug', 'holder', 'status', 'keyword', 'since' are not addressed at all. 'since' is especially ambiguous — it reads like a date cutoff, yet the description ties change detection to 'the previous snapshot', leaving the two mechanisms unreconciled.

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 ('Snapshot an EMA medicines query') plus an explicit account of what it returns: new medicines and status/opinion/EC-decision/withdrawal changes. It implicitly separates itself from the search sibling (ema_medicines) by framing this as a persisted snapshot, though it never names ema_medicines or ema_changes_since directly.

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?

'changes since the previous snapshot' implies a repeated monitoring workflow (run once to baseline, again later to diff), which is useful implied context. However, there is no explicit statement of when to prefer this over ema_medicines or ema_changes_since, and no note on first-run behavior when no prior snapshot exists.

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

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

With no annotations, the description carries the full burden. It does disclose the key behavior that state is written to a local DB and that results are diffs against a prior snapshot, which is valuable. But it omits whether reusing the same name overwrites an existing snapshot, what the first call returns with no baseline, and whether the write is reversible - significant gaps for a stateful mutation.

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 dense sentence with the action front-loaded and the return payload trailing, with no filler. It could be slightly clearer by splitting the persistence claim from the diff claim, but 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 6-parameter stateful tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. An agent can guess the general effect but not the snapshot naming/overwrite semantics or the meaning of the filter parameters, which are the main risks here.

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 0% across 6 parameters, so the description must compensate and does not. It never explains that 'name' is the required snapshot identifier, nor what pi/org/since/keyword/org_exact filter, nor whether org_exact modifies matching semantics of org - all of which are ambiguous from the bare 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 ('Snapshot a grant query into the local DB') plus the return payload, so the agent knows this both persists a query and diffs it. It is distinguishable from search_grants (read-only search) and grant_changes_since (diff without snapshot) by implication, but neither sibling is named 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?

The phrase 'since the previous snapshot' implies repeated invocation to build a diffing baseline, and the fact that a query is stored implies the snapshot is reused later. However, there is no explicit statement of when to prefer this over grant_changes_since or search_grants, nor of first-run behavior when no previous snapshot exists.

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 behavioral burden. It discloses that this is a snapshot operation returning new results since a prior snapshot and that preprints may be included, but it does not explain snapshot persistence, naming behavior, permission requirements, or what happens when no prior snapshot exists.

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 communicates the core action and return semantics 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?

With no annotations, no output schema, six parameters, and zero schema description coverage, the definition is too sparse. It omits key operational details such as snapshot storage/naming semantics and the meaning of most parameters, leaving the agent under-equipped to invoke the tool correctly.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate substantially. It vaguely references a paper query and optional preprints but does not explain the required 'name' parameter, the meaning of 'since', how drug/keyword/affiliation filters work, or what 'preprint_days' controls.

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 ('Snapshot a paper query') and clarifies the sources and return behavior ('PubMed + optional preprints', 'papers new since the previous snapshot'). It is clear enough to distinguish this from a plain paper search, though it does not explicitly name the sibling alternatives.

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

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

The mention of returning papers 'new since the previous snapshot' implies a recurring monitoring workflow, but there is no explicit guidance on when to use this versus search_papers or paper_changes_since. The intended usage is inferable 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool writes a snapshot into the local DB and returns a delta from the previous snapshot, which are meaningful traits, but it omits important details such as overwrite behavior, permissions, what happens when no prior snapshot exists, and the return format.

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 language. The parenthetical '(watch)' is helpful but slightly opaque, and the sentence remains tight and efficient overall.

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 five parameters, no annotations, no output schema, and zero schema description coverage, the one-sentence description is not complete enough. It covers the core action but leaves parameter meanings and key behavioral details unexplained.

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 0%, so the description must explain the five parameters, but it does not. It indirectly suggests that 'name' identifies the saved query/watch, yet phases, sponsor, condition, and intervention are not mentioned at all, leaving most parameter semantics undocumented.

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: snapshot a saved query ('watch') into the local DB and return changes since the previous snapshot. It is clear what the tool does, but it does not distinguish itself from sibling snapshot tools like snapshot_grants, snapshot_papers, snapshot_ema, or snapshot_adcom.

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 alternatives such as snapshot_grants, snapshot_papers, or the corresponding *_changes_since tools. The only implied usage is restating the purpose, with no explicit conditions, 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?

With no annotations, the description must carry the behavioral burden. It usefully discloses output shape (phase/status grouping, active trials sorted by primary completion), but leaves key questions open: whether max_records caps the summary counts or only the active-trial list, what happens when a sponsor has no trials, and whether results are read-only snapshots of current 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?

A single front-loaded sentence with the summary scope and sort behavior, zero filler. Everything stated 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?

No annotations and no output schema, so the description is the only source of behavioral detail; it does explain the returned structure well. However, given two undocumented parameters at 0% schema coverage, the description should have clarified sponsor identification and the max_records truncation semantics.

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 0%, so the description must compensate and largely does not. It implies 'sponsor' is a name but never says whether an ID or exact name is expected, and never mentions max_records (default 300) or what it bounds — a significant omission given the default silently truncates 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 — 'Summarize a sponsor's trial pipeline by phase and status' — plus a sort order for active trials. An agent can tell this is an aggregation view rather than a trial-by-trial search like search_trials or get_trial, though no sibling is named 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?

Usage is only implied: 'summarize a sponsor's pipeline' suggests a portfolio overview rather than a targeted lookup. There is no explicit statement of when to prefer this over search_trials or get_trial, and no exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully explains severity levels, critical triggers, shift_days, and min_severity filtering, but omits read-only status, permissions, result limits, pagination, and 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 front-loads the core action and uses compact enumerations for change types and severity semantics. It is dense but every sentence adds useful information with no filler.

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

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

The output schema covers return structure, and the description defines the input parameters well enough to invoke the tool. However, absence of annotations and schema descriptions means it should also cover watch ID source, result limits/pagination, and sibling routing; those gaps leave it only 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?

Schema description coverage is 0%, so the description must compensate. It defines all three parameters meaningfully: since as an ISO date, watch as an optional single watch, and min_severity with accepted values and filtering behavior. Watch identifier format/source is not specified, preventing a 5.

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 ('List') and resource ('detected changes') scoped to trials, and enumerates trial-specific change types. This clearly separates it from search_trials/get_trial and from grant/fda/paper change tools, though it does not explicitly route away from changes_feed.

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 guidance on when to use this tool versus alternatives such as changes_feed, snapshot_watch, or search_trials. The only behavioral guidance is about min_severity filtering, leaving the agent to infer the monitoring use case.

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