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

With no annotations provided, the description must carry the full burden. It discloses the output (matching pages with text excerpts) and that no API key is required, which are useful. However, it does not mention pagination behavior, match semantics (e.g., case sensitivity), or potential limitations. It adds some value but lacks depth for a no-annotation tool.

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

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

The description is concise, with each sentence contributing distinct information: purpose, output, prerequisite, uniqueness, and authentication requirement. It is front-loaded with the primary purpose and avoids fluff. Slight redundancy exists (unique feature and no API key are separate but related), but overall it is 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?

For a search tool with no output schema, the description covers the essential context: what it does, what it returns, how to obtain the required publication_id, and availability (no API key). It does not explain all parameters, but the schema covers those. The absence of error-handling or limitation notes is a minor gap, but the description is reasonably complete for its 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?

Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it repeats the publication_id source already present in the schema description. It does not elaborate on the 'domain' parameter or pagination details, which are left to the schema. Therefore, it neither enhances nor detracts from the schema's explanations.

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 function: 'Full-text search inside BPS PDF publications.' It specifies the verb (search), the resource (BPS PDF publications), and the output (matching pages with text excerpts). It also distinguishes from the sibling allstats_search by noting it's a unique feature not available via WebAPI.

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 workflow guidance by instructing users to get publication_id from allstats_search results (deep_search_id field). It also explains that the tool is a unique feature not available via WebAPI, implying it should be used for this specific deep-search capability. However, it does not explicitly state exclusions or contrast with other search alternatives.

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

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

No annotations exist, so the description carries the full burden. It discloses high latency due to proxy/scraping, states no API key is required, and frames it as a fallback due to speed. It doesn't mention rate limits or result structure, but covers the most critical operational constraints relevant for an agent.

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, purpose first, then a clearly marked IMPORTANT caveat. Every clause adds value—no filler or redundant 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 the 8-parameter schema with thorough descriptions and no output schema, the description provides the essential context: scope, content types, latency warning, and relationship to the faster 'search' tool. It doesn't explain return values, but that's not expected without an output schema. Covers operational caveats well, though it could mention potential scraping fragility.

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%, with every parameter having a description. The description adds a high-level mapping by listing content types, but doesn't add new syntax or format details beyond the schema, so the 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 opens with 'Search BPS content via AllStats Search Engine' and enumerates content types (publications, tables, press releases, infographics, microdata, glossary, classifications), clearly identifying the tool's scope. It also differentiates from sibling 'search' by positioning this as a fallback, making the purpose clear and 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?

Explicitly instructs to use the 'search' tool first, stating it is 'much faster', and to only use this tool if 'search' finds no results. This provides clear when-to-use and alternative guidance, leaving no ambiguity about when this tool should be invoked.

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 destructive cache-clearing action but does not disclose side effects such as potential slower subsequent requests or whether the cache is server-wide or session-specific.

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 short sentences with the action front-loaded and no unnecessary words or repetition.

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 tool, the purpose and a use case are covered, but the lack of behavioral detail (e.g., side effects, scope of the cache cleared) leaves some contextual 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 tool has zero parameters, so there is no parameter semantics to add; the baseline of 4 applies since no parameter information 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 states a specific action ('Clear BPS data cache') with a clear resource and verb, and it is immediately distinguishable from sibling data retrieval 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 phrase 'Useful to ensure latest data is fetched directly from the API' gives clear context for when to use the tool, though it does not explicitly name alternatives or exclusion criteria.

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

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

With no annotations, the description carries the full burden. It discloses a key limitation ('only supports comparison for 1 year') and clarifies that multi-year comparisons require a different tool. However, it does not describe the return format or behavior in edge cases (e.g., invalid region names), which would improve 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 concise and front-loaded. It opens with a clear one-sentence purpose, then provides usage guidance, a critical constraint, and relevant examples. 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?

For a tool with moderate complexity (3 parameters, no output schema), the description provides strong contextual coverage: purpose, usage, constraints, and examples. However, it does not describe the response format or error behavior, which is a minor gap given the lack of an 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?

The schema provides 100% coverage of the three parameters, including examples for each. The description does not add further semantic detail beyond the schema, so the baseline score of 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 uses a clear verb 'Compare' and resource 'statistical data across regions', and explicitly distinguishes from siblings by noting it handles single-year comparisons only. The provided examples further clarify the tool's purpose and scope.

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 states when to use the tool ('when the user wants to compare data between 2 or more regions') and provides an explicit alternative for multi-year comparison ('use get_trend per region'). This is clear, actionable 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 exist, so the description carries the full burden. It discloses the automatic pipeline 'detect intent → resolve region → find variable → fetch data' and notes delegation behavior. While it doesn't discuss auth, rate limits, or return format, for a read-only retrieval tool this is reasonable and adds substantial behavioral context.

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 longer than average but exceptionally well-structured with headers, tables, bullet lists, and a front-loaded purpose sentence. Every section serves a distinct role: intent detection, quick reference, strategy, and examples. Minor redundancy exists between Quick Reference and Strategy, but overall it earns its length.

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 complexity (automatic intent detection, delegation logic) and absence of an output schema, the description is quite complete: it covers intent disambiguation, topic mappings, strategic priorities, and examples. It omits an explicit statement of return format or error handling, but the examples and fallback notes ('static table fallback') imply expected outputs. This is a robust description for a primary AI 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% (all three parameters described), so the baseline is 3. The description adds value through concrete examples (query, region, year) and a Quick Reference table that maps common topics to useful var_ids and alternative methods. This enriches the schema definitions without contradicting them.

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 'Primary AI tool: search and retrieve BPS data in one step', establishing a specific verb and resource. It distinguishes itself from siblings by explicitly listing delegation targets (compare_data, get_trend, get_ranking, search), making the tool's scope unambiguous.

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 'Intent Detection' section provides explicit when-to-use and when-not-to-use rules for multiple query types (single value, comparison, trend, ranking, table/breakdown, publication). The 'Strategy' list additionally ranks alternative tools by scenario, giving the agent clear decision criteria.

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 adds useful context by stating that it searches 'across all relevant subjects' and showing domain-filtered examples. However, it does not disclose output format, pagination, or any limitations. For a non-destructive search tool, this is adequate but not rich.

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 well-structured with a one-line purpose, three illustrative examples, and a practical follow-up note. Every sentence earns its place, and the examples are concise and non-redundant. 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?

The description provides scope, usage examples, and a clear next-step workflow, which is sufficient for a search tool with a straightforward interface. It does not specify the full return structure, but since there is no output schema, the mention of 'var_id' gives a key hint. Minor gaps around pagination or result size are acceptable given 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?

The input schema already describes all three parameters (100% coverage), providing a baseline of 3. The description adds value beyond the schema by giving concrete usage examples, clarifying domain codes (e.g., '3500' = East Java), and referencing supporting tools like resolve_domain and list_subjects. This enhances parameter understanding.

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

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

The description opens with a specific verb+resource: 'Search BPS data variables by keyword.' It also adds the scope 'across all relevant subjects' and provides examples that clarify the resource. This differentiates it from siblings like list_variables, which list variables rather than search by keyword.

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 includes a clear follow-up instruction: 'After getting a var_id from this tool, use get_dynamic_data to retrieve the data.' It also gives example calls with domain and keyword usage. However, it does not explicitly mention when to use this tool over related siblings like list_variables or find_data, so it lacks explicit exclusions or alternative 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 are provided, so the description carries the full burden. It discloses the prerequisite behavior (must call list tools first) and clarifies that data is actual census data, not metadata. However, it does not discuss return format, error handling, or size, limiting 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?

