Scrutica

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

With no annotations, description handles the burden. It discloses methodology reference and warns against presenting as exact measurements. However, it misses behavioral traits like whether it's read-only or any side effects, though likely safe.

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 sentences: first states purpose, second states return type, third gives crucial usage warning. Front-loaded, no redundancy, every sentence adds value.

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

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

Given no output schema, description only mentions 'point estimate + bounds' without details on structure. Parameter guidance is adequate but could specify expected patterns. Overall decent but gaps remain.

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 60% (3 of 5 parameters described). The description does not add explanation beyond schema for sparsity and precision, but mentions 'BF16' which aligns with precision param. Baseline 3 is appropriate as schema does partial work.

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

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

The description clearly states the tool computes peak BF16 FLOP estimates for hardware configurations, using specific verb 'Compute' and resource 'peak BF16 FLOP estimates'. It differentiates from sibling tools which are about companies, facilities, etc., making purpose distinct.

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

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

Provides explicit guidance on how to present outputs ('always relay the bounds and the is_estimated flag') and references methodology. While it doesn't explicitly state when to use vs alternatives, the context is clear enough given no similar sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read operation (fetch) and lists the return fields, implying no destructive side effects. However, it does not explicitly state safety (e.g., 'read-only') or mention any required permissions, which would elevate it to 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?

Three sentences with no filler. First sentence clearly states purpose and content, second lists return fields, third provides alternative tools. Highly efficient and front-loaded.

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

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

Given the tool's simplicity (single parameter, well-documented schema, no output schema but return fields listed), the description is complete. It covers what the tool does, its inputs, outputs, and how it relates to siblings. No gaps.

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 already provides a thorough description (format, resolution instructions) for the sole parameter. Schema coverage is 100%, so baseline is 3. The description adds no additional parameter detail beyond what is in 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?

Clearly states the verb 'Fetch' and resource 'organization' (company, government entity, holding company) by canonical ID. Lists specific return fields. Distinguishes from siblings by explicitly mentioning alternatives like scrutica_query_export_controls and scrutica_get_supply_chain.

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

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

Explicitly tells when to use alternatives: use scrutica_query_export_controls for BIS details, scrutica_get_supply_chain for edge graphs. Also, the input schema description advises to resolve ID via scrutica_search first, providing clear when-not guidelines.

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

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

No annotations provided, but description lists returned fields comprehensively (operator, owner, country, power capacity, etc.). Implies read-only retrieval; does not disclose potential errors or rate limits, but that is acceptable for a simple fetch 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?

Two precise sentences plus a clear bullet list of return items. No wasted words 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?

Given one parameter, full schema coverage, and no output schema, the description fully covers how to invoke the tool (resolve ID first) and what it returns. No gaps.

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 covers the single parameter with 100% description coverage. Description adds critical guidance: 'Resolve via scrutica_search first — do NOT guess slugs,' which adds significant value beyond the schema.

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

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

Clearly states 'Fetch complete details for a single Scrutica facility by canonical ID' – specific verb and resource. Distinguishes from siblings like scrutica_search by noting the need to resolve IDs first.

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

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

Explicitly instructs to resolve facility IDs via scrutica_search first and warns against guessing slugs. Provides clear when-to-use and when-not-to-use guidance.

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

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

No annotations provided, but the description implies a read-only lookup operation. It discloses that it returns documentation (URL, anchor, summary) and lists accepted topics. It does not mention any side effects, errors, or auth requirements, but for a simple retrieval tool, this is adequate.

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: first states purpose, second lists topics and return format, and ends with a clear usage hint. Highly efficient with no fluff.

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 (one enum parameter, no nested objects, no output schema), the description covers purpose, parameters, output, and usage context thoroughly. No gaps.

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%, but the description explicitly lists all enum values for the 'topic' parameter, providing context beyond the schema. It also clarifies the return format, adding meaning. The single parameter is well explained.

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

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

The description clearly states it returns methodology documentation for a Scrutica metric or index, lists all possible topics, and specifies the return format (URL + section anchor + summary). It distinguishes from sibling tools which retrieve entities, not documentation.

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

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

Explicitly states when to use: when a user asks 'how did you calculate X'. While no explicit when-not-to-use or alternatives are given, the sibling tools are obviously different, so the context is clear enough.

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 full burden. It states 'Fetch' indicating a read operation and describes the output structure (assumptions, affected facilities, etc.). However, it does not disclose potential side effects, idempotency, or rate limits, which are minor for a simple fetch tool.

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

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

The description is two sentences: the first states the purpose, the second lists scenarios and output. No wasted words. The most important information is front-loaded.

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

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

For a tool with one parameter and no output schema, the description covers the input options and output structure well. It lacks error handling or pagination details, but these are not critical for a simple fetch scenario.

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 explains each enum value (e.g., 'taiwan-strait' -> '4 TSMC disruption scenarios'), adding meaning beyond the bare enum list. This provides rich context for input selection.

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 'Fetch geopolitical compute risk scenarios,' clearly stating the verb and resource. It then lists all available scenario IDs with brief explanations, distinguishing this tool from siblings like 'scrutica_get_company' which fetch different entities.

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 listing available scenarios but does not explicitly guide when to use this tool over alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the sibling tool names.

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

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

