This server provides access to official Indonesian financial and statistical data from IDX, BPS, and KSEI, with full source citations and provenance tracking on every response.
IDX (Indonesia Stock Exchange)
List all IDX-listed issuers with sector, industry, and listing date.
Retrieve detailed company profiles including management and shareholder information.
Search official company announcements with direct attachment URLs.
Access financial report attachments (XLSX, PDF, XBRL ZIP, inline-XBRL ZIP) by ticker, year, and period.
Query and parse raw XBRL facts from official filings, including context periods, dimensions, units, and decimals.
BPS (Badan Pusat Statistik — Statistics Indonesia)
Browse official statistical subjects and variables. (requires a free BPS_API_KEY)
Retrieve dynamic statistical table time series by variable and period IDs.
KSEI (Central Securities Depository)
Access official investor-count (SID) growth series by month and metric.
Query investor demographic breakdowns by gender, age, education, job, or income.
Health Check
Verify the availability of all upstream data sources and BPS credential readiness.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Indonesia Financial Data MCP get company profile for BBCA"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Citation-first MCP server for official Indonesian financial data. It does not use Yahoo Finance or yfinance.
Provider | Coverage | Access |
IDX | Issuer directory, detailed company profile, management/shareholders, announcements, financial-report attachments (XLSX/PDF/XBRL) | Public web endpoints; session cookie initialized automatically |
BPS | Subjects, variables, dynamic statistical tables | Official WebAPI; requires free |
KSEI | SID growth and investor demographics | Public JSON endpoints |
Every successful response has:
{
"data": {},
"provenance": [
{
"provider": "IDX",
"source_url": "https://www.idx.co.id/...",
"retrieved_at": "2026-07-16T00:00:00+00:00",
"official": true,
"source_format": "json"
}
],
"warnings": [],
"meta": {}
}Credential values are redacted from provenance URLs.
Related MCP server: BPS MCP Server
idx_list_companies
idx_company_profile
idx_company_announcements
idx_financial_reports
idx_filing_facts
bps_list_subjects
bps_list_variables
bps_get_data
ksei_sid_growth
ksei_investor_demographics
source_health
See docs/SOURCES.md for source contracts and boundaries,
and docs/HERMES.md for Hermes registration and live checks.
python3 -m venv .venv
.venv/bin/pip install -e '.[dev]'Optional BPS setup:
Create a key at https://webapi.bps.go.id/developer/.
Export it as BPS_API_KEY or configure it in the MCP client's scoped environment.
Run over stdio:
.venv/bin/python -m indonesia_data_mcp.serverHermes registration (run from the repository root):
hermes mcp add indonesia-official \
--command "$PWD/.venv/bin/python" \
--args -m indonesia_data_mcp.serverIf BPS is enabled, add BPS_API_KEY to Hermes's secret environment rather than Markdown or command history.
Run the responsive evidence-first dashboard on the LAN:
.venv/bin/pip install -e '.[dashboard]'
.venv/bin/python -m dashboard --host 0.0.0.0 --port 8010Open http://localhost:8010. Official issuer, announcement, and filing data is
kept separate from clearly labelled in-memory demo workflow state. The dashboard
does not display unlicensed market prices or investment recommendations.
.venv/bin/pytest -qLive tests are separate so upstream availability cannot make the deterministic suite flaky.
idx_filing_facts resolves the requested IDX filing, downloads its official
instance.zip, verifies the ZIP, calculates SHA-256, and exposes its raw XBRL
facts with context periods, dimensions, units, decimals, and citations. Use the
optional concept substring to keep responses small—for example, Assets,
ProfitLoss, or InterestIncome.
The tool deliberately preserves the filing's taxonomy and raw values. It does not claim canonical cross-company normalization: concept names can vary by issuer profile and taxonomy version.
IDX's public endpoints are protected by Cloudflare. The client establishes a
normal IDX session and uses conservative pacing. If ordinary HTTP TLS is
rejected, it retries with browser-compatible TLS via curl_cffi; it does not
solve or bypass CAPTCHAs.
This MCP returns official source records and attachments. It can query raw
instance.zip XBRL facts, but canonical cross-company line-item
normalization remains a separate future layer.
OJK's public data portal and Bank Indonesia sources were investigated. Their browser-facing services require additional contract discovery and reliability work, so they are not falsely advertised as production-ready tools in v0.1.
Market-price data is not included: official IDX real-time/delayed market data is a licensed data product.
MIT
Read an official BPS dynamic-table series by variable and period IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| language | No | ind | |
| period_ids | Yes | ||
| variable_id | Yes | ||
| derived_period_ids | No | ||
| derived_variable_id | No | ||
| vertical_variable_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Read', implying read-only, but lacks details on side effects, auth requirements, rate limits, or return format. For a data retrieval tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with no filler. It is appropriately front-loaded but arguably too terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 7 parameters, no output schema, no annotations. Description fails to explain return structure, error conditions, or how to use non-required parameters. Highly incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 7 parameters with 0% description coverage. Description only mentions variable_id and period_ids, ignoring domain, language, derived_*, and vertical_variable_id. No explanation of default values, constraints, or usage for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Read', resource 'BPS dynamic-table series', and key parameters 'variable and period IDs'. It effectively distinguishes from sibling tools like bps_list_subjects and bps_list_variables, which are for listing metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for reading specific data series but provides no explicit guidance on when to use versus alternatives, no exclusions, and no context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official BPS statistical subjects. Requires BPS_API_KEY from the BPS developer portal.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| domain | No | ||
| language | No | ind | |
| subject_category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the authentication requirement but omits details like read-only nature, pagination behavior, or error responses. 'List' implies safety, but more explicit disclosure would raise the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste: first states purpose, second states authentication requirement. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is too minimal. It lacks parameter explanations, return value details, and usage context, making it insufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any parameters (page, domain, language, subject_category). For a tool with 4 parameters, this is a critical gap, leaving agents to guess parameter meanings from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and specific resource 'official BPS statistical subjects', making the tool's purpose distinct from siblings like 'bps_get_data' and 'bps_list_variables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or any exclusion criteria. The only context is the authentication requirement, which does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official BPS variables for a subject and domain.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| domain | No | ||
| language | No | ind | |
| subject_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral cues. It only states 'list', implying read-only, but does not disclose authentication needs, rate limits, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words) and front-loaded with purpose. However, conciseness sacrifices necessary detail, making it less useful overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no param descriptions, no output schema, and no annotations, the description is severely incomplete. It leaves the agent guessing about pagination, default values, domain meaning, and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for any of the 4 parameters. The words 'for a subject and domain' loosely map to subject_id and domain but provide no details on page, language, or allowed values. Fails to compensate for coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's action (list) and resource (official BPS variables) with scoping (subject and domain). It clearly differentiates from sibling tools like bps_get_data (retrieves data) and bps_list_subjects (lists subjects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. The description provides no help in tool selection beyond the basic verb-noun combination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search official IDX issuer announcements and return direct attachment URLs with citations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| ticker | No | ||
| date_to | No | ||
| language | No | id | |
| date_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Only states return of attachment URLs with citations. Missing behavioral traits such as read-only nature, authentication, rate limits, or behavior when no results found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. While efficient, it sacrifices necessary detail. Could be restructured to include key parameter hints without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is grossly incomplete. Missing pagination details, result format, and all parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description adds no meaning to parameters like ticker, date_from, date_to, language, limit, offset. Agent cannot infer date format, default language behavior, or how filtering works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search', resource 'IDX issuer announcements', and output 'direct attachment URLs with citations'. However, it does not distinguish from sibling tools like idx_financial_reports which may overlap in content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like idx_company_profile or idx_financial_reports. No context on prerequisites, limitations, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an official IDX issuer profile, management, and disclosed shareholder snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| language | No | id-id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not mention read-only nature, data freshness, rate limits, or any other behavioral traits. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the purpose. No redundant information. However, it could be slightly expanded to include parameter hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description is too brief. It does not specify the structure of the returned snapshot or edge cases. An output schema would help, but in its absence, the description should be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'ticker' parameter (required, with pattern) or the optional 'language' parameter (with enum). It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specifies the resources: IDX issuer profile, management, and disclosed shareholder snapshot. It distinguishes from sibling tools like idx_company_announcements and idx_financial_reports by focusing on a static snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as idx_list_companies or idx_company_announcements. No prerequisites or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find official IDX financial-report attachments (XLSX, PDF, XBRL ZIP, inline-XBRL ZIP).
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| limit | No | ||
| offset | No | ||
| period | No | audit | |
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavior such as authentication requirements, rate limits, or whether the tool performs a search or direct retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently communicates core purpose, front-loaded with action and resource; but lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description provides no information on return values, pagination, or parameter constraints, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds no explanation of any parameters (ticker, year, period, limit, offset), leaving agent without necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Find') and the resource ('official IDX financial-report attachments') with specific file types, distinguishing it from sibling tools like idx_company_announcements and idx_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List IDX issuers from the official IDX endpoint with sector, industry, listing date, and source citation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'official IDX endpoint' and fields returned but omits read-only status, rate limits, pagination behavior, or any side effects. Basic disclosure only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks detail on behavior and parameters. It is front-loaded but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given pagination parameters, no output schema, and no annotations, the description is incomplete. It does not explain pagination behavior, output format, or limitations, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the limit or offset parameters. It only lists output fields, adding no meaning to the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists IDX issuers from the official IDX endpoint and specifies included fields (sector, industry, listing date, source citation). It distinguishes from sibling tools focused on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like bps_list_subjects or idx_company_profile. The description merely states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get official KSEI investor demographics by month and dimension.
| Name | Required | Description | Default |
|---|---|---|---|
| dimension | Yes | ||
| month_year | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavioral traits. It only states 'Get' (read operation) but omits details like data update frequency, range limitations, or response format. The minimal behavioral disclosure is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits critical information. Like the 'Process' example in calibration, this is under-specification rather than effective conciseness. Every sentence should contribute, but here it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one with enum), no output schema, no annotations, and 0% schema coverage, the description is grossly incomplete. It fails to specify input formats, return values, or any operational details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning to the two parameters. It does not explain the required format of 'month_year' (e.g., YYYY-MM) or the values of the 'dimension' enum (e.g., what 'income' ranges are). The agent cannot infer correct usage from this definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves official KSEI investor demographics by month and dimension. It uses a specific verb ('get') and resource ('demographics'), distinguishing it from sibling tools like ksei_sid_growth. A score of 5 would require explicit differentiation from siblings, which is implicitly achieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about the proper scenarios for using demographics vs. other KSEI tools, such as ksei_sid_growth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get official KSEI investor-count growth series by month and metric.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | ||
| month_year | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'Get,' implying a read-only operation, but fails to disclose authentication requirements, rate limits, data freshness, or any side effects. The term 'official' adds minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 11 words with no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal parameter guidance, the description fails to cover response format, error conditions, or constraints. For a tool with two required string parameters, more detail is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters have no descriptions in the schema. The description mentions 'by month and metric' but does not explain valid formats for month_year (e.g., 'YYYY-MM') or the allowed values for metric (e.g., 'investor_count', 'growth_rate'). This leaves significant ambiguity for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Get official KSEI investor-count growth series by month and metric,' providing a clear verb (Get), resource (KSEI investor-count growth series), and dimensions (month, metric). It is distinct from sibling tools like idx_* (company info) and ksei_investor_demographics, but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., bps_get_data for economic data, idx_company_announcements). The description only states what it does, not when it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check first-party source availability and BPS credential readiness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'check' but does not disclose side effects, read-only nature, or what the output indicates. Behavioral traits are vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description lacks details on return format or expected behavior. An agent might infer it returns a status, but it's not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, the baseline is 4. The description adds meaning by specifying what is checked (source availability and credential readiness), which goes beyond just knowing there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'first-party source availability and BPS credential readiness', which is specific and distinguishes this tool from sibling data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives, such as prerequisites before calling data retrieval tools like bps_get_data. No when-not or usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0bps_get_databps_list_subjectsbps_list_variablesidx_company_announcementsidx_company_profileidx_financial_reportsidx_list_companiesksei_investor_demographicsksei_sid_growthsource_healthScored across 10 tools
Each tool is clearly scoped to a specific data source (bps_, idx_, ksei_) and a distinct operation (e.g., get_data vs list_subjects). No two tools overlap in purpose; even similar operations like 'list' targets different entities across sources.
All tool names follow a consistent snake_case format with a source prefix (bps_, idx_, ksei_) and a descriptive verb_noun pattern. The naming is predictable and unambiguous.
With 10 tools covering three distinct data sources plus a health check, the count is well-balanced. It covers core operations without being overwhelming or too sparse.
The tool set covers the main workflows for each data source: listing entities, retrieving details, and fetching data. The BPS tools lack an explicit period listing (implied by get_data parameters), and IDX lacks trading data, but the coverage is reasonable for the stated domain.
BPS — Badan Pusat Statistik (Statistics Indonesia) WebAPI MCP.
Taiwan Stock Exchange (TWSE) open data as MCP tools: stock quotes, ETF data, 140+ public datasets.
Financial Datasets AI MCP — wraps financialdatasets.ai
Financial data and research MCP for US/CN/JP equities: filings, statements, ownership, signals.