Two sentences, front-loaded with the tool's core function followed by a practical prerequisite note. 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 simple data-fetch tool with no output schema, the description provides the essential purpose and required ID sourcing, which is largely sufficient. However, lack of output schema means little is said about the return shape, though the tool name and description imply raw census data.

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% with each parameter description referencing the source list tool. The description adds sequential ordering ('use ... first') that synthesizes the three parameters into a workflow, going beyond individual 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 the specific verb 'Fetch' with the resource 'actual census data' and specifies three dimensions (activity, area, dataset). This clearly distinguishes it from the sibling list_census_* tools, which provide IDs rather than 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 explicitly instructs to use list_census_events, list_census_areas, and list_census_datasets first to obtain required IDs, providing clear step-by-step context. It does not explicitly mention exclusions or alternatives, but the prerequisite guidance is strong.

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

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

With no annotations provided, the description carries the full burden. It clearly indicates this is a lookup operation and states the ID precondition, but it does not disclose the response format, error behavior for invalid IDs, or any access constraints. This is adequate but not rich.

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 primary purpose and a practical usage hint. No wasted words, and the structure prioritizes the most actionable 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?

The tool has only 2 required parameters, no output schema, and a simple lookup purpose. The description covers what the tool does and how to acquire the required ID, which is sufficient for basic invocation. It lacks return value details, but the simplicity of the tool lessens the need for more.

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 parameters have detailed descriptions with examples and enum values. The description adds a reference to 'ID' but does not go beyond the schema in explaining parameter values or interactions. Baseline of 3 is appropriate because 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?

The description uses a specific verb ('Get detailed information') and clearly identifies the resource ('a specific statistical classification entry by its ID'). It also distinguishes itself from the sibling tool list_classifications by indicating this tool retrieves details for one entry, not a list.

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 explicit usage guidance: 'Use list_classifications first to find the ID.' This tells the agent when to use this tool versus the sibling list tool and establishes the prerequisite step for invocation.

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

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

No annotations exist, so the description carries full burden. It discloses that the response includes table content in HTML format, which is helpful context, but it does not mention permissions, error behavior, or whether the HTML is sanitized/rendered. 'Retrieve' implies read-only but adds no further 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 a single, front-loaded sentence that communicates the core action and a key response detail without any filler. 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?

Without an output schema, the description at least discloses that the response contains table content in HTML format. However, 'details' remains vague, and it does not enumerate what other fields are returned. For a simple two-parameter retrieval tool, this is mostly sufficient but could be more explicit.

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% for the two simple parameters. The description does not add additional meaning beyond stating 'single CSA table', which is already implied by the 'id' parameter. The schema already explains the parameters adequately.

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 'Retrieve' and a clear resource 'details of a single CSA table', which distinguishes it from sibling list tools. The parenthetical about HTML content further clarifies the scope of the response.

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 this tool is for fetching one CSA table by ID and domain, but it does not explicitly mention when to use it over list_csa_tables or other retrieval tools. No exclusions or alternative names are provided.

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 burden. It adds context about requiring a specific var_id and lists common variables, but it does not disclose output format, error handling, or read-only nature explicitly. Some transparency is present but not comprehensive.

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 well-structured with a clear purpose, requirement, usage guidance, and a list of common variables. While slightly long, every section contributes useful information, and the bulleted list improves readability.

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

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

Despite lacking an output schema and annotations, the description provides adequate context with usage instructions, examples, and links to discovery tools. It covers the main use case well, though it does not explain return values or all parameters in depth.

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?

Since schema coverage is 100%, baseline is 3. The description adds value by providing concrete examples for var (e.g., 1452 = Population) and clarifying domain='0000' for national data, which enhances parameter understanding beyond the 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 clearly states the tool's function: 'Fetch data from BPS dynamic tables.' It specifies the requirement of a known variable ID and distinguishes itself from related tools like find_data and find_variable by explaining when each should be used.

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?

Explicit guidance is provided: 'Use find_data first for automatic search. Use this tool only if you already know the var_id' and 'Use find_variable to search for other variable IDs.' This clearly indicates when to use this tool versus alternatives.

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 burden of disclosure. It implies a read operation ('get', 'definition') but does not specify behavior for missing IDs, return format, or any access requirements. For a simple lookup this is marginal but acceptable.

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 concise sentences, front-loaded with the main purpose, and a direct pointer to a sibling tool. 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?

The tool is simple with one parameter and no output schema. The description conveys the core action and input source, which is sufficient for understanding how to use it. It doesn't promise return structure, which is acceptable given the straightforward nature.

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 fully describes the id parameter, including its source ('from list_glossary'). The description adds 'by its ID' which is redundant. With 100% schema coverage, 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 function: retrieving a detailed definition for a specific glossary term by ID. It distinguishes itself from list_glossary, which is about listing terms, and names the exact resource and action.

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 explicitly instructs to use list_glossary to find term IDs, providing a clear prerequisite and directing the user to the appropriate sibling tool for discovery. This is actionable guidance for when to use this tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the response includes a full description and download link, which is useful, but it does not mention any prerequisites (e.g., requiring a valid domain) or potential error states. For a simple read operation this is adequate but not rich.

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, concise, front-loaded sentence that directly states the purpose and key output components. No filler or redundant information is present.

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 get-by-id tool with a clear output description, the description is nearly complete. It could optionally hint at using list_infographics to discover valid IDs or mention behavior for invalid IDs, but given the tool's simplicity, it adequately covers the core context.

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?

Both parameters (id and domain) already have clear descriptions in the schema, providing 100% schema coverage. The tool description adds no additional parameter-level meaning beyond what the schema provides, so a baseline score of 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 action ('Retrieve') and the resource ('details of a single BPS infographic'), including what is returned (full description and download link). This distinguishes it from sibling tools like list_infographics, which enumerates multiple items.

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

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

The phrase 'single BPS infographic' implies this is for a specific item lookup, given an id and domain. However, it does not explicitly mention when to use list_infographics to first find the infographic, or contrast with other retrieval tools like get_publication.

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 implies a read-only operation ('Retrieve') but doesn't disclose return format, authentication needs, or any constraints on the domain parameter. For a simple get-by-ID tool this is adequate but minimal.

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

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

The description is a single, front-loaded sentence with no wasted words. It fully captures the tool's essence in an efficient manner.

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 should clarify what 'details' includes (e.g., title, date, full content). Also, the sibling get_press_release may appear similar, yet no distinction is made. The description is minimal viable but leaves 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 100% – both 'id' and 'domain' have descriptions. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 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 action ('Retrieve details'), the resource ('a single news item'), and the source ('the BPS website'). This distinguishes it from list_news, which lists multiple items, making the purpose unambiguous.

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 fetching a single item by ID, but it does not explicitly state when to use this tool vs. alternatives like get_press_release, nor does it mention that the ID likely comes from list_news. No exclusions or alternative-naming is provided.

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 only says 'Retrieve details' with no information about read-only nature, required permissions, error cases, or response shape. The behavior is minimally disclosed beyond the tool's obvious purpose.

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 concise, front-loaded sentence with no redundancy. Every word contributes to the purpose.

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 single-get tool, the description is adequate but sparse. It does not explain what 'details' includes, nor the relationship between domain and id, and no output schema exists. However, the two required parameters are clear from the schema, and sibling tools provide context.

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%, with both parameters documented ('BRS ID' and 'BPS domain code'). The description adds no additional meaning beyond the schema, 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 uses the specific verb 'Retrieve' with 'details of a single BPS Press Release (BRS)', clearly indicating the tool fetches one specific release by ID. The word 'single' differentiates from sibling list tools like list_press_releases, though it does not explicitly name the alternative.

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 no guidance on when to use this tool versus alternatives such as list_press_releases or get_publication. No context about prerequisites or preferred workflows.

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. While 'Retrieve' implies a read-only operation, the description does not disclose potential behaviors like whether an invalid ID returns an error or empty result, whether authentication or rate limits apply, or what exactly 'details' include. For a tool with no annotation support, this is insufficient 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 a single, front-loaded sentence that directly states the action and resource. It wastes no words and is appropriately concise for a simple retrieval 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?

