Scrutica

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

With no annotations provided, the description carries full burden. It discloses that outputs are estimated with bounds, but does not mention authentication, rate limits, error handling, or behavior for non-BF16 precisions.

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 concise with two sentences and a warning, front-loading the purpose. The URL adds minor overhead but is relevant context.

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 description adequately states purpose and usage caution, but lacks details on output structure beyond 'point estimate + bounds' and does not clarify behavior for precision choices beyond BF16.

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%, above 50% baseline. The description adds no additional parameter-level meaning beyond what the schema already provides, earning a neutral score.

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, returning point estimates plus bounds. It is distinct from sibling tools which retrieve static data like companies or facilities.

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 warns not to present outputs as exact measurements, but lacks explicit guidance on when to use this tool vs alternatives or when not to use it.

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

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

No annotations are provided, so the description bears the full burden. It discloses the operation (fetch) and lists key return fields (legal name, country of HQ, etc.), implying a read-only action. However, it does not explicitly state that the tool does not modify data or mention any potential side effects. Given the 'get' verb, this is still fairly transparent.

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 consists of three short sentences, each serving a distinct purpose: function + scope, return fields, usage guidelines. No redundant or unnecessary words, and the key 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 simple tool with one required parameter and no output schema, the description fully covers what the tool does, what it returns, and how it relates to sibling tools. The listed return fields compensate for the absence of an output schema adequately.

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% with a well-described 'company_id' parameter (including examples). The description repeats the parameter's purpose ('by canonical Scrutica ID') but adds no new semantic value beyond what the schema already provides, 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?

The description specifies 'Fetch complete details for a single organization' with clear scope (company, government entity, holding company) and method (by canonical Scrutica ID). It distinguishes itself from sibling tools by listing return fields and pointing to alternatives for related queries.

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 guides the agent: 'Use scrutica_query_export_controls for BIS designation details. Use scrutica_get_supply_chain for full edge graphs.' This provides clear when-to-use and when-not-to-use context.

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 compensate. It details the return data but does not mention any side effects, auth needs, or rate limits. Since it's a read-only operation, the transparency is adequate but not exhaustive.

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 wasted words. First sentence clearly states purpose, second lists returns and a usage hint. Extremely efficient and well-organized.

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

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

For a simple one-parameter tool with no output schema, the description adequately describes what data is returned and how to obtain the ID. It references the sibling search tool, making the context 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?

Input schema covers the single parameter with 100% description coverage. The description adds a concrete example of the ID format ('epoch-dc-001') and links to the search tool, providing extra context 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?

The description clearly states the tool fetches complete details for a single facility by canonical ID. It lists specific return fields, distinguishing it from sibling tools like scrutica_search.

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 advises to resolve facility IDs first via scrutica_search, providing clear guidance on when to use this tool and mentioning a prerequisite 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?

No annotations are provided, so the description carries full burden. It explains the tool returns a URL, anchor, and summary, which is basic behavioral info. No mention of destructive actions, auth, or side effects, which seems appropriate for a read-only documentation retrieval 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 three sentences, is front-loaded with the purpose, and every sentence adds value. No wasted words.

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 a single parameter with enums, no output schema, and no annotations, the description covers purpose, parameter topic, usage hint, and return format. It is complete for the tool's simplicity.

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 one parameter (topic) with an enum. Schema description coverage is 0%, but the description lists and contextualizes the enum values by stating they are topics for methodology. It adds meaning beyond the raw enum by providing context.

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 methodology documentation for a Scrutica metric or index, lists specific topics, and describes the return format (URL + anchor + summary). This is specific and distinguishes it from sibling tools.

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 explicitly says 'Use this when a user asks how did you calculate X', providing clear when-to-use guidance. It does not explicitly state when not to use, but siblings are sufficiently different to imply the context.

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, so description carries full burden. It describes the return contents (summary, assumptions, facilities, timeline, citations), implying a read-only operation. Lacks explicit safety or side-effect notes, but adequate for a 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 sentences, first states purpose, second lists scenarios and return structure. No extraneous information; 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?

Complete for a simple lookup tool with one parameter and no output schema. Covers available scenarios and return elements. Could mention response format or limitations, but not necessary.

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?

Adds meaning to the enum values beyond the schema by explaining what each scenario represents (e.g., 'taiwan-strait': 4 TSMC disruption scenarios). Semantics are enriched for the single 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?

