BPS MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation4/5
Most tools have distinct purposes, with clear separation between data retrieval (e.g., get_dynamic_data, get_static_table), listing operations (e.g., list_variables, list_periods), and search functions (e.g., allstats_search, search). However, some overlap exists between allstats_search and search, as both handle search functionality with different backends, which could cause minor confusion.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures. Verbs like 'get', 'list', 'search', and 'resolve' are used predictably across tools, making the set easy to navigate and understand.
Tool Count3/5
With 34 tools, the count is on the high side for a single server, potentially overwhelming for agents. While the domain (BPS statistical data) is broad, the tools cover many specific operations, but it might benefit from consolidation or better categorization to reduce complexity.
Completeness5/5
The tool set provides comprehensive coverage for accessing BPS statistical data, including data retrieval (dynamic/static tables, trade data), metadata listing (variables, periods, subjects), search capabilities, and auxiliary functions (cache clearing, domain resolution). No obvious gaps are present for the intended domain.
Average 3/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on June 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 what the tool does (listing subjects) without any information about permissions, rate limits, pagination, or response format. For a tool with no annotation coverage, this is a significant gap, as it doesn't help the agent understand how to handle the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that directly states the tool's purpose. It's appropriately sized and front-loaded with the core functionality. There's no wasted text, but it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of listing subjects with filtering parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what CSA subjects are, how the output is structured, or any behavioral aspects like error handling. For a tool with two parameters and no structured support, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('domain' and 'subcat') fully described in the input schema. The description mentions 'domain dan kategori tertentu' (specific domain and category), which aligns with the parameters but adds no additional meaning beyond what the schema provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as listing CSA subjects for specific domain and category, which is clear but vague. It uses the verb 'Daftar' (list) with the resource 'subjek CSA', but doesn't specify what CSA subjects are or how they differ from similar resources like 'list_subjects' or 'list_csa_categories' among the sibling tools. The purpose is understandable but lacks specificity about the nature of CSA subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools like 'list_subjects', 'list_csa_categories', and 'get_csa_table', there's no indication of how this tool differs or when it should be preferred. The mention of 'domain dan kategori tertentu' (specific domain and category) implies filtering, but no explicit usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing for a domain and subject but fails to disclose critical behaviors: whether it's paginated (implied by 'page' parameter but not stated), what the output format is, rate limits, or authentication needs. This leaves significant gaps for a tool with three parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that directly states the purpose. It's front-loaded with no wasted words, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and three parameters, the description is incomplete. It doesn't explain what CSA tables are, the return format, pagination behavior, or error handling. For a list operation with filtering, this leaves the agent under-informed about how to interpret results or handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters. The description adds minimal value by implying domain and subject are used for filtering, but doesn't explain semantics beyond what the schema provides (e.g., what 'domain' or 'subject' mean in context). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Daftar tabel CSA untuk domain dan subjek tertentu' clearly states the action (list) and resource (CSA tables) with scope (domain and subject), which is adequate. However, it doesn't differentiate from sibling tools like 'list_static_tables' or 'get_csa_table', leaving ambiguity about what makes CSA tables unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'list_static_tables' and 'get_csa_table', the description lacks any indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool lists derived variables but fails to describe key behaviors like whether it's a read-only operation, if it requires authentication, rate limits, or pagination. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, consisting of a single sentence with an example. It's front-loaded with the main purpose, though it could be slightly more structured by explicitly stating the verb. There's no wasted text, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, and usage context, which are crucial for an agent to effectively invoke this tool. The minimal description doesn't compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (domain and var). The description adds no additional meaning about the parameters beyond what the schema provides, such as explaining the examples in context. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists derived/aggregated categories with examples (total, average), which clarifies the resource type. However, it doesn't specify the verb precisely (e.g., 'retrieve' or 'fetch') or differentiate from sibling tools like 'list_variables' or 'list_vertical_variables', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'list_variables' or 'list_vertical_variables'. The description only states what it does, not the context or prerequisites for its use, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the resource (infographics) but does not disclose behavioral traits such as whether the operation is read-only, pagination behavior (implied by the 'page' parameter but not explained), rate limits, authentication needs, or what the output looks like. This leaves significant gaps for an agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the purpose and define infographics, with no wasted words. However, it could be more front-loaded by immediately clarifying the listing scope or differentiating from siblings, which would improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a listing tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., pagination, rate limits), output format, and differentiation from sibling tools, making it inadequate for an agent to fully understand how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters ('domain', 'keyword', 'page') with descriptions. The description does not add any meaning beyond what the schema provides, such as explaining how parameters interact (e.g., 'keyword' filters results) or providing examples. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists infographics from BPS and defines what infographics are ('visualisasi data statistik yang mudah dipahami'), which clarifies the resource. However, it lacks specificity about the listing scope (e.g., all infographics, filtered) and does not differentiate from sibling tools like 'get_infographic' (which likely retrieves a specific infographic) or 'search' (which might handle broader queries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention sibling tools such as 'get_infographic' for retrieving a specific infographic or 'search' for broader queries, nor does it specify prerequisites or exclusions. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions that publications contain analysis and reports, but fails to describe key behaviors like pagination (implied by the 'page' parameter), rate limits, authentication needs, or what the output looks like (e.g., list format, error handling). This leaves significant gaps for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences that are front-loaded, stating the tool's purpose efficiently. There's no wasted text, but it could be more structured by explicitly mentioning filtering or pagination to improve clarity without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like pagination or output format, nor does it differentiate from siblings, making it inadequate for an agent to fully understand how to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 5 parameters with descriptions. The description adds no additional meaning about parameters, such as how 'domain', 'keyword', or 'year/month' interact in filtering. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists BPS publications containing deep analysis and statistical reports, which clarifies the resource (publications) and their content. However, it uses vague language ('Daftar publikasi BPS' translates to 'List BPS publications') without specifying how it differs from sibling tools like 'get_publication' or 'search', making it unclear about its unique scope or filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'get_publication' (likely for single publications) and 'search' (possibly broader searches), the description lacks context on this tool's specific use cases, such as whether it's for browsing all publications or filtered lists, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the basic action ('list') without detailing permissions, rate limits, output format, pagination, or error handling. This is inadequate for a tool with parameters and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, output, and usage context, leaving significant gaps for an AI agent to understand how to invoke and interpret results effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with parameters 'domain' and 'var' documented in the schema. The description adds no additional meaning about parameters beyond implying 'var' is required for listing derived periods, so it meets the baseline of 3 without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Daftar turunan periode untuk variabel tertentu' (List derived periods for a specific variable) states the basic purpose with a verb ('list') and resource ('derived periods'), but it's vague about what 'derived periods' means and doesn't distinguish this tool from sibling tools like 'list_periods' or 'list_variables'. It provides minimal differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, context, or exclusions, and with sibling tools like 'list_periods' and 'list_variables' available, there's no indication of how this tool differs in usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions retrieving HTML content, which is useful, but doesn't cover other traits such as whether this is a read-only operation, potential rate limits, error handling, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that front-loads the purpose ('Ambil detail satu tabel CSA') and includes an important detail about HTML content. It avoids unnecessary words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimally adequate for a simple retrieval tool with two well-documented parameters. However, it lacks details on output format beyond 'HTML', error cases, or integration with sibling tools, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('domain' and 'id') adequately. The description implies these parameters are used to fetch a specific table but doesn't add meaning beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ambil detail' meaning 'Get details') and resource ('satu tabel CSA'), specifying it retrieves a single CSA table with HTML content. However, it doesn't explicitly differentiate from sibling tools like 'get_static_table' or 'list_csa_tables', which might handle similar data but with different scopes or formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention how it differs from 'get_static_table' or 'list_csa_tables', nor does it specify prerequisites like needing a valid domain and ID from other tools. The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that details include 'deskripsi lengkap dan link download' (full description and download link), which adds some context about return content. However, it lacks critical information such as whether this is a read-only operation, error handling, authentication needs, rate limits, or data format specifics, which are essential for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a detail-retrieval tool with 2 required parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain the return structure (beyond mentioning description and download links), error cases, or how to obtain the required inputs. For a tool without structured output documentation, more behavioral and usage context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('domain' and 'id') well-documented in the schema. The description doesn't add any additional meaning or examples beyond what the schema provides (e.g., it doesn't clarify what 'domain' codes are or where to get the 'id'). Since the schema does the heavy lifting, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ambil detail' meaning 'Get details') and the resource ('satu infografis BPS' meaning 'one BPS infographic'), making the purpose evident. It distinguishes from sibling tools like 'list_infographics' by focusing on a single item rather than listing. However, it doesn't explicitly differentiate from other detail-retrieval tools (e.g., 'get_publication'), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing domain and ID from 'list_infographics'), exclusions, or comparisons to similar tools like 'get_publication' or 'get_static_table'. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it retrieves details but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, response format, or whether it's a read-only operation. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence in Indonesian that directly states the tool's purpose. No wasted words or unnecessary elaboration. The description is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what details are returned, the response format, error handling, or authentication requirements. The agent would need to guess about the tool's behavior and output based on minimal information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional meaning about the parameters beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting, though the description could have explained the relationship between domain and ID or provided examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ambil detail' - Get details) and resource ('satu berita dari website BPS' - one news item from BPS website). It distinguishes from sibling 'list_news' which presumably lists multiple news items rather than getting details of one. However, it doesn't specify what details are retrieved or the format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for retrieving details of a specific news item, but doesn't mention prerequisites (like needing to know domain and ID first), nor does it reference the 'list_news' sibling tool that might help identify items to retrieve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it retrieves details but doesn't describe what 'details' include, error handling, authentication needs, rate limits, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. It's front-loaded with the core action and resource, with no wasted words. However, it could be slightly more structured by explicitly mentioning parameters, but this isn't required for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 2 required parameters. It doesn't explain what details are returned, error conditions, or how it differs from similar tools. For a read operation in a context-rich server with many siblings, more guidance is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('domain' and 'id') documented in the schema. The description implies these are needed to fetch a specific press release but adds no additional meaning beyond what the schema provides (e.g., format examples or domain/ID relationships). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ambil detail' meaning 'Get details') and resource ('satu Berita Resmi Statistik (BRS) dari BPS' meaning 'one Official Statistics News from BPS'). It's specific about retrieving a single press release by ID and domain. However, it doesn't explicitly differentiate from sibling tools like 'get_news' or 'list_press_releases', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools like 'list_press_releases' for browsing or 'get_news' for other news types, nor does it specify prerequisites or exclusions. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('ambil detail' suggests retrieval) but doesn't explicitly state it's non-destructive or confirm read-only behavior. It also lacks details on authentication needs, rate limits, error handling, or response format, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource. However, it could be slightly more structured by explicitly mentioning it's for retrieving details of a single publication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details, usage context, and output information. Without annotations or output schema, the agent must rely on the name and schema alone, leaving gaps in understanding how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('domain' and 'id') documented in the schema. The description doesn't add any semantic details beyond what the schema provides, such as explaining what a 'domain' represents or how to obtain an 'id'. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('ambil detail' meaning 'retrieve details') and resource ('satu publikasi BPS' meaning 'one BPS publication'), making the purpose understandable. It distinguishes from sibling tools like 'list_publications' by specifying retrieval of a single publication's details rather than listing. However, it doesn't explicitly contrast with other detail-retrieval tools if they exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites like needing a publication ID from 'list_publications', nor does it differentiate from other retrieval tools like 'get_static_table' or 'get_infographic'. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool retrieves data (implying read-only) and mentions the data includes value and volume, but doesn't cover important aspects like authentication requirements, rate limits, error conditions, response format, or whether the data is real-time/historical. This leaves significant gaps for an agent to understand how to interact with it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. However, the second sentence ('Data mencakup nilai dan volume perdagangan Indonesia.') could be integrated more smoothly, and there's room to add brief usage context without sacrificing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 required parameters, no annotations, no output schema), the description is moderately complete. It states the purpose and data scope but lacks behavioral details (e.g., response format, error handling) and usage guidelines. For a data retrieval tool with multiple parameters, more context would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics beyond the schema. It mentions data is based on HS code and includes value and volume, which aligns with the 'hs_code' parameter, but doesn't provide additional context for 'source', 'hs_type', 'year', or 'period'. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ambil data perdagangan luar negeri (ekspor/impor) berdasarkan kode HS' (Retrieve foreign trade data (export/import) based on HS code). It specifies the resource (foreign trade data) and scope (Indonesia), but doesn't explicitly differentiate from sibling tools like 'get_static_table' or 'get_dynamic_data' that might also retrieve trade data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention sibling tools like 'get_static_table' or 'get_dynamic_data' that might offer similar data, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 what the tool does (list categories) without any information about permissions, rate limits, output format, pagination, or error handling. For a tool with no annotations, this is insufficient to inform the agent about how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one explaining CSA. Both sentences are relevant, with no wasted words. However, it could be more front-loaded by placing the explanation of CSA after the core purpose to improve clarity for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks usage guidelines, behavioral details, and output information. While the purpose is clear, the overall context for an agent to effectively use this tool is insufficient, especially compared to siblings that might have overlapping functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'domain' documented as 'Kode domain BPS'. The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar kategori CSA (Classification of Statistical Activities) BPS' translates to 'List CSA categories of BPS', specifying the verb (list) and resource (CSA categories). It distinguishes from siblings like 'list_csa_subjects' or 'list_csa_tables' by focusing on categories. However, it doesn't explicitly differentiate from all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention when to use 'list_csa_categories' instead of 'list_csa_subjects', 'list_csa_tables', or other listing tools. There's no context about prerequisites, exclusions, or typical use cases, leaving the agent without operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool is 'useful for understanding definitions', which implies a read-only, informational operation, but doesn't specify whether it's safe (non-destructive), what authentication might be required, rate limits, pagination behavior (implied by the 'page' parameter but not explained), or error handling. The description adds some context about the glossary's purpose but lacks critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and utility. There's no unnecessary information or repetition. However, it could be slightly more structured by explicitly mentioning the parameters or usage context, but it's efficient as is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search tool with 3 parameters), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and utility but lacks details on behavior, output format, or error handling. The schema provides parameter documentation, but the description doesn't fill gaps in behavioral transparency or usage guidelines, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters (domain, keyword, page) with descriptions. The description doesn't add any additional meaning or clarification about these parameters beyond what's in the schema (e.g., it doesn't explain what 'domain' codes represent or how 'keyword' searches work). With high schema coverage, the baseline is 3, and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cari istilah di glosarium statistik BPS' (Search for terms in the BPS statistical glossary). It specifies the resource (BPS statistical glossary) and the action (search for terms/definitions). However, it doesn't explicitly differentiate from sibling tools like 'search' or 'allstats_search', which might also search BPS data but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'Berguna untuk memahami definisi dan pengertian indikator statistik' (Useful for understanding definitions and meanings of statistical indicators). This implies the tool is for glossary lookups, but it doesn't specify when to use this versus alternatives like 'search' or 'allstats_search', nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the source (BPS website) and scope (general news vs. BRS), but lacks critical details like whether this is a read-only operation, pagination behavior, rate limits, authentication needs, or what the output format looks like. For a tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence, with no wasted words. It efficiently states the purpose and key distinction. However, it could be slightly improved with more structured guidance, but it's appropriately sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It covers the basic purpose and scope but misses behavioral details and usage context. It's minimally adequate but has clear gaps, especially for a tool without structured safety or output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters (domain, keyword, page). The description doesn't add any meaning beyond what's in the schema, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar berita dari website BPS' (List news from the BPS website). It specifies the resource (news) and distinguishes it from BRS (Berita Resmi Statistik) by noting this is general BPS news. However, it doesn't explicitly differentiate from sibling tools like 'get_news' or 'get_press_release', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance by contrasting with BRS, but it doesn't specify when to use this tool versus alternatives like 'get_news' or 'search'. There's no explicit context for when or when not to use it, nor any mention of prerequisites or alternatives, leaving the agent with insufficient direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes a read-only listing operation but does not cover important aspects such as authentication requirements, rate limits, pagination, error handling, or the format of returned data. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and the types of periods. There is no wasted language, though it could be slightly more informative without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., list format, data structure) or address behavioral aspects like error conditions. For a tool with no structured metadata, the description should provide more context to be fully helpful to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters ('domain' and 'var'). The description does not add any semantic details beyond what the schema provides, such as explaining what a 'domain' or 'var' represents in context. However, with high schema coverage, a baseline score of 3 is appropriate as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar periode data yang tersedia untuk variabel tertentu' (List data periods available for a specific variable). It specifies the verb ('list') and resource ('periods'), and mentions the types of periods (year, semester, quarter, month). However, it does not explicitly differentiate from sibling tools like 'list_derived_periods' or 'list_variables', which reduces clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, exclusions, or compare it to similar tools like 'list_derived_periods' or 'list_variables'. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool lists press releases but provides no behavioral details about pagination (implied by 'page' parameter), rate limits, authentication requirements, response format, or whether this is a read-only operation. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences that efficiently convey the core purpose. There's no wasted language, though it could be slightly more informative given the lack of annotations. The structure is straightforward and front-loaded with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the return values look like (list format, fields included), pagination behavior, or any constraints. For a tool with 5 parameters and multiple sibling alternatives, more contextual information would be helpful for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. With complete schema coverage, the baseline score of 3 is appropriate since the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing official statistical press releases (Berita Resmi Statistik) from BPS. It specifies the resource (BRS) and that these contain the latest official data releases. However, it doesn't differentiate from sibling tools like 'get_press_release' or 'list_news' which might handle similar content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With sibling tools like 'get_press_release' (singular) and 'list_news' available, the description offers no comparison or context about when this list-focused tool is appropriate versus other press release or news-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output format ('HTML') which is useful, but doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires authentication, pagination behavior (implied by 'page' parameter but not explained), rate limits, or error conditions. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence that directly states the tool's purpose. It's front-loaded with the main function. However, it could be slightly more structured by explicitly mentioning it's a listing/filtering operation rather than just describing what static tables are.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficient. It doesn't explain the tool's behavior, output format details beyond 'HTML', error handling, or how to interpret results. The agent would struggle to use this effectively without trial and error or external knowledge about BPS data structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain how parameters interact (e.g., combining domain, keyword, year, month filters) or provide examples. Baseline 3 is appropriate when schema does the documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing static BPS tables that contain HTML-formatted data. It specifies the resource ('tabel statis BPS') and the output format ('HTML'), but doesn't distinguish it from sibling tools like 'get_static_table' or 'list_csa_tables' which might handle similar data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling tools for listing/searching different data types (e.g., 'list_csa_tables', 'list_publications', 'search'), the description offers no context about when this specific static table listing is appropriate versus other listing or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it indicates this is a listing operation (implied read-only), it doesn't mention pagination behavior (though the schema has a 'page' parameter), rate limits, authentication requirements, or what format the results will be in. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - two sentences that directly state the tool's purpose and provide concrete examples. The first sentence clearly identifies the resource, and the second adds useful context about what strategic indicators include. There's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 3 parameters and 100% schema coverage but no annotations or output schema, the description provides adequate basic context about what's being listed. However, it doesn't address important behavioral aspects like pagination, result format, or how the parameters interact. The examples help, but more complete guidance would be beneficial given the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters (domain, var, page). The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar indikator strategis BPS' (List strategic indicators of BPS) and provides examples of what these indicators include (economic growth, inflation, unemployment, poverty). This distinguishes it from other list_* tools that focus on different data types like census events, publications, or variables. However, it doesn't explicitly contrast with similar tools like list_variables or list_vertical_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple list_* tools in the sibling set (list_variables, list_vertical_variables, list_subjects, etc.), but the description doesn't explain how strategic indicators differ from these other data types or when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it lists data units but doesn't disclose behavioral traits like whether it's read-only, paginated, rate-limited, or requires authentication. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose in the first sentence and providing examples in the second. Both sentences earn their place by clarifying the tool's function, though it could be slightly more structured (e.g., explicitly stating it's a read operation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, fields), behavioral constraints, or error conditions. For a tool in a server with many list_* siblings, more context is needed to distinguish and use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one parameter 'domain' documented as 'Kode domain BPS'. The description adds minimal value beyond this, mentioning 'domain tertentu' (specific domain) but not elaborating on semantics. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar satuan data' (List data units) with examples provided (Jiwa, Persen, Rupiah). It specifies the resource (data units) and context (used in a specific domain), though it doesn't explicitly differentiate from sibling tools like list_variables or list_subjects, which list different types of resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions 'di domain tertentu' (in a specific domain), implying context, but doesn't specify prerequisites, exclusions, or compare it to other list_* tools. Without this, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does (lists variables) without mentioning whether it's read-only, paginated, rate-limited, requires authentication, or what the output format looks like. The description lacks critical behavioral context needed for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function. The first sentence states the core purpose, and the second provides helpful examples. There's no wasted verbiage, though it could be slightly more structured with explicit usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. While it states the basic purpose, it lacks critical information about behavioral traits, output format, pagination behavior, and differentiation from similar tools. For a tool with 4 parameters and multiple sibling tools, more contextual information would be needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all four parameters with descriptions. The tool description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing data variables in BPS dynamic tables. It specifies the resource (variables) and provides examples (Population Count, Poverty Rate), which helps distinguish it from generic list tools. However, it doesn't explicitly differentiate from sibling tools like list_derived_variables or list_vertical_variables, which appear to serve similar listing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like list_derived_variables or list_vertical_variables, nor does it explain prerequisites, filtering logic, or appropriate contexts for use. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes a read operation ('list'), which implies it's non-destructive, but doesn't address other behavioral aspects like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of one clear sentence stating the purpose followed by examples. There's no wasted text or redundancy. However, it could be slightly improved by structuring it to explicitly separate purpose from examples, but it's already efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, and output. Without annotations or an output schema, the agent must infer these aspects, making the description incomplete for optimal tool invocation. It meets the minimum viable standard but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('domain' and 'var') documented in the schema. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't clarify what 'vertical variables' means in relation to the 'var' parameter). According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar variabel vertikal (breakdown/disaggregasi) untuk variabel tertentu' (List vertical variables/breakdowns/disaggregations for a specific variable). It specifies the verb ('list') and resource ('vertical variables'), and provides concrete examples ('jenis kelamin, kelompok umur' - gender, age groups). However, it doesn't explicitly differentiate from sibling tools like 'list_variables' or 'list_derived_variables', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools like 'list_variables' (which might list all variables) or 'list_derived_variables' (which might list derived variables), nor does it specify prerequisites or exclusions. The only implied usage is for getting breakdowns of a specific variable, but this is basic and lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool returns table content in HTML format, which is useful context. However, it doesn't disclose other important traits like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what happens if parameters are invalid. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Indonesian that conveys the core purpose and key output format (HTML). It's front-loaded with the main action and includes no unnecessary words or redundant information. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is partially complete. It clearly states what the tool does and the output format, which is helpful. However, it lacks behavioral context (e.g., safety, errors) and usage guidance relative to siblings, making it inadequate for full understanding without additional exploration. The absence of an output schema means the description doesn't explain return values, but that's acceptable per the rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('domain' and 'id') fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain what 'domain' codes look like or where to find 'id' values). According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ambil detail' = 'Get details') and resource ('satu tabel statis BPS' = 'one BPS static table'), including that it returns table content in HTML format. It distinguishes from sibling tools like 'list_static_tables' (which lists tables) and 'get_csa_table' (which gets a different type of table). However, it doesn't explicitly contrast with all similar siblings like 'get_dynamic_data' or 'get_trade_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention when this tool is appropriate compared to siblings like 'get_csa_table' (for CSA tables) or 'get_dynamic_data' (for dynamic data), nor does it specify prerequisites or exclusions. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'list' implies a read operation, the description doesn't mention authentication requirements, rate limits, pagination behavior, or what happens when the optional domain parameter is omitted. For a tool with no annotation coverage, this is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences in Indonesian that directly state what the tool does. Every word earns its place with no wasted text, and the purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description is minimally adequate. However, with no annotations and many similar sibling tools, it should provide more context about when to use it and what the output looks like. The description covers basic purpose but lacks important contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the single 'domain' parameter with its default value. The description doesn't add any parameter-specific information beyond what's in the schema. With high 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar kategori subjek statistik BPS' (List BPS statistical subject categories) and explains that categories group related subjects. It uses a specific verb ('list') and identifies the resource ('subject categories'), but doesn't distinguish it from similar sibling tools like list_csa_categories or list_subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many similar list_* sibling tools (list_csa_categories, list_subjects, list_domains, etc.), there's no indication of when this specific subject category listing is appropriate versus other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing subjects with optional filtering by subcat, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what happens with invalid inputs. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first sentence with a clarifying example. No wasted sentences, though it could be slightly more structured by explicitly separating usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters, the description is incomplete. It lacks details on return values, error handling, and behavioral constraints, making it inadequate for a tool that likely returns a list of subjects. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (domain and subcat). The description adds minimal value by mentioning domain filtering and an example code, but doesn't provide additional semantics beyond what's in the schema, such as format details for subcat. Baseline 3 is appropriate as the schema handles most documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing statistical data subjects available in BPS for a specific domain, with examples of subjects like 'Kependudukan' (Population). It distinguishes itself from siblings like list_csa_subjects by specifying 'BPS' (Indonesia's statistics agency) and 'statistical data subjects,' but doesn't explicitly differentiate from all similar tools (e.g., list_census_topics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing subjects for a domain, with a hint to use resolve_domain for domain codes, but lacks explicit guidance on when to choose this over alternatives like list_csa_subjects or list_census_topics. No exclusions or clear alternatives are stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fallback behavior to AllStats Search Engine, which is useful. However, it lacks details on permissions, rate limits, response format, pagination, or error handling, leaving significant gaps for a search tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently convey the tool's purpose and fallback mechanism. It's front-loaded with the main function and avoids unnecessary details, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It covers the search scope and fallback but misses critical behavioral aspects like response format, error handling, and usage context compared to siblings. For a search tool with 4 parameters and no structured safety info, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds minimal value by mentioning search across types and fallback, but doesn't elaborate on parameter usage beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across data types in BPS using WebAPI with fallback to AllStats Search Engine. It specifies the verb 'search' and resource 'data across types' but doesn't explicitly differentiate from sibling tools like 'allstats_search' or 'allstats_deep_search' beyond mentioning fallback behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-type searches and mentions automatic fallback to AllStats Search Engine when WebAPI yields no results. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'allstats_search' or specific get_* tools, nor does it specify exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it states the tool clears cache and explains why you'd use it, it doesn't disclose important behavioral traits: whether this operation requires special permissions, if it affects all users or just the caller, what happens during execution (immediate vs background), potential performance impact, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a clear purpose: the first states what the tool does, the second explains when to use it. There's no wasted text, and the information is front-loaded. The only minor issue is that it could be slightly more structured, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (cache clearing) with no annotations and no output schema, the description is minimally adequate but has clear gaps. It explains the purpose and basic usage context, but doesn't provide important details about behavioral characteristics, permissions, scope of effect, or response format. For a tool that presumably modifies system state, more contextual information would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain any parameters, which is appropriate. The baseline for 0 parameters is 4, as there's no parameter documentation burden. The description correctly focuses on the tool's purpose rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bersihkan cache data BPS' (Clear BPS data cache) with the goal 'memastikan data terbaru diambil langsung dari API' (to ensure the latest data is fetched directly from the API). It uses a specific verb ('bersihkan' - clear/clean) and identifies the resource ('cache data BPS'). However, it doesn't explicitly differentiate from sibling tools, which are mostly data retrieval tools rather than cache management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Berguna jika ingin memastikan data terbaru diambil langsung dari API' (Useful if you want to ensure the latest data is fetched directly from the API). This suggests when to use it (when you suspect cached data might be stale), but doesn't explicitly state when NOT to use it or mention alternatives. No explicit comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the tool's purpose and prerequisites, but doesn't describe what the tool returns (data format, structure), error conditions, rate limits, authentication requirements, or any other behavioral characteristics. This leaves significant gaps for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve clear purposes: stating the tool's function and providing usage guidance. It's front-loaded with the core purpose. No wasted words, though it could potentially be structured more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what kind of data is returned, the response format, error handling, or any behavioral characteristics. The guidance about prerequisite tools is helpful but insufficient for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ambil data dari tabel dinamis BPS' (Get data from BPS dynamic tables) and identifies it as the main tool for statistical data. However, it doesn't explicitly differentiate from siblings like 'get_static_table' or 'get_csa_table' beyond calling itself the 'main' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool ('untuk mendapatkan data statistik' - for getting statistical data) and references two specific sibling tools ('list_variables' and 'list_periods') as prerequisites for finding required parameter values. It doesn't explicitly state when NOT to use it or mention alternatives like 'get_static_table'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool lists census activities and that the output includes IDs for subsequent use, but doesn't describe return format, pagination, rate limits, authentication requirements, or error behavior. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences that each earn their place. The first sentence states the core purpose, the second provides crucial usage context. There's zero wasted language, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and hints at how the output is used, but doesn't describe the return format or structure. For a list operation that presumably returns multiple items, more detail about the response would be helpful despite the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It earns a baseline 4 for not needing to compensate for parameter documentation gaps, though it doesn't add value beyond the schema (which already shows no parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar kegiatan sensus BPS' (List BPS census activities) with examples of specific census types. It uses a specific verb ('Daftar' - List) and identifies the resource (census activities). However, it doesn't explicitly differentiate from sibling tools like 'list_census_topics' or other list_* tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'Gunakan ID kegiatan untuk mengambil topik dan data sensus' (Use activity ID to retrieve topics and census data), suggesting this tool is a prerequisite for other operations. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_census_topics' or 'list_subjects', nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states what the tool does (list topics) and a prerequisite. It doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what the output format looks like. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured in just two sentences. The first sentence states the purpose, and the second provides essential prerequisite guidance. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single required parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and prerequisite but lacks behavioral context and output details. Without annotations or output schema, the description should do more to explain what the tool returns and its operational characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'kegiatan' fully documented in the schema as 'ID kegiatan sensus (dari list_census_events).' The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar topik data yang tersedia untuk kegiatan sensus tertentu' (List data topics available for a specific census activity). It uses a specific verb ('list') and resource ('data topics'), but doesn't explicitly differentiate from sibling tools like 'list_census_events' beyond mentioning it as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for listing data topics for a specific census activity. It explicitly mentions the prerequisite to 'use list_census_events to get the activity ID,' which is helpful guidance. However, it doesn't specify when NOT to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions the tool doesn't require an API key (useful auth context) and positions it as a fallback alternative to WebAPI search. However, it doesn't describe pagination behavior (implied by 'page' parameter but not explained), rate limits, error conditions, or what the search results look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences that efficiently communicate the tool's purpose, scope, and key usage context. Every word earns its place with no wasted text. It's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 8 parameters, 100% schema coverage, and no output schema, the description provides adequate context about what it searches and when to use it. However, without annotations or output schema, it should ideally describe the result format, pagination behavior, or error handling to be more complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 8 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline is 3 when the schema does the heavy lifting, though the description could have explained how parameters interact (e.g., content filtering with domain/year constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches BPS content through the AllStats Search Engine and lists the content types it covers (publications, tables, press releases, etc.). It distinguishes this as a general search tool but doesn't explicitly differentiate it from the sibling 'search' tool, which appears to be a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good usage context: it's useful for discovery, finding publications, or as an alternative/fallback to WebAPI search. It also mentions it doesn't require an API key. However, it doesn't explicitly state when to use this versus the sibling 'search' tool or other content-specific 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.
Behavior2/5
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 mentions support for fuzzy matching, which adds some behavioral context, but lacks details on permissions, rate limits, error handling, or what happens if no match is found. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes essential details about input support. There is no wasted language, and every part contributes directly to understanding the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and input semantics well, but lacks details on output format, error cases, or behavioral constraints, which are important for a conversion tool with fuzzy matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the single parameter 'query'. The description adds value by specifying the types of inputs accepted (official names, abbreviations like 'Jatim', fuzzy matching), which clarifies semantics beyond the schema's example list. With only one parameter, the baseline is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting region names to BPS domain codes. It specifies the exact action ('Konversi') and resource ('nama wilayah ke kode domain BPS'), and distinguishes itself from siblings by focusing on domain resolution rather than searching, listing, or retrieving data like other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning support for official names, abbreviations, and fuzzy matching, suggesting it's for flexible domain lookup. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_domains' or 'search', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool 'Tidak memerlukan API key' (Doesn't require API key), which is useful behavioral context. However, it doesn't mention rate limits, pagination behavior (beyond the page parameter), error conditions, or whether this is a read-only operation. The description adds some value but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in four sentences: purpose, output format, prerequisite, and unique/authentication details. Every sentence adds value with zero waste. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description provides good purpose and usage context but lacks behavioral details about the search operation. It doesn't explain what the return structure looks like (beyond mentioning pages and snippets) or potential limitations. For a search tool with no output schema, more detail about result format would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters thoroughly. The description adds marginal value by reinforcing that publication_id comes from 'field deep_search_id di hasil allstats_search' and noting this searches 'di dalam isi PDF' (within PDF content). However, it doesn't provide additional semantic context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Full-text search di dalam isi PDF publikasi BPS' (full-text search within BPS publication PDF contents) and specifies it 'Mengembalikan halaman yang cocok beserta cuplikan teks' (returns matching pages with text snippets). It distinguishes from sibling 'allstats_search' by explaining this searches within PDF content while that tool likely searches metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: 'Dapatkan publication_id dari hasil allstats_search (field deep_search_id)' (Get publication_id from allstats_search results). It also notes 'Fitur unik — tidak tersedia di WebAPI' (Unique feature — not available in WebAPI). However, it doesn't explicitly state when NOT to use it or compare with other search-related siblings like 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 this is a read-only operation (listing data) but doesn't explicitly state it. The description adds some behavioral context by explaining the meaning of 'type' parameter values, which helps understand what data will be returned. However, it doesn't disclose other important traits like response format, pagination, rate limits, or authentication requirements, leaving gaps for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences in Indonesian. The first sentence states the purpose, and the second provides crucial usage guidance for the 'type' parameter. Every word serves a clear purpose with zero redundancy. It's front-loaded with the core functionality and follows with implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, enum-based filtering) and no annotations or output schema, the description is minimally adequate. It explains what the tool does and how to use the 'type' parameter but doesn't cover response format, error conditions, or relationship to other tools. For a listing tool with administrative data, more context about the returned data structure would be helpful, but the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 thoroughly. The description adds value by providing practical examples and clarifying the semantics of 'type' values in Indonesian context ('prov' for provinces, 'kab' for regencies). It also implicitly explains that 'prov' parameter is only needed for 'kabbyprov' type. This goes beyond the schema's technical descriptions, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Daftar domain/wilayah BPS (provinsi, kabupaten/kota)' which translates to 'List BPS domains/regions (provinces, regencies/cities)'. It specifies the verb ('list') and resource ('BPS domains/regions'), and distinguishes itself from siblings like 'resolve_domain' or 'search' by focusing on listing administrative divisions rather than resolving or searching content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use specific parameter values: 'Gunakan type='prov' untuk provinsi, 'kab' untuk semua kabupaten, 'kabbyprov' untuk kabupaten per provinsi' (Use type='prov' for provinces, 'kab' for all regencies, 'kabbyprov' for regencies per province). This clarifies the context for different filtering options. However, it doesn't mention when to use this tool versus alternatives like 'resolve_domain' or other list_* tools, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bps-mcp-server MCP server](https://glama.ai/mcp/servers/setiapam/bps-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/setiapam/bps-mcp-server)

Score Badge

Copy to your README.md:

[![bps-mcp-server MCP server](https://glama.ai/mcp/servers/setiapam/bps-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/setiapam/bps-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/setiapam/bps-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server