Given the tool's low complexity (2 required params, no output schema, no enums), the description covers the core purpose and both parameters are documented. However, it lacks any nuance about the return value's shape, error behavior, or relationship to sibling tools like list_publications, so it is minimally viable but not complete.

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

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

Schema description coverage is 100% (both 'id' and 'domain' have descriptions). The tool description adds no additional meaning about how the parameters interact (e.g., that both are needed to uniquely identify a publication) or what constitutes a valid 'BPS domain code'. Baseline 3 is appropriate since structured data already documents the 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 uses a specific verb ('Retrieve') and resource ('details of a single BPS publication'), clearly distinguishing this from sibling tools like list_publications (which lists multiple) and get_press_release (which targets a different resource type). It precisely states what the tool does.

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 no guidance on when to use this tool versus alternatives such as list_publications or get_press_release. There is no mention of use cases, when not to use it, or which alternative might be more appropriate for listing vs. single-item retrieval. This is a clear absence of usage direction.

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 carry the behavioral disclosure burden. It states 'in one step' and 'across all provinces,' adding some value. However, it does not describe output format, handling of missing data, or limitations (e.g., max top_n), leaving the agent to infer from 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 concise and front-loaded: purpose sentence, usage sentence, then a bulleted list of examples. Every sentence earns its place, and the examples are illustrative without being verbose.

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 simple tool with full schema coverage and no output schema, the description covers purpose, usage scenario, and query examples. It could mention default top_n or max values, but these are already in the schema. Overall, the context is sufficient for accurate tool selection.

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 baseline is 3. The description goes beyond schema by providing example queries that clarify the 'query' parameter's semantics (e.g., 'kemiskinan', 'pengangguran', 'IPM'). This helps the agent map user intent to the indicator field, adding meaningful value.

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

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

The description opens with a specific verb+resource: 'Retrieve province rankings by a given indicator.' It clearly distinguishes from sibling tools (e.g., get_trend, compare_data) by focusing on rankings across all provinces. The example queries reinforce the exact 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?

Provides clear context: 'Use this tool when the user wants to see rankings, top-N, or comparisons across all provinces.' No explicit when-not or alternative tool references, but the positive use cases are concrete and unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavior disclosure. It explains that the tool returns dynamic or static table data depending on the model, but it does not describe the return format, potential errors, pagination, or any operational constraints. This is adequate but lacks rich behavioral detail.

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 long, front-loaded with the primary purpose, and every sentence contributes meaningful information. There is 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?

Given the tool's low complexity, full schema coverage, and no output schema, the description covers the essential workflow and parameter sourcing. However, it could be more complete by explaining what the returned data looks like or any limitations, especially without annotations.

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 full descriptions for all parameters, so the baseline is 3. The description adds value by explaining that var_id and model come from list_sdds and by clarifying the meaning of the model enum ('data' vs 'statictable'), which goes beyond the schema's 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 action ('Fetch actual SDDS indicator data') and resource, and further distinguishes behavior by model type ('For 'data' model, this fetches dynamic table data. For 'statictable' model, it fetches a static table.'). It also references the prerequisite list_sdds, setting it apart from listing 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 instructs to use list_sdds first to obtain var_id and model type, establishing a clear workflow. It also explains the difference between the two model types, helping users decide when the tool is appropriate. However, it does not explicitly mention alternative data-fetching tools or when not to use this tool.

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

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

No annotations are present, so the description carries the full burden. It indicates a read operation ('Fetch') and mentions 'data values,' but it does not disclose the response format, whether results are time-series, possible limitations, or error behavior. The description adds little beyond what the tool name implies.

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

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

Two focused sentences: the first states the core purpose, the second gives the critical prerequisite and workflow. No wasted words, and both sentences earn their 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 simple 2-parameter read tool with fully documented schema, the description is sufficiently complete for selection and invocation: it names the resource, specifies the prerequisite, and points to the schema for parameters. It lacks any description of the return structure, but given the absence of an output schema and the simplicity of the tool, the gap is not severe.

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% and the schema already explains both var_id ('Variable ID from list_sdgs') and year ('Year filter... Omit for latest'). The description mostly repeats the var_id source ('Use list_sdgs first'), adding no new parameter semantics; thus the baseline of 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 uses a specific verb ('Fetch') and resource ('actual SDGs indicator data') for a specific variable. It clearly distinguishes this from list_sdgs, which is the discovery tool, and from other data-fetching siblings like get_sdds_data by scoping to SDGs.

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 workflow guidance: 'Use list_sdgs first to find the var_id, then call this to get the data values.' This establishes the prerequisite and the proper sequence, effectively telling the agent when to use this tool versus its list counterpart.

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

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

With no annotations provided, the description carries the full burden. It states the core function and required inputs but does not disclose return format, pagination, or any side effects. The prerequisites are helpful but basic behavior is only partially 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?

Two concise sentences with the main action front-loaded. No waste; every sentence earns its place by stating what the tool does and what inputs are needed.

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 data retrieval tool with full schema coverage and no output schema, the description adequately covers purpose, required parameters, and their source. It is slightly vague about what 'detailed data' means and does not describe the response format, but it remains sufficient for invocation.

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

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

The input schema already provides descriptions for all three parameters (coverage 100%), so the schema carries the heavy lifting. The description adds minimal extra context (e.g., the source of id_tabel from list_simdasi_tables), but it largely restates schema information.

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 action ('Get detailed data') and the target resource ('SIMDASI table') scoped by area and year. It distinguishes from sibling list tools by focusing on retrieving specific table data rather than listing available tables.

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 states the required parameters and notes that id_tabel must come from list_simdasi_tables, implying a prerequisite step. It does not explicitly mention alternatives or when not to use this tool, but gives clear contextual guidance.

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

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

With no annotations provided, the description must disclose behavioral traits. It does reveal that the table content is returned in HTML format, which is useful. However, it does not describe other details, error behavior, or any constraints, leaving the agent with limited information beyond a basic read operation.

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, focused sentence that gets straight to the point. It includes the key detail (HTML format) without any extraneous 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?

As a simple retrieval tool with no output schema, the description partially explains the return value by mentioning HTML content but leaves 'details' vague. It could benefit from clarifying what other fields are returned or how to identify the correct domain/ID, but the schema covers the latter.

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 100% coverage with descriptions for both parameters ('Static table ID' and 'BPS domain code'). The tool description adds no extra parameter semantics, 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 specifies the action (retrieve details) and the exact resource (a single BPS static table), and clarifies that the response includes HTML content. This clearly distinguishes it from sibling tools like list_static_tables and get_dynamic_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?

There is no explicit guidance on when to use this tool versus similar getter tools such as get_csa_table or get_simdasi_table. The description implies usage through 'single static table' but does not mention any prerequisites or alternatives.

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

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

With no annotations provided, the description carries the full burden. It mentions that data includes value and volume, offering some insight into the return content, but does not disclose response format, potential limitations, or authentication needs. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that is concise and free of redundancy. Every word contributes to the tool's purpose, making it highly 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?

For a simple data retrieval tool with comprehensive schema coverage and no output schema, the description provides sufficient context about what the tool does and what data it returns. It does not explain return formatting, but this is not critical given the schema handles parameter details.

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, so the description does not need to elaborate much. It mentions 'by HS code' and 'exports/imports', which roughly align with hs_code and source parameters, but adds little beyond what the schema already provides. Baseline of 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 retrieves foreign trade data (exports/imports) by HS code for Indonesia, using a specific verb and resource. It effectively distinguishes this tool from sibling tools like get_census_data or get_press_release by focusing on trade 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 Indonesian trade data queries but does not provide explicit when-to-use guidance or mention alternatives. Since the context is clear but exclusions are absent, this is an implied usage scenario rather than fully 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?

