nerai-mcp

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral detail beyond them: a four-digit heading returns contained CHPL subheadings and prompts for HS6, and NERAI refuses to infer a classification. That edge-case behavior is exactly the kind of context annotations cannot express.

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

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

Two sentences, front-loaded with the core action and the definition, then the input constraint. The second sentence is dense but each clause (four-digit behavior, rationale, no-inference rule) carries information rather than 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?

There is no output schema, so the description bears some burden for describing return values; it explains the four-digit return case but never says what a successful six-digit lookup returns (match/no-match, control details, etc.). Annotations handle the safety profile, leaving this the main gap for a single-parameter lookup tool.

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

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

Schema coverage is 100% and the schema says 'ideally six digits', but the description sharpens this into a hard requirement and explains the consequence of supplying only four digits. That is genuine added meaning about the parameter beyond the schema's 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?

States a specific verb (look up) and resource (an HS code against the Common High Priority List) and even expands the acronym's meaning. It is clearly distinct from the country- and corridor-oriented siblings, though it does not explicitly contrast itself with the nearest sibling, get_commodities.

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 conveys context (goods jointly flagged by the US, EU, UK and Japan as most frequently diverted) and the input precondition of a six-digit code, but it never states when to prefer this tool over alternatives such as get_commodities or find_enforcement_precedent. Usage is implied rather than routed.

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, closed-world behavior, so the safety profile is covered. The description adds value beyond that by spelling out what the ranking returns (current percentile, 90-day change, regime state), which matters since there is no output schema.

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

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

Two sentences, zero filler: the first front-loads what is computed and returned, the second front-loads the use case with an example. Nothing to trim.

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 read-only ranking tool with no output schema, the description supplies the key return fields and a usage scenario, which is most of what an agent needs. Minor gaps (ordering direction, how the 60-country default interacts with the countries subset) remain unstated.

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

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

Schema description coverage is 100%, so the schema already documents limit, topic, and countries in detail. The description adds no parameter-level syntax or format detail, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Rank countries on a given risk topic') plus the exact output dimensions (percentile, 90-day change, regime state). Scope (multi-country ranking over a topic) implicitly separates it from single-entity siblings like get_country_risk or list_countries, but 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?

Gives a clear usage context ('portfolio or footprint screening') with a concrete example query, which tells the agent when this multi-country ranking is the right call. It stops short of naming alternatives or stating when-not to use it.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the score counts shared features and 'is not a probability' (guarding against misreading it as risk), and every result links to the authority's own published action, establishing an evidence standard.

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 tightly packed sentences, front-loaded with what is returned before the qualification rule and the score caveat. Every sentence carries distinct payload (source list, matching rule, return format, score caveat) 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?

With no output schema, the description usefully specifies the return shape (shared features plus a link to the published action) and the score's meaning. The qualification rule and the client-quoting caveat are also covered. Remaining gaps — parameter-level meaning, result limits, ordering — are minor.

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

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

Schema coverage is only 60% (transit and destination lack descriptions), so the description must compensate. It does explain the semantics that tie the parameters together — commodity/behaviour paired with destination/route — which is real meaning beyond the schema, though it still leaves transit and red_flag's individual roles implicit.

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 precise verb+resource: retrieving published enforcement actions (naming four specific authority types) that share features with a described shipment. No sibling tool covers this ground, and the parenthetical authority list makes the scope unmistakable.

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

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

The description implies usage by defining the matching rule ('shares the commodity or the behaviour AND the destination or route'), which tells an agent what inputs matter. However, it never states when to reach for this tool versus siblings like get_early_warning, get_country_risk, or check_commodity_controls, and offers no exclusions.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine analytical context the annotations cannot: the relationships are Granger-significant at a p<0.01 threshold and carry lag-in-days and F-statistic values, which tells the agent how to interpret and trust the output. It omits rate limits, coverage windows, and empty-result behavior.

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

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

Two sentences, both front-loaded: the first defines the resource and its statistical content, the second gives the use case. Every clause carries information (significance threshold, lag, F-statistic, purpose) 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?

