NarcoScope — illicit-economy evidence atlas

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds further behavioral context: output includes source metadata and native caveats, missing data is explicit null, pagination uses stable cursors, and records never identify people or operational locations. This goes beyond the annotations and does not contradict them.

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

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

Two sentences with no filler. The first sentence front-loads the return scope and key output traits; the second adds a single high-value privacy constraint.

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 five-parameter read-only query with an output schema present, this description covers the resource scope, output traits, pagination, and privacy boundary, which is enough to invoke correctly. It omits alternative-tool routing, but that is already scored under usage guidelines and is not required to call this 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%, so the description must compensate. It maps 'country-year' to iso3/year, names the two domain values, and implies cursor/limit via 'stable cursor pagination'. However, it does not explain limit bounds, cursor format, or the 'all' domain option, leaving the schema's patterns, defaults, and enums to carry much of the parameter-meaning burden.

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?

Description opens with a specific verb ('Return') and a precise resource: country-year organized-crime and firearms-tracing observations. It adds distinctive detail—source metadata, native caveats, explicit null fields, stable cursor pagination, and a privacy boundary—that separates it from siblings like get_entities or get_overview.

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 gives clear context for when to use the tool: when country-year organized-crime or firearms-tracing observations are needed. It also states an implicit when-not ('No records identify people or operational locations'), but does not name an alternative sibling tool or provide explicit routing conditions.

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?

Beyond the read-only/destructive annotations, the description discloses that this is a limited data view ('approved public designation identity fields only') and explicitly lists withheld categories: aliases, addresses, dates of birth, identity documents, and allegation text. It also adds important context that a designation is not an adjudication or proof of guilt.

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 front-loaded sentences with no filler. The core behavior is stated first, and the withheld-field detail earns its place by setting expectations for the response.

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 and annotations cover return format and safety, and the description clarifies data limitations. But with six undocumented parameters and no guidance on filtering or pagination, the definition is not fully complete for an agent deciding how to invoke it 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%, so the description needed to explain the six parameters. It does not: query, limit, cursor, country, program, and entity_type are all undocumented, and opaque enum values such as 'SDNTK' and 'ILLICIT-DRUGS-EO14059' are left 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 starts with a specific verb and resource: 'Return approved public designation identity fields only.' It clearly identifies the domain (OFAC designation identities) and distinguishes the tool from siblings by subject matter, even without naming 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?

There is an implied use case: when an agent needs public OFAC designation identity fields rather than full records. However, the description does not explicitly state when to use this tool over siblings, nor does it mention exclusions or alternative tools.

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

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

Annotations already establish readOnly/destructive safety, and the description adds meaningful behavior: results are bounded, public, and free of inference/cross-lane synthesis, and upstream unavailability is preserved as typed rather than collapsed. This goes beyond the structured metadata without contradicting it.

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

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

Two tight sentences earn their place: the first states scope and exclusions, the second a key error/availability behavior. No filler or repetition of schema details.

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 a rich output schema, safe annotations, and a single optional enum parameter, the description covers purpose, boundaries, and an important upstream-availability behavior. It is missing only explicit lane-parameter semantics and sibling routing, so it is near-complete but not exhaustive.

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 prose needed to explain the lane parameter, but it never mentions 'lane', 'all', 'seiche-summary', or the palimpsest/seiche enum values. The domain labels in the description only indirectly map to enum values, leaving parameter selection semantics mostly to the schema.

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

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

The description opens with a specific verb and resource ('Return bounded public ... context') and clearly defines the tool's lane-scoped read purpose: separate Seiche and Palimpsest evidence without cross-lane scoring or inference. This distinguishes it from synthesis-oriented siblings while matching the title's 'separate evidence lanes' framing.

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 gives an explicit negative usage rule ('without cross-lane scoring, composites, causal inference, or culpability inference'), making clear when this tool is not appropriate. It does not name alternative tools or positive when-to-use conditions, 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful contextual detail about what the newsroom contains, such as citations, correction metadata, publication gates, and evidence limits, but it does not explain behaviors like ordering, pagination, or what 'publication gates' mean in practice.

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 sentence that front-loads the action and resource, then packs the relevant details into a compact list. There is no fluff or redundancy.

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 list operation with one simple optional parameter, an output schema, and readOnly annotations, the description is fairly complete. It names the content domain and the key metadata categories. It could be stronger with sibling guidance, but that is already captured under usage guidelines.

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 the description never mentions the 'limit' parameter. The schema itself provides type, default, min, and max constraints, but the description adds no semantic meaning about how the limit affects the returned list, so it does not compensate for the missing schema descriptions.

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

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