No annotations are provided, so the description carries the full burden. It adds the behavioral note that the tool retrieves data 'in one step,' indicating it combines multiple years into a single call. However, it does not disclose the return format, any rate limits, or whether specific permissions are needed. For a read-only trend retrieval, this is adequate but not rich.

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 well-structured with a clear purpose statement, a usage guideline, and four example queries. Each section serves a purpose, though the example list is somewhat long. It remains concise 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?

The tool has 4 parameters, no output schema, and no annotations. The description covers purpose, usage, and provides concrete examples, which is fairly complete for a data retrieval tool. It does not explicitly describe the response structure, but given the simplicity and the implicit 'time-series data' return, this is acceptable. A bit more detail on output could push it higher.

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% description coverage for all four parameters, so the baseline is 3. The description adds example queries that illustrate how to fill the parameters (e.g., 'poverty trend Indonesia 2019-2023' maps to query, region, start_year, end_year), which provides slight added 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?

The description opens with 'Retrieve time-series data (multi-year trend) in one step,' which clearly specifies the verb (retrieve), resource (time-series data), and scope (multi-year trend). This distinguishes it from sibling tools like get_census_data or get_dynamic_data by focusing on trend analysis. Example queries further clarify the tool's 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 explicitly states 'Use this tool when the user wants to see data trends year over year,' providing clear usage context. However, it does not explicitly mention alternatives or exclusions, so it lacks the when-not-to-use guidance for 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?

With no annotations, the description carries the burden of disclosing behavior. It provides a workflow and indicates that the output is used elsewhere, but it does not explicitly state whether the operation is read-only or require any permissions. For a simple list operation, the implication is there, but it could be more explicit.

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 concise sentences, front-loaded with the purpose. Every sentence adds value: purpose, prerequisite, and output usage. 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 simple tool with one parameter and no output schema, the description provides the essential context: how to get the parameter and what to do with the result (MFD codes). It could be more complete if it described the return format or any pagination, but for this simplicity level it is adequate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context by tying the parameter to 'a specific census activity' and referencing list_census_events, which mirrors the schema description. It does not provide additional syntax or format details 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 action ('List available areas/regions') and the resource ('for a specific census activity'). It references the prerequisite tool (list_census_events) and downstream usage (get_census_data), which distinguishes it from other list_* 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?

The description explicitly instructs to use list_census_events to get the activity ID, providing a clear prerequisite. It also mentions that the returned MFD codes are used as wilayah_sensus in get_census_data, establishing workflow context. However, it does not list 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It accurately conveys that the tool is a read-only listing operation requiring a valid activity and topic, and hints at dependencies on prior calls. It does not disclose return format or error behavior, but for a simple list operation this is acceptable and richer than many similar tools.

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 long, with the primary purpose front-loaded in the first sentence and a concise workflow directive in the second. Every word earns its place, making it highly 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?

For a simple two-parameter list tool with no output schema or annotations, the description sufficiently covers what the tool does and how to obtain inputs. It could be more complete by explicitly describing the nature of the returned dataset list or contrasting with get_census_data, but it is not severely lacking.

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 100% coverage, describing both parameters as IDs sourced from list_census_topics and list_census_events. The description reinforces the parameter semantics but adds no new information beyond the schema, meriting the baseline score of 3.

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 lists available datasets for a specific census activity and topic, using a specific verb and resource. It distinguishes itself from sibling tools by emphasizing dataset listing and referencing prerequisite tools, which helps narrow its role.

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 to call list_census_events and list_census_topics first, establishing a clear workflow. It does not explicitly state when not to use this tool (e.g., for actual data retrieval via get_census_data), so it falls short of a 5 but offers strong contextual usage direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention pagination, sorting, response format, or the read-only nature of the operation. The examples and ID hint are purpose-oriented, not behavior-oriented.

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 concise sentences effectively communicate the tool's purpose and a key workflow hint without redundancy. Information is front-loaded and 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 simple list tool with no parameters and no output schema, this description covers the core use case and explains the role of the activity ID. The only gap is the unspecified return structure, which is a minor omission for such a simple 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 tool has zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are required since no parameters exist.

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 identifies the tool as listing BPS census activities with concrete examples (Population, Economic, Agricultural). It distinguishes itself from sibling tools like list_census_topics and list_census_datasets by focusing on the activity-level entity.

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 as a starting point for obtaining activity IDs, which are then used to fetch census topics and data. However, it does not explicitly mention when to use alternative tools or provide exclusions, leaving guidance implicit 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?

There are no annotations provided, so the description carries the full burden. It states the operation is a list, implying non-destructive behavior, but it does not disclose any specific behavioral details such as auth requirements, pagination, or data format. The description is minimal but not misleading.

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 short sentences. The main purpose is front-loaded in the first sentence, and the second provides essential prerequisite guidance. 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?

This is a simple tool with one parameter and no output schema. The description explains what it lists and where to get the required ID. It doesn't describe the return format, but that might be inferred from 'data topics'. Given the simplicity, the description is adequate but could benefit from a note about the response structure or field names.

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 for the sole parameter 'kegiatan' with its description 'Census activity ID (from list_census_events)'. The tool description reinforces this by saying 'Use list_census_events to get the activity ID', but it doesn't provide additional syntax or format details beyond the schema, so a baseline of 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 uses a specific verb 'List' with a clear resource 'data topics' and scope 'for a specific census activity', distinguishing it from sibling tools like list_census_areas and list_census_datasets by the resource type.

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 says 'Use list_census_events to get the activity ID,' providing a clear prerequisite and directing the agent to a sibling tool for the required parameter. However, it doesn't explicitly state when not to use this tool vs other census listing 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?

With no annotations provided, the description carries the full burden. It implies a read-only listing operation via 'List', and adds context about model types and level filtering, but does not disclose potential pagination, response format, or any other behavioral details. The provided context is minimal but not misleading.

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, each earning its place: the first states the core action, the second details supported models, and the third gives filtering guidance. It is front-loaded and free of 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 simple two-parameter list tool, the description is nearly complete. It covers the purpose, supported models, and how to use the optional parameter. The absence of an output schema is not a major gap since the tool probably returns a list of entries. It could mention what happens when no level is specified, but overall it is sufficient.

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%, but the description enriches the parameter meanings by explaining what KBLI and KBKI represent (business vs commodity classification, ISIC-based) and explicitly pointing to the 'level' parameter for hierarchy filtering. This adds value beyond the raw enum values 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?

The description starts with 'List BPS statistical classification entries by model', which uses a specific verb and resource, clearly distinguishing it from sibling tools by specifying the classification models (KBLI and KBKI) and their versions. The scope is unambiguous.

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 clearly indicates when to use the tool: to list classification entries for KBLI or KBKI models, and how to filter by level. It does not explicitly mention alternatives (e.g., get_classification), but the context is clear enough for selecting this tool.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It only explains that CSA is an international classification, but does not indicate pagination, ordering, whether the list is hierarchical, if authorization is required, or what the response format looks like. This is a significant gap for a tool with zero annotation coverage.

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 concise sentences. The first sentence states the purpose directly, and the second clarifies the acronym CSA. Every word earns its place, with 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 tool with no output schema and no annotations, the description is incomplete. It does not describe the return structure, whether categories are nested, or how the domain parameter filters the results. While the tool appears simple, the lack of behavioral and output details leaves the agent uncertain about what to expect.

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 schema description covers 100% of parameters (the 'domain' field has a description 'BPS domain code'), so the baseline is 3. The tool description adds no additional meaning about how 'domain' affects the results or what values are expected, but the schema already provides basic semantics.

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 lists BPS CSA categories with a specific verb ('List') and resource ('CSA categories'). It also explains the CSA acronym, adding context. However, it does not explicitly distinguish this from sibling tools like list_csa_subjects or list_classifications, though the resource name is specific enough to infer some differentiation.

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 guidance is provided on when to use this tool versus alternatives. It doesn't mention whether this should be used for top-level categories or how it relates to list_csa_subjects or list_csa_tables. There is no explicit context or exclusion criteria, leaving the agent to guess the appropriate use case.

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

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