With no output schema, the description carries the burden and does describe the shape of the returned relationships and their fields. It does not say how results are ordered, how many are returned, or what happens when no significant relationships exist, which are minor gaps for a single-parameter read tool.

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

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

There is a single required parameter with 100% schema description coverage, so the schema already documents it. The description only implies a country scope and adds no format or accepted-value detail (e.g. ISO codes vs names) beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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 ('causal network for a country') and pins down exactly what is returned: Granger-significant lead-lag relationships at p<0.01, with lag in days and F-statistic. This is clearly distinguishable from siblings like get_country_risk or get_early_warning, which report status rather than causal structure.

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?

'Use to explain WHY a risk is building, not just that it is' gives a concrete selection criterion that separates this from the descriptive risk tools. It stops short of naming the specific alternatives (e.g. get_early_warning, get_country_risk) or stating exclusions, so it is clear context rather than a full routing rule.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the scoring scale (0-100, ordinal) and the data scope (goods plus watch items), which is useful but is content description rather than behavior beyond annotations; nothing is said about freshness, coverage period, or result shape.

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 scale and scope are stated before the trailing 'goods and watch items' qualifier. The unexplained acronym 'NERAI CHPL' consumes space without adding agent-usable meaning.

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

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

For a no-argument, read-only retrieval tool with no output schema, the description covers what is returned and its scale, which is most of what an agent needs to call it. Missing only interpretive detail — what 'watch items' means, over what period or geography the corridors are measured, and the rough shape of 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?

The tool takes zero parameters, so the baseline is 4. The description adds nothing parameter-related, but there is nothing to document, and the schema is closed with additionalProperties=false.

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

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

The description names a concrete resource — circumvention-corridor intensity scores for Russia-bound diversion routes of controlled microelectronics — so an agent knows exactly what data comes back. It is somewhat jargon-heavy ('NERAI CHPL', 'watch items') and never explicitly contrasts itself with nearby siblings like get_maritime_corridors or check_commodity_controls, so it falls short of a 5.

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

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

There is no statement of when to reach for this tool versus alternatives such as get_maritime_corridors, get_supply_chain_risk, or check_commodity_controls. The Russia/microelectronics scope implies a domain, but no conditions, prerequisites, or exclusions 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds real behavioral context beyond that: licensing/public-domain status per source, update frequency (daily vs monthly), and that each row carries its own source and frequency.

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 core purpose and then the two source families and their change metrics in a compact form. Slightly dense with enumerated commodity names, but every clause carries distinguishing information rather than 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?

With no output schema and no parameters, the description must convey the return shape, and it does: two source families, the metrics attached (7/30-day changes, month-on-month), and per-row source and frequency fields. An agent knows what it will get.

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 the baseline is 4. There is no parameter semantics to clarify, and the description correctly spends its words on what the (parameterless) call returns instead.

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 (benchmark prices) and precise resources: U.S. EIA daily spot for Brent/WTI/Henry Hub and World Bank Pink Sheet monthly averages for gas, wheat, maize, urea. The sourcing detail makes it unmistakably distinct from the sanctions, risk, and corridor siblings.

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, no prerequisites, and no named alternative among siblings. Usage is only implied by the data content (benchmark commodity pricing), which an agent can infer but must guess at.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds real behavioral detail: the default truncation to 8 elevated topics, the toggle to 40, and the topic filter. It does not disclose rate limits or pagination, but it clearly characterizes the operation's behavior.

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

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

Two sentences, no filler, and the payload contents are front-loaded before the parameter guidance. The first sentence is dense with parentheticals but each clause conveys distinct return information, keeping it 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly (regime states, resilience, percentiles, shock horizons, default 8-topic cap). It is nearly complete for a read tool, though it leaves some terms like 'resilience score' 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 100%, so the schema already documents country, topic, and all_topics. The description reinforces all_topics (40 vs 8) and the topic filter in output context but adds little syntax or semantics the schema does not already carry; baseline 3 applies.

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

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