The description uses a specific verb ('List') and a specific resource ('current deterministic analyses'), and enumerates the kinds of metadata returned. It is clear what the tool does, though it does not explicitly differentiate it from sibling tools like get_story or get_overview.

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

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

The description gives no explicit guidance on when to use this tool versus its siblings, nor any exclusions or conditions. The word 'current' implies a recency filter, but there is no actionable direction about choosing this over get_overview or get_palimpsest_bridge.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safe read-only nature is covered. The description adds the useful behavioral note that aggregates are 'bounded' and 'headline', implying a curted summary rather than exhaustive data, but it does not describe pagination, rate limits, or other runtime behavior.

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

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

The description is a single sentence, front-loaded with the core action and scope, and every phrase adds meaning by listing the specific data domains included. There is no redundancy.

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

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

For a zero-parameter overview tool with an output schema present, the description is sufficient: it names the data domains and the bounded/headline nature of the aggregate, while the output schema supplies the exact return structure. No critical information is missing for an agent to invoke it 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?

The input schema has zero parameters. Since there are no parameters to document, the description does not need to add parameter semantics, and the baseline of 4 applies.

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

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

The description uses a specific verb ('Return') with a concrete resource ('headline aggregates across official prices, seizures, overdose mortality, wastewater, and public designations'). It clearly identifies what the tool provides and is distinguishable from the sibling tools by focusing on the official-data overview domain.

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

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

Usage context is implied: an agent would use this when it needs a bounded official-data overview, not when it needs newsroom content, story details, or palimpsest context. However, the description does not explicitly state when to prefer it over alternatives or mention any 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 readOnlyHint and openWorldHint, but the description adds a meaningful behavioral boundary: it explicitly forbids cross-lane drug, actor, route, guilt, political, project, causal, tactical, and navigable inference or use. This is valuable context beyond the structured annotations, clarifying the tool's limited analytical scope.

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

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

Two sentences with no filler. The main action is front-loaded, and the second sentence crisply adds the key restriction. Every word earns its place.

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

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

For a parameterless read tool with an output schema defined, the description fully covers purpose, scope, and the critical behavioral constraint. There is nothing an agent needs to know to invoke it correctly that is missing.

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

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

The tool has zero parameters, so the schema fully covers the interface. Per the baseline for parameterless tools, a score of 4 is appropriate; no further parameter explanation is needed.

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

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

The description clearly states the verb 'return' and the specific resource: pinned source readiness and national WDI coverage for CPEC, Gwadar, CMEC, Kyaukpyu, and Balochistan. It also frames this as a 'parallel context lane,' which distinguishes its scope from siblings like bridge or corridors.

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 provides a negative guideline—prohibiting cross-lane inference—but never explicitly compares itself to sibling tools or states conditions for when to choose it over them. The usage context is implied but not directly spelled out.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the output includes 'disclosure and causal boundaries', which is more about content than behavior. It does not disclose any other behavioral traits (e.g., pagination, auth requirements, rate limits). Since annotations cover the main concerns and the description adds minimal behavioral context, a 3 is appropriate.

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, well-constructed sentence of 14 words. It front-loads the key information (what is returned) and avoids any filler. Every word earns its place, making it appropriately concise and well-structured.

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

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

Given the tool's simplicity (no parameters) and the presence of an output schema (which the prompt states exempts the description from explaining return values), the description is complete. It clearly states what is returned, and the annotations cover safety. No critical information needed for correct invocation is missing.

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

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

The tool has zero parameters, and schema description coverage is trivially 100% (no parameters to document). The description therefore does not need to add parameter semantics. As per the calibration, 0 params yields a baseline of 4, since there is nothing to explain beyond what the schema already covers.

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

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