With no annotations, the description must convey behavioral traits. It only says 'list,' implying read-only, but offers no detail on side effects, error handling, filtering semantics, or return behavior. The description adds minimal value beyond the tool name.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose without filler.

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

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

The description is minimal and does not explain return values, pagination, or behavior with no arguments. Since there is no output schema, the description should compensate but does not, leaving a significant gap for a list-type 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%, so the baseline is 3. The description mentions 'domain and category,' aligning with the parameters, but adds no additional meaning beyond what the schema already documents (e.g., parameter types or defaults).

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 lists CSA subjects, filtered by domain and category. This is specific and distinguishes from siblings like list_csa_categories or list_csa_tables by naming the resource type, though it does not explicitly contrast with generic list_subjects.

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 guidance is provided on when to use this tool versus alternatives. It simply states the action without context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden for behavioral transparency. It only states the action and inputs, but does not disclose whether pagination applies, what the response contains, or how the optional subject parameter behaves when omitted. The description omits the 'page' parameter entirely, leaving agents to infer behavior from 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 a single sentence that immediately states the action and key inputs. There is no filler or redundant phrasing, making it appropriately concise 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 that there is no output schema and no annotations, the description should explain return values, pagination behavior, and the optionality of parameters. It fails to do so, leaving agents without sufficient context to predict the tool's output or handle all parameters correctly. It only covers the core action, not the broader context needed for a 3-parameter 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 schema already describes all three parameters (page, domain, subject) with 100% coverage, so the description does not need to carry much parameter-specific weight. The phrase 'for a given domain and subject' slightly reinforces the role of two parameters, but adds no new meaning beyond the schema. The 'page' parameter is not mentioned in the description.

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

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

The description 'List CSA tables for a given domain and subject' clearly identifies the action (list), the resource (CSA tables), and the key inputs (domain and subject). This distinguishes it from sibling tools like list_csa_categories and list_csa_subjects, which target different resources.

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 the tool is used to list CSA tables filtered by domain and subject, but it provides no explicit guidance on when to choose this over alternatives such as list_csa_categories or list_csa_subjects. There are no exclusions or 'use X instead' instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation ('List derived periods') without mentioning return format, pagination, authentication needs, error behavior, or whether the listing is derived dynamically. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core purpose with no wasted words. It is appropriately sized for a tool of this simplicity.

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 2-parameter tool with no output schema and no annotations, this description is minimally viable but leaves gaps. It does not state what the response contains, explain the role of the domain parameter, or mention any default behavior. Given the low complexity, some additional context would improve completeness, but the current text is adequate at a basic level.

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 describes both parameters (var as 'Variable ID' and domain as 'BPS domain code') with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. It neither enhances nor contradicts the schema's parameter documentation.

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'), resource ('derived periods'), and scope ('for a given variable'), clearly distinguishing it from sibling tools like list_periods (which lists all periods) and list_derived_variables (which lists variables, not periods). This is a precise and unambiguous statement of the tool's function.

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 offers no guidance on when to use this tool versus alternatives such as list_periods or list_derived_variables. It does not mention prerequisites, exclusions, or selection criteria beyond the trivial fact that it applies to a given variable, leaving the agent without useful decision-making information.

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 reveals the tool is a read-only listing operation but does not disclose behavior such as whether parameters filter results, pagination, or return format. For a simple listing tool, 'List' implies read-only, but the effect of the optional var and domain parameters is unexplained.

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 one sentence with examples, front-loaded and free of filler.

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

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

The tool is simple, but with two optional parameters and no output schema, the description does not explain how var and domain affect the result or what the list contains. It lacks guidance on filtering and distinctions from related list tools. However, for a basic list operation, it is minimally adequate.

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

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

Schema coverage is 100% with both variables having descriptions. The description adds no parameter semantics beyond the schema, 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 uses a specific verb 'List' and identifies the resource as 'derived variables' with a parenthetical clarification '(aggregated categories)' and examples 'total, average'. This clearly distinguishes it from sibling tools like list_variables and list_derived_periods.

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 over alternatives like list_variables, nor does it mention any exclusions. The examples imply it is for aggregated metrics, but guidance is implicit 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?

No annotations are provided, so the description carries the transparency burden. It implies a read-only list operation and explains type filtering, but does not discuss output format, pagination, or any side effects. The additional behavior described is minimal 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?

Two concise sentences, front-loaded with the main purpose. Every word adds value, with no filler or repetition.

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 two-parameter list tool, the description covers purpose, type usage, and parameter meaning. It is reasonably complete given the low complexity and absence of an output schema, though it does not specify the returned fields or format.

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%, with both parameters already described in the input schema. The description restates the type enum in slightly different words and adds the prov requirement context, but does not significantly extend beyond the schema's built-in 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 lists BPS domains/regions (province, regency/city), with a specific verb and resource. It distinguishes from sibling list tools by its focus on geographic domains and provides type options.

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 usage instructions for each type value ('prov', 'kab', 'kabbyprov'), telling the user exactly which option to use for different needs. Does not explicitly mention alternative tools or when-not to use, but the guidance is clear and actionable.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Search terms' and does not mention pagination, domain filtering, return format, or whether it returns a list or a single entry. This is insufficient for an agent to understand the tool'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?

The description is concise and front-loaded with the primary action. The second sentence provides purpose but is somewhat redundant; still, it does not waste 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?

The tool has three parameters, no output schema, and no annotations. The description does not explain what the tool returns, how pagination works, what domain means, or how it differs from get_glossary. This leaves significant gaps for an agent trying to invoke the tool correctly.

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

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

Schema description coverage is 100%, so all three parameters (page, domain, keyword) are already documented in the schema. The description adds no extra meaning beyond implying the keyword is for searching, which is already evident from the parameter name and description.

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

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

The description clearly states the tool searches terms in the BPS statistical glossary with the verb 'Search' and resource 'glossary terms.' However, it does not explicitly distinguish itself from the sibling tool get_glossary, which likely retrieves a specific entry.

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 a clear use case: 'Useful for understanding definitions and meanings of statistical indicators.' However, it does not mention exclusions or alternatives, such as when to prefer get_glossary or the broader search 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?

With no annotations, the description must supply behavioral context. It only defines infographics but does not mention pagination, default domain, ordering, or response format. This is thin for a listing 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 one concise sentence, front-loaded with the verb and resource, and contains no irrelevant 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?

For a simple list tool with optional parameters and no output schema, the description is minimally acceptable but lacks details about pagination, result size, and how filters work together. More context would improve usability.

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 covers all three parameters with descriptions (page, domain, keyword). The tool description adds no extra parameter detail, so the baseline of 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 states 'List BPS infographics,' which specifies a clear action and resource. It also clarifies what infographics are, but does not explicitly distinguish from sibling tools like get_infographic, though the list/get distinction is implicit.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_infographic or search. It lacks any mention of use cases or 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?

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the data source ('BPS website') and the general nature of the news, but gives no information about pagination, output format, filters, rate limits, or any other operational behavior. This is a significant gap for a tool without annotation support.

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 extremely concise, consisting of two sentences that are both essential. The first sentence states the primary action and resource, and the second sentence adds a crucial distinction from BRS. There is no fluff or repetition, making it well-structured 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?