States a specific verb+resource (full risk read for one country) and enumerates the payload it produces: HMM regime state, resilience score, and topic percentiles with shock probabilities. This clearly delineates it from a list or comparison tool, but it never explicitly names siblings like compare_countries or get_early_warning, so it falls short of the top tier.

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: 'for one country' suggests this is the single-country read versus a comparison tool, and the all_topics/topic guidance is about parameters rather than when to choose this tool. There is no explicit when-to-use, when-not-to-use, or named alternative.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds real context beyond that: it operates across all 60 countries, returns two distinct lists (probability leaders plus risers and fallers), and signals 'calibrated' probabilities — useful framing since no output schema exists. It omits anything about ordering or truncation behavior, keeping it below 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?

One dense sentence plus a short framing question, with the broadest and most distinctive claim (platform-wide) front-loaded. No filler and nothing redundant with 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?

For a single optional-parameter read tool with no output schema, the description adequately conveys what comes back (probability leaders and percentile movers) and the scope of coverage. It does not specify list sizes or ordering, but with annotations covering the safety profile and the schema covering the parameter, this is close to complete.

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

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

Schema coverage is 100% and the single optional limit parameter is fully documented in the schema (default 15, max 40). The description does not mention the parameter at all, so it adds nothing beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource (platform-wide early warning) and enumerates the two concrete outputs: highest calibrated shock probabilities and biggest 90-day percentile movers across all 60 countries. This is specific enough to distinguish it from the country-scoped siblings like get_country_risk and get_supply_chain_risk.

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?

Frames usage clearly as the broad, platform-wide triage question ('what should I be watching?'), which implies it is the entry point before drilling into country-specific tools. It does not explicitly name an alternative or state when not to use it, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the description earns credit for adding real behavioral context: a 2-day re-scoring cadence and exactly which derived fields accompany each forecast (probability history, change since filing/last review, review rationale). It stops short of mentioning auth, rate limits, or result-size 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, front-loaded on what the resource is, then the archive modifier. The first sentence is dense but every clause carries information; 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?

No output schema exists, so the description must explain return values — and it does well, enumerating the per-forecast fields and the archive variant. Gaps are minor: no pagination, sorting, or result-cap behavior, which an agent might need for a large question 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 coverage is 100%, so the schema already documents category, movers_only and include_archive. The description restates the archive semantics ('closed questions (resolved, past-horizon and retired) with their full trajectories') with only marginal added value beyond the schema text, so baseline 3 applies.

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

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

The description names a specific resource ('NERAI's open calibrated forecasts — binary questions with probabilities and horizons') and scopes it across named domains, which is clearly distinct from every sibling (country risk, chokepoint traffic, enforcement precedent). An agent can tell what comes back without opening the schema.

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

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

Usage is implied rather than stated: the description explains what the desk contains and that include_archive surfaces closed questions, which hints at monitoring use. But there is no explicit when-to-use guidance or contrast against siblings like get_early_warning or get_country_risk.

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 cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), and the description adds genuinely useful behavior beyond them: the data is from licensed sources, AIS counts are unavailable with available=false and null counts, and the metric is vessels-present-in-radar-scenes over a 30-day rolling window versus a 2025 same-orbit baseline. It does not state auth requirements or rate limits, keeping it short of a 5.

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

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

Front-loaded with the most decision-relevant fact (live counts unavailable) and compact at three sentences. The middle sentence is dense and slightly hard to parse ('carries Copernicus Sentinel-1 radar vessel presence (30-day rolling, % vs the 2025 same-orbit baseline)'), which costs it a point.

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 no-argument read tool with no output schema, the description supplies the essentials: the null/available flag semantics and the definition of the one published metric. It leaves minor ambiguity about whether other chokepoints exist but are unpublished ('Where published...'), which keeps it just under 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?

Zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to clarify. No param-level information is needed or missing.

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 concrete resource (chokepoint vessel picture) and specifies the one populated dataset (Strait of Hormuz, Copernicus Sentinel-1 radar vessel presence). It is distinguishable from siblings like get_maritime_corridors, though the opening phrase 'chokepoint vessel picture' is loose and the negative framing ('live counts NOT available') competes with the actual purpose.

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 signals a when-not condition ('Live AIS vessel counts are NOT available in this edition'), which steers the agent away from expecting live transit counts. However, it names no alternative tool and gives no positive guidance on when this tool is the right choice versus get_maritime_corridors or get_supply_chain_risk.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive safety, so the bar is lower. The description still adds real behavioral value beyond them: it discloses data provenance (GDELT-based scoring) and, importantly, that transit and cost-pressure fields are retained for compatibility but are null in this edition — a caveat an agent would otherwise misread as missing 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?

One dense sentence that front-loads the resource and its fixed coverage, then the returned field families, then the null-field caveat. Every clause carries information; there is no filler or 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?

There is no output schema, so the description must carry the return shape, and it does: threat/activity scores, phase, news and sanctions intensity, NERAI read, plus the explicit null caveat for legacy fields. It stops short of stating units, scale, or freshness/cadence, which an agent consuming risk scores would benefit from.

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?

Zero parameters, so the baseline is 4; there is nothing to mis-specify. The description correctly implies a fixed, non-parameterized snapshot of all monitored corridors rather than a filterable query.

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 and resource with an enumerated scope: it names all 8 monitored corridors (Hormuz, Suez, Red Sea/Bab-el-Mandeb, Black Sea, Malacca, Taiwan Strait, E. Mediterranean, South China Sea) and the field families returned. It does not explicitly differentiate itself from close siblings such as get_live_chokepoint_traffic or get_circumvention_corridors, so an agent must infer the split from content alone.

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

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

The description states what the tool returns but gives no when-to-use guidance, no prerequisites, and no routing to alternatives, even though the sibling list contains an obviously adjacent tool (get_live_chokepoint_traffic). The use case is only implicit in the resource name.

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

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

Annotations already declare read-only, idempotent, non-open-world, non-destructive, so the description needn't restate safety. It adds the behavioral shape of the call, that it's an aggregate combining four distinct datasets, which is useful context. It does not mention whether results are cached/stale, rate limits, or the response layout.

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, zero waste, and the four data components are listed compactly. It is exactly the length the content needs.

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

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

No output schema exists, so the agent must decide whether the four listed components are sufficient. The four components are named, but their shape (counts vs. scores vs. action records) is only hinted at. Given the tool returns a multi-dataset panel, the description should say more about the shape of each component.

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

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

With zero parameters, the baseline is 4. The description signals there is nothing to filter or scope: it's a fixed overview bundle, which matches the empty 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 gives a precise verb and resource ('sanctions picture in one call') and enumerates the returned content: register counts by list and type, shadow-fleet index, economic-impact measures, recent actions. It's distinguishable from adjacent siblings like find_enforcement_precedent and check_commodity_controls, but it does not explicitly name any sibling it might be confused with.

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

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

Implied usage is clear: this is a bundled overview, so an agent reaches for it when it wants a broad snapshot rather than a targeted query. No explicit when/when-not guidance or named alternatives are supplied, so the agent must infer from the sibling names which to pick for detail.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered, and the description adds real context beyond that: it discloses that GSCPI carries a 'required notice' (an attribution obligation) and that the chokepoint_transits field is null in this edition. It still does not characterize response format or size, but the payload-composition disclosure is genuinely useful.

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 no filler, front-loaded on what the response contains, followed by the single exclusion that an agent most needs. Every clause carries informational weight.

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 must carry the return-value burden, and it does list the three component boards plus one known null field. It stops short of describing the shape of those boards or the notice's exact requirement, leaving a small gap for a no-argument tool whose output is the entire deliverable.

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 no parameter semantics for the description to add; with no arguments the baseline is a 4. Nothing in the text contradicts or confuses the empty 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 gives a specific verb-less but clear retrieval scope: a composite 'global supply-chain picture' bundling NY Fed GSCPI, country disruption readings, and NERAI's supply-disruption forecast board. It distinguishes itself from the chokepoint-focused siblings by explicitly excluding chokepoint transit series, though it does not differentiate from get_forecast_desk or get_country_risk by name.

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

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