Clearly states it fetches geopolitical compute risk scenarios and lists available scenarios. Distinguishes from sibling tools which focus on other entities (companies, facilities, sovereign programs, supply chains, export controls, search).

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 context on when to use: when needing a predefined scenario summary. Does not explicitly state when not to use or name alternatives, but the sibling list implicitly clarifies differentiation.

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

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

With no annotations provided, the description discloses the fetch operation and return fields but lacks details on safety (e.g., idempotency), authentication needs, rate limits, or error handling. The description is adequate but not thorough.

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 concise, consisting of two sentences that clearly convey purpose and key behavior. No redundant or extraneous information.

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

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

Given no output schema, the description compensates by listing return fields. However, it does not address edge cases like non-existent programs or error states. For a data retrieval tool with multiple parameters, it is reasonably complete but leaves minor 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 coverage is 100%, so parameters are already documented in the input schema. The description adds value by listing the return fields for a single record, which is not in the schema, and explaining the list_all parameter's effect. This provides context beyond schema definitions.

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 clearly states the specific verb ('Fetch') and resource ('national sovereign AI compute program') with detailed return fields. It differentiates from siblings by focusing on sovereign programs, distinct from other scrutica_get_* tools for companies or facilities.

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

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

No explicit guidance on when to use this tool versus alternatives like scrutica_get_company or scrutica_get_facility. The description implies use for sovereign program data but does not provide when-not or alternative scenarios.

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 details the direction options, each edge's fields (source, target, relationship type, supply share, price correlation, data source), and the dataset size and sources. This provides good transparency into the tool's behavior, though it omits mention of read-only nature or potential rate 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?

The description is concise, with each sentence adding value: it states purpose, explains direction, lists output fields, and gives dataset context. It could be slightly more structured (e.g., bullet points), but it remains 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 absence of an output schema, the description explains return fields thoroughly. It also provides dataset source and scale. However, it does not clarify the effect of the limit parameter or pagination, which is a minor gap for a tool with 3 parameters and no output schema.

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%), but the description adds value by explaining each enum value for the direction parameter. However, it does not elaborate on the limit or org_ids parameters beyond what the schema provides (e.g., example in schema). The explanation of direction is helpful but not sufficient to fully compensate for the lack of param 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 clearly states the tool returns supply-chain relationships for organizations, specifying direction options and output fields. It is distinct from sibling tools like scrutica_get_company or scrutica_search, which cover different aspects of Scrutica 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 implies usage for retrieving supply-chain relationships but does not explicitly state when to use this tool over alternatives or provide exclusionary criteria. No guidance on prerequisites or limitations.

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 responsibility for behavioral transparency. It explains that the tool uses fuzzy matching on entity_name, returns specific fields, and notes the data source authority tier. This adds valuable context beyond the schema, though it lacks details on rate limits or error handling.

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 three sentences, each adding essential information: purpose, matching and return fields, and authority tier. It is front-loaded and concise without any superfluous content.

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 annotations and output schema, the description covers key aspects: queried lists, matching method, return fields, and data source tiering. It could mention the limit parameter and optional country, but overall it provides sufficient context for a 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?

The input schema already provides descriptions for 3 of 4 parameters (75% coverage). The description only reinforces the fuzzy matching for entity_name, not adding new semantic meaning beyond the schema. 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?

The description clearly states the tool's purpose: looking up export control designations from BIS Entity List, OFAC SDN, and Wassenaar Arrangement CCL. It specifies the verb 'look up' and the resource 'export control designations for companies or countries', distinguishing it from sibling tools like `scrutica_search` 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 implies usage for export control lookups and explains the fuzzy matching behavior, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is clear enough for most use cases.

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

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

With no annotations provided, the description carries the burden but only describes basic search behavior. It does not cover potential behavioral aspects like rate limits, auth requirements, or performance implications. However, for a read-only search tool, the description 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?

The description is concise, with three sentences that front-load the main purpose and use bullet points for clear directives. Every sentence adds value without waste.

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 4 parameters and no output schema, the description covers the return fields and provides usage context. It lacks explicit mention of the limit parameter, but overall it is sufficiently complete for a search 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?

The description adds meaning to the entity_type and country parameters beyond the schema by stating their purpose (scoping to a single class, filtering by ISO code). With 75% schema coverage, the description compensates for undocumented parameters.

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 the tool searches facilities, companies, or sovereign programs by free-text query, and returns specific fields. It also distinguishes itself from sibling tools like scrutica_query_export_controls and scrutica_get_supply_chain, making the purpose very clear.

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 provides explicit guidance on when to use and when not to use the tool, including alternatives for export-control lookups and supply-chain traversal. It also explains filtering options by entity_type and country code.

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