Despite the tool's relative simplicity, the description lacks important contextual details about how the tool behaves in practice. It does not mention how the parameters interact, whether results are paginated, what fields are returned (no output schema exists), or any limitations. This makes the description incomplete for an agent to fully anticipate the tool's behavior.

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 has 100% parameter-description coverage, with descriptions for page, domain, and keyword. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies here.

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 function with a specific verb ('List') and resource ('news from the BPS website'), and further distinguishes it from BRS (Official Statistics News) by specifying 'general BPS news items'. This effectively differentiates the tool from the alternative news type, making it easy for an agent to identify its 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 provides clear context by noting that this tool lists general BPS news as opposed to BRS (Official Statistics News). While this implies appropriate usage, it does not explicitly name sibling tools or provide explicit when-to-use/when-not-to-use guidance beyond the BRS distinction, so it falls just 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?

No annotations are provided, so the description carries full burden. It states that the tool lists news categories and gives examples, but it does not disclose return format, whether the list is exhaustive, or any side effects. For a simple read-only list operation this is minimally adequate, but some behavioral context (e.g., 'returns a flat list of category names') is missing.

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 only two sentences: the first states the purpose with concrete examples, and the second gives usage integration. Every word earns its place, with no fluff 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?

For a simple list tool with one optional parameter and no output schema, the description is largely complete. It identifies the resource, gives examples, and explains how the result will be used (in list_news). The only minor gap is the lack of return format details, but the use case context compensates.

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 schema describes the single 'domain' parameter as 'BPS domain code' with 100% coverage, so the baseline is 3. The description adds no additional meaning about the parameter, such as how it affects the results or what domains are valid, but the schema already covers it sufficiently.

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' with the resource 'BPS news categories' and provides concrete examples ('Sensus dan Survey, Statistik Lain'), making the tool's function unambiguous. It also distinguishes this from sibling list tools by clarifying it's for news categories specifically, not other domains like census or subjects.

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 tells the agent to use the category name as a 'newscat filter in list_news', giving a concrete downstream use case. This clearly situates the tool within a workflow, though it doesn't explicitly mention when not to use it or compare to alternatives like list_csa_categories.

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

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

With no annotations, the description carries the full burden. It adds useful context by specifying that periods can be years, semesters, quarters, or months, but does not disclose other behaviors such as how missing variables are handled, whether domain affects results, or whether the operation is read-only (though 'list' implies so).

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 concise sentence that immediately states the purpose and adds value by enumerating possible period types. It is front-loaded and contains 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?

For a simple listing tool with two optional parameters and no output schema, the description provides sufficient context: it names the resource (periods), ties it to a variable, and explains the possible period granularity. However, it omits details about the domain parameter's role and any output structure, but these are not critical for a straightforward list operation.

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 both parameters (var and domain). The description adds no new parameter semantics beyond reinforcing that periods are tied to a variable; it does not elaborate on the domain parameter or provide format details 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 lists available data periods for a given variable, with a specific verb (list) and resource (periods). It identifies common period types (years, semesters, quarters, months), but does not explicitly distinguish itself from sibling tool list_derived_periods, so it lacks full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives like list_derived_periods, nor any exclusions or prerequisites beyond implying a variable is needed. The description says 'for a given variable' but does not explain when one would choose this over other list 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool lists BRS releases and that BRS contains official data releases, which implies a read-only operation. However, it does not disclose any other behavioral traits such as pagination behavior, default ordering, or result limits. It is minimally adequate but lacks depth.

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 concise sentences. The first sentence states the primary purpose with the tool name, and the second adds useful context about BRS. There is no extraneous information, and the structure is front-loaded with the action.

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 (5 optional, well-documented parameters, no output schema, no annotations), the description provides adequate context. It explains what a BRS is and that the tool lists them. However, it could have referenced the 'get_press_release' sibling for retrieving a specific release. Overall, it is complete enough for a straightforward list operation.

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 complete descriptions for all 5 parameters (page, year, month, domain, keyword), covering 100% of the schema. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate since 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?

The description clearly states the tool's function: 'List BPS Press Releases' with the specific resource (Berita Resmi Statistik). It also distinguishes it from the sibling 'get_press_release' by using 'list' as the verb, indicating a collection operation. The added context that BRS contains latest official data releases further clarifies its 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 implies the tool is for browsing press releases but does not explicitly state when to use it over alternatives like 'list_publications' or 'get_press_release'. No when-not-to-use or alternative recommendations are provided. The purpose is clear enough to infer usage, but explicit guidance is missing.

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 of behavioral disclosure. It only states 'List BPS publications' without explaining return format, pagination behavior, read-only nature, or any side effects. There is no indication of what happens with no parameters or how filters interact, leaving the agent uncertain about the tool'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?

The description is concise: two short sentences. The first sentence states the purpose, and the second adds useful context about publications. There is no redundancy or filler, making it well-structured and easy to parse.

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 5 parameters, no annotations, and no output schema, the description is quite minimal. It does not explain what the response looks like, how pagination works, or how the year/month/domain/keyword filters combine. While the schema covers parameter names, the overall context is incomplete for an agent to fully understand the tool's capabilities and output.

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 all five parameters have descriptions in the schema. The tool description does not add any additional meaning beyond that. Per the baseline for high schema coverage, a score of 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: 'List BPS publications.' The verb 'List' combined with the resource 'BPS publications' is specific. It also adds context that publications contain in-depth analysis and statistical reports. However, it does not explicitly distinguish this from sibling tools like list_press_releases or get_publication, so it's not a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer list_publications over list_press_releases or get_publication, nor does it state any prerequisites or exclusions. This is a clear gap.

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

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

With no annotations, the description carries the full burden. It adds useful context by noting that each indicator has var_id and model type, and that domain is always 0000 (National). However, it does not disclose the exact return structure (e.g., full list of fields), pagination behavior, or whether any side effects exist (though listing implies read-only). Some behavioral traits are disclosed, but not comprehensively.

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, front-loaded with the core purpose in the first sentence. Each sentence adds relevant information (scope, indicator attributes, fixed domain) without any fluff or redundancy. It is appropriately concise for a tool with no parameters.

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, no output schema), the description provides necessary context: the source (BPS), the standard (IMF SDDS), and key attributes of returned indicators (var_id, model type, domain). It lacks explicit details about the full return format or any limitations, but for a list operation, it covers the essential information needed for an agent to invoke and interpret 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?

The tool has zero parameters, which establishes a baseline of 4. The description adds meaningful context by explaining that returned indicators include var_id and model type, and that the domain is always 0000, giving the agent a sense of what the list contains beyond 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 clearly states that the tool lists SDDS indicators from BPS, using a specific verb ('List') and resource ('Special Data Dissemination Standard indicators'). It also distinguishes from sibling tools by mentioning the IMF standard and the fixed domain (0000 National), making the tool's scope unambiguous.

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 context (to discover available indicators and their attributes for fetching values) but does not explicitly contrast with alternatives like get_sdds_data or other list tools. It mentions that var_id and model type are 'used to fetch actual values,' which hints at a subsequent data-fetching step, but no alternative tool is named.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses a non-obvious constraint: 'Domain is always 0000 (National),' and highlights the presence of var_id, which is beyond the schema. While it doesn't explicitly state read-only, 'List' implies a read operation, and the added details are valuable.

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 earning its place: main purpose, optional parameter, and workflow insight. It's front-loaded and free of filler, making it highly 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?

For a tool with one optional parameter and no output schema, the description covers the core purpose, filtering option, workflow (var_id to get_dynamic_data), and an important domain constraint. It slightly lacks detail about the response structure, but the mention of var_id and 'indicators' gives sufficient context. Overall, it's a complete enough description for this simple tool.

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

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