It implies usage (fetch the global picture) and provides a negative boundary by stating chokepoint_transits is null and not included, which nudges the agent toward get_live_chokepoint_traffic. However, it never says when to choose this tool over get_forecast_desk, get_country_risk, or get_early_warning, so routing guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds that each record carries a legal instrument and source link, which is useful return-content context, but says nothing about update cadence, whether 'latest' is real-time or cached, or how limit interacts with the feed.

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 core noun phrase leads and the source detail follows. It is dense but every clause (sources, diff type, legal instrument, source link) carries information an agent can use.

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 two-parameter, zero-required, read-only feed tool with full schema coverage and annotations covering the safety profile, the description is largely sufficient. The one remaining gap is freshness/cadence semantics around 'latest', which matters for a change-tracking tool but is not fatal.

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%: both 'limit' (default 10, max 25) and the optional 'jurisdiction' filter (UK/US/EU) are fully documented in the schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description names the specific resource and data sources (UK Sanctions List, US CSL diffs, CELEX-anchored EU Official Journal acts) and the provenance ('NERAI TradeControl Action Desk'), which is far more concrete than a generic 'get changes'. It implicitly distinguishes itself from the sibling get_sanctions_overview by emphasizing deltas/updates, but never names that alternative explicitly, 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?

There is no when-to-use, when-not-to-use, or alternative-selection guidance. The agent must infer from the phrase 'latest ... changes' that this is the tool for recent regulatory deltas rather than standing overviews or country risk, and the crowded sibling list makes that inference risky.

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 establish readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful context that some checks 'require the platform rather than this connector' – i.e. it discloses a capability boundary – but says nothing about response shape, freshness, or cost, which would matter for a status/coverage endpoint.

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 listing coverage areas followed by a one-line usage hint. Front-loaded with the main concept, no filler. Slightly cluttered with proper nouns (NERAI, CHPL) that an agent may not know, but length is appropriate for a no-arg status tool.

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 no-input read-only status tool this is nearly adequate: it names the coverage dimensions. But with no output schema, the description leaves the agent guessing the actual return structure and whether the 'platform vs connector' distinction maps to returned fields. It says what is covered but not how to read the result.

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

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

There are zero parameters, so the baseline is 4; there is nothing to misinterpret and no parameter semantics to compensate for. The description correctly does not waste words on inputs.

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 (coverage status of the transaction intelligence layer) and enumerates the contents: register size, per-source health, enforcement corpus size by authority, CHPL vintage, and platform-only checks. That is clear, though it never says in a verb-first way what action the tool performs (report/return) and does not name a sibling it is distinguished from.

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?

'Use it to know what a full assessment would add' implies a prospective/coverage-check usage, but gives no explicit when-to-use vs. when-not, no prerequisite, and no reference to any of the 15 sibling tools such as check_commodity_controls or get_sanctions_overview. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the result is a fixed set of 60 countries with code+name plus platform metadata (as-of dates, calibration), which tells the agent this is a static reference payload with freshness metadata.

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 sentence, front-loaded with the core scope (60 countries, code + name) and the secondary metadata trailing after. No filler, no restating 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?

There is no output schema, so the description carries the return-value burden and does so partially by naming the payload (code + name) and metadata (as-of dates, calibration). For a zero-parameter reference list this is nearly complete, with only the exact response shape left unspecified.

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 no parameter syntax to explain; baseline for a parameterless tool is 4. The description correctly implies no filtering input is required, though it doesn't state whether the list can be narrowed.

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

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

The description states a specific verb (List) and resource (countries) and bounds the scope precisely: 'the 60 countries covered by NERAI's daily risk indices (code + name)'. It is clearly a reference/enumeration tool rather than a per-country risk lookup, so an agent can distinguish it from get_country_risk or compare_countries without opening a schema, 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: the description tells the agent this is the coverage/code list, which suggests calling it to discover valid country codes before invoking risk tools, but it never says when to use it versus siblings or what it should not be used for (e.g. it returns no risk values). Adequate but with a clear gap.

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