No annotations are provided, so the description must convey behavioral traits. It lists return fields and notes that list_all returns a summary table, implying a read-only operation. However, it does not disclose authentication needs, rate limits, or whether the tool has any side effects, which is a gap for transparency.

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

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

The description is two sentences with no redundant information. It front-loads the action and resource, followed by a succinct list of return fields and a note on list_all. Every sentence 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?

Given the lack of an output schema, the description provides a detailed list of return fields, which is helpful. However, it does not specify the exact data type (e.g., object vs. array) for single fetch or list_all, nor any pagination or error handling. Still, it is largely complete for the tool's complexity.

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

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

The input schema has 100% coverage with descriptions for all three parameters. The description adds value by explaining the return values and the dual mode (single vs. list_all), which aids understanding beyond the schema. However, it does not elaborate on parameter constraints beyond 'ISO 3166-1 alpha-2' for country.

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

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

The description explicitly states 'Fetch detailed data on a national sovereign AI compute program,' providing a clear verb and resource. It distinguishes between fetching a single program and using 'list_all' for a summary table, which differentiates the tool from siblings like 'scrutica_estimate_flops' or 'scrutica_get_company'.

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 explains two usage modes: fetching a specific program (via country or program_id) or listing all programs for comparison. While it does not explicitly state when not to use or mention alternatives among siblings, the context of 'for cross-country comparison' provides clear guidance on when to use the list_all option.

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

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

No annotations provided, but the description discloses data sources (licensed database, SEC Exhibit 21), subscription restrictions, and output fields like supply_share and price_correlation_3m. This provides useful behavioral context beyond the 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?

The description is two well-structured sentences. It front-loads the purpose, then details direction and fields, and ends with dataset statistics. Every sentence adds value with 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?

Although no output schema exists, the description explains return fields and provides dataset size and sources. Pagination is covered by the limit parameter in the schema. It lacks error handling or rate limit info, but is sufficient for a data retrieval 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 low (33%), so the description carries burden. It clarifies the direction parameter's enum values ('upstream', 'downstream', 'both') and describes output fields. However, it adds minimal detail for the limit and org_ids parameters beyond what the schema provides.

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

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

The description clearly states the tool returns supply-chain relationships for organizations, with directional options (upstream, downstream, both). It distinguishes from sibling tools like scrutica_get_company which return different entity data.

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 explains directional options but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Usage context is implied rather than explicit.

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 full burden. It discloses behavioral details: fuzzy matching, returned fields (designation_date, jurisdiction, control_reason, source_url), and authority tier (Tier 1). It does not explicitly state that the operation is read-only, but the querying nature makes it obvious.

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 sentences, front-loaded with main purpose. The second sentence details matching and return fields, the third adds authority tier. No redundant or filler content; every sentence 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 output schema exists, but the description lists four return fields and the source type. It explains the matching behavior and covers the main query aspects. It does not mention that all parameters are optional or the effect of the limit parameter, but for a simple query tool, the description is sufficiently 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 description coverage is 75% (3 of 4 parameters have descriptions). The description adds value by explaining how entity_name is used ('fuzzy matches...against organization_aliases'), which is more specific than the schema description. It also implies the return format, but does not detail each parameter's role.

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

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

The description clearly states it 'looks up' specific export control lists (BIS Entity List, OFAC SDN, Wassenaar CCL) for companies or countries. This distinguishes it from sibling tools like 'scrutica_search' or 'scrutica_get_company', as none of them directly query these designations.

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

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

The description mentions fuzzy matching on entity_name, implying when to use it (to check a company/country against export control lists). However, it does not explicitly state when not to use it or provide alternative tools. Since no sibling tool serves the same purpose, the implied usage is clear.

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 present, so description shoulders the burden. Discloses return fields (id, name, type, summary, URL) and filtering options. Does not explicitly state read-only, but search is implied safe. Lacks mention of pagination or rate limits, but adequate.

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?

Four sentences, front-loaded with purpose. Every sentence adds value: what it does, what it returns, filtering, and exclusions. No redundancy or fluff.

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 search tool with 4 parameters and no output schema, the description covers all essential aspects: what is searched, return fields, filtering, and when to avoid. Complete enough for an AI agent to invoke 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 coverage is 75%, and description adds context: 'Filter by entity_type to scope to a single class' and 'Filter by ISO 3166-1 alpha-2 country code'. Describes output format, which compensates for missing output 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?

Clear verb+resource: 'Search facilities, companies, or sovereign programs'. Distinguishes from siblings by naming alternatives (scrutica_query_export_controls, scrutica_get_supply_chain).

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

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

Explicitly states when NOT to use (BIS Entity List, supply-chain traversal) and provides correct alternative tools. Also gives filtering advice (by entity_type, country).

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