Schema description coverage is 100% and the parameter description ('Goal number to filter (1-17). Omit to list all SDG indicators.') fully explains the goal parameter. The tool description merely restates this as 'Optionally filter by goal number (1-17),' adding no new semantic information. Thus, 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 function: 'List Sustainable Development Goals (SDGs) indicators from BPS.' The verb 'List' and specific resource 'SDG indicators from BPS' make it unambiguous. It also differentiates from sibling tools by mentioning var_id linkage to get_dynamic_data, separating it from data-fetching tools like get_sdgs_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 provides workflow context by stating 'Each indicator has a var_id that can be used with get_dynamic_data to fetch actual values,' indicating when to use this tool as a precursor. It also mentions optional filtering by goal number. However, it doesn't explicitly mention when not to use it or name alternatives beyond the implicit link to get_dynamic_data.

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

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

With no annotations, the description carries the full burden. It adds useful context beyond the schema: the SIMDASI domain, the 7-digit format, and the need for a parent regency code. However, it does not disclose output structure, error behavior, or potential edge cases such as empty results or invalid parent codes, leaving notable gaps for a tool with 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?

The description is two short sentences, front-loaded with the primary action and resource, then a direct, useful instruction for obtaining the required parent code. Every sentence earns its place 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?

For a simple single-parameter list tool, the description covers what it lists, the domain, and the prerequisite parent code. The lack of an output schema means the exact return format is not explicitly stated, but 'List 7-digit MFD codes' strongly implies an array of code strings, making it largely complete for its low 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 schema already provides 100% coverage for the single 'parent' parameter with a clear description. The tool description adds value by explaining how to obtain the correct parent MFD code via list_simdasi_regencies, which is practical guidance beyond the schema's static field description.

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

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

The description uses the specific verb 'List' and identifies the resource as '7-digit MFD codes for districts in a regency', with context that it is used in SIMDASI. It clearly distinguishes from sibling tools by scoping to districts and referencing list_simdasi_regencies for the parent code, making the hierarchy explicit.

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

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

The description explicitly instructs to use list_simdasi_regencies to get the parent MFD code, which is a clear prerequisite and points to an alternative tool for the parent level. It does not explicitly state when not to use this tool (e.g., for provinces or regencies), but the parent-child framing implies the appropriate usage 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?

With no annotations, the description carries the full burden but reveals no behavioral traits beyond a basic listing action. It does not mention pagination, ordering, or any system dependencies, making the tool's actual runtime behavior opaque.

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, concise sentence with no redundancy. It directly states the action and object, earning its place as an efficient summary.

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 many sibling tools with similar names, the description lacks the context needed to clarify what 'master tables' means and how this tool fits into the broader API. Without an output schema or annotations, it does not sufficiently guide a user on the tool's scope or relationship to alternatives.

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 baseline is 4. The description adds no parameter-specific meaning, but the schema indicates no inputs are needed, and the lack of parameters is consistent with the stated purpose of listing all master tables.

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 ('List') and resource ('SIMDASI master tables'), making the core purpose apparent. However, it does not differentiate from sibling tools like list_simdasi_tables or list_simdasi_tables_by_subject, since 'master tables' is ambiguous without further 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?

No guidance is provided on when to use this tool versus its siblings. The description only says 'List all...' without explaining what distinguishes master tables from other table types or when a user should select this tool over alternatives.

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 discloses the core behavior (listing 7-digit codes) but does not add context such as read-only confirmation, authentication requirements, or output response structure. The usage note adds practical value beyond the basic listing action.

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, front-loaded with the main purpose and followed by a practical usage note. It contains no unnecessary words and is efficiently 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?

For a zero-parameter tool, the description is largely complete: it states what is returned (7-digit MFD codes) and how to use the output. However, since there is no output schema, it could more explicitly describe the response format (e.g., whether names are included alongside codes), leaving a minor gap.

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 the input schema is empty. The description adds no parameter-specific semantics, but since there are no parameters, the baseline for zero-parameter tools is 4, and no further 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 tool lists 7-digit MFD codes for all provinces used in SIMDASI, using a specific verb and resource. It distinguishes from sibling tools like list_simdasi_regencies and list_simdasi_districts by explicitly specifying provinces.

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 clear context by instructing users to use the returned codes as the 'wilayah' parameter for other SIMDASI tools. However, it does not explicitly mention alternative tools or when not to use this tool, stopping short of full exclusion guidance.

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

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

With no annotations provided, the description carries the full burden for behavioral transparency. The verb 'List' implies a read-only operation, and the description clarifies the input is a 7-digit province code, but it does not disclose return format, pagination, or error behavior. This is adequate for a simple listing operation but leaves some behavioral aspects implicit.

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 two concise, front-loaded sentences with no redundancy. The first sentence states the core action and output, and the second sentence provides a crucial usage pointer; 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?

Given a simple one-parameter list tool with no output schema and no annotations, the description provides the essential context: what it lists, for which geographical level, and how to obtain the parent code. It does not describe the return structure, but the absence of an output schema reduces the need for that detail; an agent can reasonably infer the output from the tool's purpose.

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 schema already fully describes the single parameter 'parent' as a '7-digit MFD code of the parent province' (100% coverage). The description adds value by referencing list_simdasi_provinces as the source for this code, teaching the agent the provenance of the input value, which goes beyond the schema's static definition.

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 action ('List') and the target resource ('7-digit MFD codes for regencies/cities in a province'), clearly distinguishing it from sibling tools like list_simdasi_provinces and list_simdasi_districts by specifying the administrative level. The phrase 'used in SIMDASI' adds domain 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 provides an explicit prerequisite instruction: 'Use list_simdasi_provinces to get the parent MFD code,' which guides the agent on how to obtain the required parameter. However, it does not explicitly state when this tool should be used over alternatives like list_simdasi_districts, so it lacks a full exclusion set.

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 of behavioral disclosure. It only says 'List' and mentions a required code, but does not state that it is a read-only operation, what happens with invalid codes, whether the response is paginated, or what format the subjects/chapters take. This minimal disclosure leaves significant behavioral aspects unaddressed.

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 long, with the primary action front-loaded and the prerequisite stated in the second sentence. No redundant or fluff content; every word contributes to understanding the tool's purpose and usage.

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 listing tool, the description covers the core purpose and input requirement. However, without an output schema or annotations, it leaves gaps around expected return values and error behavior. It is minimally adequate but not comprehensive.

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 fully describes the 'wilayah' parameter as a '7-digit MFD code of the area (province/regency)' (100% schema coverage). The description adds the source of the code ('from list_simdasi_provinces') and reinforces that it is required, but this is marginal added 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?

The description clearly states the tool's function: 'List SIMDASI subjects/chapters available for a specific area.' It uses a specific verb ('List'), names the resource (SIMDASI subjects/chapters), and adds scope ('for a specific area'), which distinguishes it from sibling tools like list_simdasi_tables and list_simdasi_master_tables.

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 a specific prerequisite: 'Requires a 7-digit MFD wilayah code from list_simdasi_provinces.' This tells the agent where to obtain a valid input and implies the tool is for area-specific subject listing. However, it does not explicitly mention when to prefer this tool over alternatives like list_simdasi_tables_by_subject, so it stops short of full exclusion 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 are provided, so the description carries the full burden. It only discloses the requirement for a wilayah code and its source, but does not describe the return value, pagination, or side effects. For a list operation, output behavior is left unspecified.

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 short, front-loaded sentences with no filler. The main action is stated first, and the constraint follows in the second sentence.

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 list tool, the description is adequate. However, the absence of an output schema and any description of the returned data structure leaves a gap for agents needing to know what 'list tables' actually returns. The prerequisite helps but does not fully address output semantics.

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

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