The description clearly states a specific verb ('Return') and a well-defined resource ('official-only China aggregate shared with the Intelligence Commons'), and further specifies the content boundaries ('disclosure and causal boundaries'). This distinguishes it from sibling tools like get_palimpsest_bri_context or get_palimpsest_corridors, which presumably cover other aspects.

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 does not explicitly state when to use this tool versus sibling tools, nor does it mention alternatives or exclusions. The intended usage is implied by the resource name, but there is no explicit routing guidance. With a clear context but no exclusions, this fits the 'clear context, no exclusions' level at best, though the lack of explicit comparison suggests score 3.

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 and non-destructive behavior. The description adds meaningful behavioral context by disclosing missing-data, provenance, disclosure, and geography-and-time-only join rules, which go beyond the annotations and help the agent understand what kind of result to expect.

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

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

A single sentence that front-loads the core action and resource, then packs necessary qualifiers into a compact list. No filler or repetition of the title; every word contributes to agent understanding.

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 parameterless read tool with an output schema, the description covers the essential content: what data is returned, for which countries, and under which join/missing-data rules. Nothing critical is missing for an agent to decide whether to call it.

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 and the schema is empty, so parameter detail is not needed. The description does not waste space on parameters and instead focuses on output semantics, which is appropriate for a parameterless read-only tool.

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

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

The description states a specific verb ('Return') and resource ('official country-level China, Pakistan, and Myanmar aggregates'), plus distinctive join and provenance rules. This clearly distinguishes it from siblings like get_palimpsest_bridge and get_palimpsest_bri_context.

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 establishes clear context: this tool is for official country-level corridor aggregates for three specific countries, with particular data-quality and join-rule constraints. It does not explicitly name alternatives or say when not to use it, but the specificity makes the intended use inferable.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds value by disclosing the three return formats, enriching the agent's expectation of the response, though it does not go into detail about what each artifact mode contains. This is adequate but not rich behavioral context beyond the annotations.

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

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

Two sentences with zero filler. The primary action is front-loaded, and the usage tip is appended as the second sentence. Every word earns its place; no redundant phrasing 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?

For a read-only fetch tool with an output schema, this is largely complete: it names the resource, scope, artifact modes, and a recommended default. It does not elaborate on the semantic difference between the three artifact types or document the slug format, but these are minor gaps given the self-explanatory mode names and the presence of an output schema covering return values.

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 explain the 'artifact' parameter's enum by naming its three modes (metadata, machine brief, dossier), adding meaning beyond the bare enum values. However, the required 'slug' parameter has no semantic or example context in either the schema (which only shows a regex pattern) or the description, leaving a gap for the one required parameter.

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

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

States a specific verb (Fetch) and resource (one story), and precisely defines the three artifact modes it returns: metadata, machine brief, or cited dossier. These artifact types clearly separate it from sibling tools like get_newsroom (fetches an entire newsroom), get_overview, and the get_palimpsest_* family, so an agent can distinguish it without opening schemas.

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?

Offers one genuine usage tip — 'Use the machine brief first for agent workflows' — which guides the default artifact choice. However, it gives no when-not-to-use guidance and does not reference alternative tools (e.g., when to call get_newsroom or get_overview instead). The guidance is artifact-level rather than tool-selection-level.

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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating what the capability listing includes, especially 'safety boundaries,' which gives an agent a clearer picture of the tool's informational scope.

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, well-structured sentence that front-loads the verb and resource list. Every element earns its place, and there is no redundant wording.

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

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

For a zero-parameter discovery tool with an output schema and clear sibling context, the description is nearly complete. It could more explicitly frame itself as the capability discovery entry point, but nothing essential is missing for invoking it 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?

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies, and the description adds useful context about what the no-argument call returns.

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 the specific verb 'List' and names the exact scope: evidence explorer, newsroom, API, feeds, MCP tools, audiences, and safety boundaries. This clearly distinguishes it from the sibling get_* tools, which each retrieve a single specific resource.

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

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

The description and title imply this is a discovery/entry-point tool, but it never explicitly states when to use it versus the get_* siblings. There is no direct guidance like 'use this first to see what is available' or mention of alternatives.

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