The input schema already describes 'wilayah' as '7-digit MFD code of the area' (100% coverage). The description adds provenance by stating the code comes 'from list_simdasi_provinces', which is meaning not present 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?

The description uses 'List' as a specific verb, identifies the resource as 'SIMDASI tables', and scopes it to 'a specific area' via a wilayah code. This clearly differentiates it from siblings like list_simdasi_provinces and get_simdasi_table.

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 a clear prerequisite: 'Requires a 7-digit MFD wilayah code from list_simdasi_provinces,' which tells the agent how to obtain the input. It does not explicitly mention alternative tools or exclusions, but the context is clear for the intended use case.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the tool's purpose ('List') and does not mention any additional behaviors such as pagination, ordering, result format, or that it is a read-only operation.

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 concise sentence that starts with the core action and resource, then adds necessary details. Every word earns its place, with no filler 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?

The description is minimally sufficient for a simple list tool with fully documented parameters, but it lacks any mention of return values or behavior. Given the absence of an output schema and annotations, a bit more context could improve completeness.

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 already describes both parameters in detail. The description repeats the same information (e.g., '7-digit MFD' and 'from list_simdasi_subjects') without adding new semantic value, so the 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 explicitly states that this tool lists SIMDASI tables filtered by area and subject, which clearly distinguishes it from broader siblings like list_simdasi_tables. The verb 'List' plus the resource and filter criteria make the purpose specific and unambiguous.

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 clearly communicates the required inputs (wilayah and id_subjek) and implies the tool should be used when these are known. However, it does not name alternatives or explicitly state when not to use it, so it falls short of full 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?

With no annotations provided, the description carries the transparency burden. The statement about static tables containing pre-formatted HTML data gives a hint about output format, but it does not disclose pagination behavior, whether the list returns metadata or actual table content, or any default behaviors (e.g., default domain '0000'). It adds some context but remains incomplete.

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 exceptionally concise: two sentences that immediately convey the core purpose. No wasted words, and the verb-first structure is clear and scannable.

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

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

The tool lacks an output schema and annotations, so the description is the only source of context. It fails to explain what fields are returned in the list, whether pagination applies, or how the filter parameters affect results. Given the 5 optional parameters and no output schema, the description is insufficiently complete for an agent to fully anticipate tool behavior.

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 all five parameters, achieving 100% coverage. The description does not add any extra meaning beyond the schema, so the baseline score of 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 function with a specific verb and resource: 'List BPS static tables.' It also distinguishes the resource from other table types (e.g., SIMDASI tables) and adds context that static tables are pre-formatted HTML, which differentiates from alternative list 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 verb 'List' implies usage for browsing static tables, and the mention of filters in the schema indicates potential uses. However, there is no explicit guidance on when to use this tool versus alternatives like 'get_static_table' or other 'list_*' tools, nor any when-not-to-use 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?

With no annotations, the description carries the transparency burden. It discloses that data is 'latest headline data' and includes 'the latest value', setting expectations for a non-historical summary list. It doesn't mention pagination or domain/region mapping, but for a read-only list tool this is reasonably 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 is three short, information-dense sentences: purpose, usage guidance, and an alternative for historical data. No redundancy or filler, and the purpose 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 list tool with no output schema and no annotations, the description covers the essential behavioral aspects: what it lists, when to use it, what data to expect (latest value), and alternatives for history. It doesn't specify output structure or how a region maps to parameters, which is a minor gap but overall adequate.

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

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

Schema description coverage is 100%, with each parameter (var, page, domain) having a description. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 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 lists BPS strategic indicators with specific examples (inflation, GDP, poverty) and emphasizes 'latest headline data', which distinguishes it from historical-data tools like find_data/get_dynamic_data. The verb 'List' and resource 'BPS strategic indicators' are specific.

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 explicitly says to use this tool for a quick summary of key indicators for a region, and directs users needing multi-year historical data to find_data or get_dynamic_data. This provides clear when-to-use and when-not-to-use guidance with named alternatives.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation ('List') but doesn't mention pagination, sorting, output format, or any constraints. The second sentence is definitional, not behavioral.

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 short sentences, no waste. The first word is the verb ('List'), and the second sentence adds useful context about category semantics. Every part 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 simple list tool with one optional parameter, the description covers the basic function but lacks context about the domain parameter's effect, relationships to numerous sibling list tools, and return value details. Since there is no output schema, more behavioral context would be valuable.

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 schema description covers the sole 'domain' parameter (BPS domain code, default '0000'), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already 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 uses a specific verb ('List') and resource ('BPS statistical subject categories'), and adds a clarifying note that categories group related subjects. It doesn't explicitly distinguish from sibling tools like list_csa_categories or list_subjects, but the resource is specific enough to be 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?

No guidance is provided on when to use this tool versus alternative list tools. The optional domain parameter's filtering role is not mentioned, and no exclusions or alternatives are given, leaving the agent without context for selection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'list' implies a read-only operation, which is a positive signal, and the description adds context about what subjects are. However, it does not mention pagination, potential errors, or access limitations, which would be useful for a full behavioral picture.

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 just two sentences, front-loaded with the core purpose and followed by a clarifying definition. Every word adds value, and it is appropriately sized for the tool's simplicity.

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?

As a simple list tool without an output schema, the description adequately covers purpose, scope, and examples. It is sufficient for an agent to select and invoke the tool correctly, especially given strong schema coverage. Minor gaps like return format and edge cases are not critical here.

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

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

Schema description coverage is 100%, with clear descriptions for domain and subcat params. The description reinforces the domain concept with examples but does not add any new parameter-level detail beyond what the schema already provides, so it stays at the baseline 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 lists BPS statistical data subjects for a given domain, using a specific verb and resource. It distinguishes from sibling tools like list_csa_subjects and list_simdasi_subjects by specifying 'BPS' and provides concrete examples of content.

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 a clear context by specifying subjects are for a given domain, implying usage when domain-specific subject lists are needed. It does not explicitly name alternatives, but the 'BPS' qualifier differentiates it from similar sibling tools. The schema's note to use resolve_domain adds indirect 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 are provided, so the description must convey behavior. It states this is a list operation and implies read-only, but does not clarify the exact output structure (e.g., list of strings vs. objects) or the effect of the optional domain parameter default. The examples hint at content but not the response envelope.

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 plus examples, with no wasted words. It is front-loaded with the core action and resource, making it easy to scan and understand.

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 optional parameter and no output schema, the description provides the essential purpose and examples of the expected unit values. It does not specify the exact JSON response format, but the list nature and examples make it adequate for basic invocation.

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

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

The only parameter 'domain' is already well-described in the schema as a BPS domain code with a default of '0000'. The description adds that units are domain-scoped but provides no additional syntax or format details. With 100% schema coverage, the baseline score of 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 that the tool lists data units for a given domain, with concrete examples (Person, Percent, Rupiah). This distinguishes it from sibling list tools like list_census_areas or list_variables, making the purpose unambiguous.

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 clearly indicates the intended use case—retrieving available measurement units for a specific domain. It does not explicitly mention alternatives or exclusion criteria, but the examples and domain scoping make it clear when to use this tool versus other list 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 fails to disclose any behavioral traits such as whether results are paginated (despite a page parameter), the output format, or that it is a read-only operation. The description only adds domain context, not behavioral 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, front-loaded with the action ('List data variables'), and contains no filler. Every word adds value, earning top score for conciseness.

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

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

Given 4 optional parameters, no output schema, and no annotations, the description does not provide enough context about how this tool fits into the broader API. It lacks any mention of pagination behavior, relationships to the many sibling list tools (e.g., list_vertical_variables), or what the response might look like. The comprehensive schema partially compensates, but the description is too thin to be considered 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?

The input schema has 100% description coverage for all four parameters (page, year, domain, subject), so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, so no extra credit is warranted.

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