Read-only discovery for 389 Malaysian public datasets with freshness, licence, and provenance.
Return the published cross-source reconciliation group for a dataset name or id, including per-member counts, dates, statuses, tolerances, and contextual deltas. A discrepancy requires human review and does not prove either source is wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_name | Yes | Dataset id or name to reconcile, e.g. 'interestrates' or 'Monthly Interest Rates'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safety traits (read-only, idempotent, non-destructive). The description adds meaningful context: it returns 'published' (precomputed) data and explains that a discrepancy does not prove either source wrong, requiring human review. This goes beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads the core functionality and contents, the second adds an important interpretive caveat. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with a well-described parameter, rich annotations, and an output schema, the description covers the essential return contents and caveats. The existence of an output schema means return format details are not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter fully with examples and clarification ('id or name'). The tool description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a cross-source reconciliation group for a dataset name or id, listing specific contents (counts, dates, statuses, etc.). This distinguishes it from sibling tools focused on anomaly detection or evidence verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'published' and the reconciliation context, but does not explicitly state when to prefer this tool over alternatives like find_anomalies or verify_evidence. The caveat about human review provides interpretive guidance but no direct when-to-use/not-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets flagged by the latest published anomaly detection (anomalies), ranked by how far the observed update interval exceeds its threshold. Optionally require a minimum publish-reliability grade; includes pipeline-computed anomaly and reliability evidence so agents do not recompute it.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional exact detection mode; e.g. 'rolling_14d' or 'cadence_fallback'. | |
| limit | No | Maximum ranked anomalies to return; integer from 1 to 200, e.g. 50. | |
| min_reliability | No | Optional minimum publish-reliability grade; e.g. 'C' keeps A, B, and C and excludes insufficient data. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, open-world, idempotent, and non-destructive. The description adds useful behavioral detail about ranking by threshold exceedance and including pipeline-computed evidence, which goes beyond what annotations provide. No contradiction 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?
The description is two sentences, front-loaded with the main action and ranking logic, and ends with a valuable note about not recomputing pipeline results. Every clause contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a read-only list tool with a rich output schema and no required parameters, the description covers purpose, ranking, optional filtering, and rationale for use. It could be more explicit about when to prefer this over sibling find_* tools, but overall it is adequately complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described in detail. The description adds slight value by restating min_reliability as 'minimum publish-reliability grade' and mentioning ranking, but it does not meaningfully expand on the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Return') and resource ('datasets flagged by the latest published anomaly detection'), and clearly defines ranking criteria. It distinguishes itself from sibling tools like find_stale or find_deteriorating by focusing on anomaly detection evidence directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it returns pre-computed anomaly results and includes reliability evidence, explicitly stating agents should not recompute it. It also explains an optional filter (min_reliability). However, it does not explicitly name alternative sibling tools for exclusions, but the context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all datasets with the given licence, summarised. Use to enumerate what's available under a specific licence for compliance/reuse scoping.
| Name | Required | Description | Default |
|---|---|---|---|
| licence | Yes | Exact licence name or supported alias, e.g. 'Creative Commons Attribution 4.0'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that results are 'summarised' and include 'all' datasets, which clarifies the output scope beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core functionality, and includes the use case without any redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema, strong annotations, and presence of an output schema, the description sufficiently covers the purpose and use context. It adequately explains what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single parameter, including description and examples. The tool description does not add additional parameter semantics beyond referencing 'the given licence', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Return'), the resource ('all datasets'), and the scope ('with the given licence, summarised'). It distinguishes itself from siblings by focusing specifically on licence-based enumeration rather than general searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit use case ('Use to enumerate what's available under a specific licence for compliance/reuse scoping'), but does not mention when to avoid it or name alternative tools. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets whose published freshness trend is deteriorating, ranked by staleness slope. Optionally require a minimum historical anomaly rate; includes pipeline-computed trend and reliability evidence so agents do not recompute it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked deteriorating datasets to return; integer from 1 to 200, e.g. 50. | |
| min_anomaly_rate | No | Optional minimum percent of anomaly-evaluable history days, e.g. 25.0. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: results are ranked by staleness slope and include pipeline-computed trend and reliability evidence, which goes beyond simple read-only semantics and clarifies what the agent will receive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and then add option and guidance. Every phrase earns its place; no surplus words or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 0 required parameters, a rich input schema, and an output schema, the description adequately explains what is returned (ranked deteriorating datasets with evidence) and why agents should use it (pre-computed trend). No important usage aspects are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, with clear type definitions, defaults, and examples. The description restates the concept of 'minimum historical anomaly rate' for min_anomaly_rate but adds no new semantic detail beyond the schema. Baseline 3 applies when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('datasets') with a clear scope ('whose published freshness trend is deteriorating') and ranking criterion ('ranked by staleness slope'). This distinguishes it from siblings like find_stale or find_recovering, which target different trend statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells agents when to use this tool: when they need deteriorating freshness trends and pre-computed trend/reliability evidence. It explicitly advises 'agents do not recompute it', offering a reason to prefer this tool. However, it does not explicitly name alternative tools for other scenarios, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets whose published freshness trend is recovering, with the fastest staleness reductions first. Includes pipeline-computed trend and publish-reliability evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked recovering datasets to return; integer from 1 to 200, e.g. 50. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context about ordering ('fastest staleness reductions first') and included evidence ('pipeline-computed trend and publish-reliability evidence'), going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core functionality and followed by a concise note on included evidence. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an existing output schema, the description covers purpose, ordering, and result contents. It lacks explicit when-not-to-use guidance, but given the strong annotations and schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' is fully described in the schema with type, range, default, and example. The description does not add additional semantic meaning about the parameter, but the schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns datasets with a recovering freshness trend, sorted by fastest staleness reductions. This is a specific verb-resource pair and distinguishes it from siblings like find_deteriorating or find_stale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying recovering trends but does not explicitly state when to prefer this over alternatives like find_deteriorating or find_stale. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets with published structural or record-count drift evidence, ranked with structural changes first. Optionally require a minimum number of structural transitions; includes pipeline-computed evidence so agents do not infer drift from freshness alone.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked drift results to return; integer from 1 to 200, e.g. 50. | |
| min_change_count | No | Minimum structural fingerprint or column-count transitions; integer from 0 to 100, e.g. 1. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds meaningful behavior details: ranking order (structural changes first), optional minimum transition threshold, and the inclusion of pipeline-computed evidence. It goes beyond simple read-only scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main purpose is front-loaded, and each clause adds crucial context (ranking, optional filter, evidence provenance) without unnecessary 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 being short, the description fully covers the tool's purpose, ranking behavior, key parameter, and a usage caveat. Given the output schema and strong annotations, no critical information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that min_change_count requires 'a minimum number of structural transitions' and clarifies the ranking behavior, which complements the parameter 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 returns datasets with structural or record-count drift evidence, ranked with structural changes first. This specific verb+resource+scope distinguishes it from sibling tools like find_stale and find_anomalies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-not directive: 'so agents do not infer drift from freshness alone'. This tells agents this tool should be used when pipeline-computed drift evidence is needed, setting it apart from freshness-based approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets whose status is aging, stale, or degraded, plus datasets missing from the latest health snapshot. Use when an agent needs to know which data has a freshness or schema-validity risk.
| Name | Required | Description | Default |
|---|---|---|---|
| max_age_hours | No | Maximum acceptable age of the latest health check in whole hours; non-negative integer, e.g. 72. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, idempotent, non-destructive behavior. The description adds value by disclosing the exact selection criteria (status aging/stale/degraded, plus missing from latest snapshot), which is not inferable from annotations. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with action and purpose, with no redundant words. Every sentence contributes meaning.
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 one optional parameter, a rich output schema, and appropriate annotations, the description adequately covers the tool's purpose and when to use it. It doesn't explain return format, but the output schema covers that. The only minor gap is no explicit mention of how max_age_hours relates to the snapshot criteria, but that is a parameter detail.
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 parameter max_age_hours is fully described in the schema with type, default, minimum, examples, and a clear description. The tool description doesn't address parameters, but schema coverage is 100%, so baseline 3 applies; the description adds no additional param meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and specifies the resource 'datasets' with conditions (aging/stale/degraded, missing from snapshot), clearly distinguishing it from sibling tools like find_by_licence and search_datasets which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when an agent needs to know which data has a freshness or schema-validity risk,' providing clear context for when this tool is appropriate. It doesn't explicitly mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return datasets whose evaluated publish-reliability grade is at or below a threshold (the unreliable ones), with the worst grades and lowest on-time percentages first. Reliability measures timeliness of successful freshness observations, not uptime; sample days are included so agents can judge evidence depth.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked unreliable datasets to return; integer from 1 to 200, e.g. 50. | |
| at_or_below_grade | No | Inclusive reliability threshold; e.g. 'C' returns grades C, D, and F. | C |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful behavioral details beyond annotations: ordering by 'worst grades and lowest on-time percentages first' and the inclusion of 'sample days' for evidence depth. It also clarifies the metric definition, which is transparent about what reliability counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the primary function and ordering; the second sentence provides essential clarifications (metric definition and sample days) without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 optional parameters with full schema documentation, and output schema exists. The description conveys what the tool returns, sort order, and a critical nuance about the metric. It also mentions sample days, which addresses evidence depth. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and now includes full descriptions for both 'limit' and 'at_or_below_grade'. The description adds the conceptual term 'threshold' but does not provide additional parameter-level detail beyond the schema. The baseline of 3 is appropriate since the schema does the heavy lifting and the description adds minimal parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: 'Return datasets whose evaluated publish-reliability grade is at or below a threshold' clearly identifies the resource (datasets) and the selection criterion. The phrase 'with the worst grades and lowest on-time percentages first' adds ordering semantics. It distinguishes from sibling tools like find_stale or find_deteriorating by focusing on publish-reliability grade rather than staleness or trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by defining reliability as 'timeliness of successful freshness observations, not uptime', which helps avoid misuse. However, it does not explicitly name alternative tools or state when to prefer this tool over siblings like find_stale or find_deteriorating. The 'not uptime' clarification serves as an implicit exclusion but is not as strong as explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full detail for one dataset id, including its latest health status and last-verified timestamp, content_freshness_date, and freshness_signal_source (last_modified, content_parse, or none). Use to fetch the provenance/citation metadata for a dataset found via search_datasets and distinguish unknown-freshness from proven stale data.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Canonical dataset identifier, e.g. 'dosm_cpi_state'. See the registry catalogue for valid IDs. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by specifying what freshness_signal_source values mean (last_modified, content_parse, or none) and that the tool can distinguish unknown-freshness from stale data, which is not evident from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences. The first sentence states purpose and return fields, the second gives usage context and adds nuance about freshness signals. Every word earns its place, with zero fluff and strong front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects) and has both input and output schemas. The description covers the key differentiator (freshness signal semantics), provides usage context via search_datasets, and the output schema can explain return values. There are no obvious gaps for an AI agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: dataset_id has a clear description with an example. The description does not add parameter semantics beyond 'one dataset id', which is already clear from the schema. Per calibration, baseline 3 applies when schema does the heavy lifting, and no extra parameter detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return full detail for one dataset id' and lists specific fields (health status, last-verified timestamp, content_freshness_date, freshness_signal_source). This distinguishes it from siblings like search_datasets (finding datasets) and find_stale (finding stale datasets), and even from get_provenance by emphasizing health/freshness in addition to provenance 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?
The description explicitly says 'Use to fetch the provenance/citation metadata for a dataset found via search_datasets' and 'distinguish unknown-freshness from proven stale data', giving clear context on when this tool is appropriate. It does not mention explicit exclusions or 'instead' alternatives, but the context is sufficient for an AI agent to select it over search_datasets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete pipeline-published evidence receipt for one dataset id, including probe time, transport, access dependency, freshness, record-count, shape, tolerance, status, and anomaly fields. Use for a deep audit, e.g. get_evidence('fuelprice'); values are presented without MCP-side recomputation.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Canonical dataset identifier for a deep receipt, e.g. 'fuelprice'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond these annotations by stating that 'values are presented without MCP-side recomputation' and listing the exact fields returned, which helps the agent understand the tool's behavior in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the purpose and fields, the second provides usage guidance with an example. Every word earns its place, with no fluff or repetition of schema/annotations.
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 simple one-param tool, rich annotations, and presence of an output schema, the description is complete for an agent to select and invoke the tool correctly. It covers what it does, when to use it, and a key behavioral nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the param already has a description and example. The description reiterates the example usage and mentions 'one dataset id' but doesn't add significant new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Return' with a specific resource (pipeline-published evidence receipt) and scope ('for one dataset id'). It also lists the key fields included, distinguishing it from siblings like verify_evidence or get_provenance by framing it as a 'deep audit' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for a deep audit' and provides a concrete example (get_evidence('fuelprice')), giving clear context for when to use the tool. It does not explicitly mention exclusions or alternatives, but the guidance is clear enough for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a freshness-at-a-glance summary of the published catalogue: fresh, aging, stale, and reference counts plus the latest health check time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds useful behavioral context by specifying the output categories and the health check timestamp, giving the agent a clearer expectation of what the tool reports.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It immediately states the action and result, then lists the specific components of the summary. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only summary tool, the description is complete. It states the scope ('published catalogue'), the output categories, and the health check time. The output schema exists to provide further return structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema confirms this with 100% coverage of an empty properties set. There are no parameter semantics to clarify, so the baseline of 4 is appropriate; the description has no parameter burden to carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') with a specific resource ('freshness-at-a-glance summary of the published catalogue') and enumerates the exact contents (fresh, aging, stale, reference counts, latest health check time). This clearly distinguishes it from siblings like find_stale or usage_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case: when an agent needs a quick overall freshness summary of the catalogue. However, it does not explicitly state when to prefer this over alternatives such as find_stale or find_deteriorating, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return citation-ready provenance metadata for the listed dataset ids, plus compact pipeline-published evidence receipts: row probe time, HTTP status, request URL, access dependency, freshness source, content date, record count, shape fingerprint, anomaly flag, and status. Use when an agent must cite data and show the evidence behind the trust claim without recomputing it.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_ids | Yes | JSON array of 1 to 50 canonical dataset IDs, e.g. ['fuelprice', 'pricecatcher']. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by specifying the exact fields in the evidence receipts (row probe time, HTTP status, etc.) and noting it does not recompute, which clarifies the tool is a lookup rather than a computation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence front-loading the main return content and the second providing usage context. The list of receipt fields is concise and informative, and every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and a rich output schema, the description covers the return content and usage context well. However, it does not mention edge cases like invalid dataset IDs or mixed success/failure handling, which are minor gaps given the openWorldHint and existing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for dataset_ids, including a description, examples, min/max items, and required status. The description adds conceptual context by tying the IDs to 'citation-ready provenance' and evidence receipts, but it does not add syntactic or semantic details beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'citation-ready provenance metadata' plus 'compact pipeline-published evidence receipts', naming the specific resource and the verb. It also distinguishes from siblings by emphasizing the evidence receipts and the 'without recomputing it' lookup nature, which separates it from verification or trust-verdict tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'Use when' clause: 'when an agent must cite data and show the evidence behind the trust claim without recomputing it.' This gives clear context for appropriate use, though it does not explicitly mention alternatives or when not to use the tool, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search DataPulse MY's 412 Malaysian public datasets by natural-language query. Filter by licence (e.g. 'CC BY 4.0', 'Open Government Licence (Malaysia)') or source ('OpenDOSM', 'data.gov.my', 'MET Malaysia', etc.). Returns ranked matches: id, title, source, licence, status, score. Use when an agent needs to find datasets covering a topic, by an agency, or under a specific licence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum ranked matches to return; integer from 1 to 50, e.g. 10. | |
| query | Yes | Free-text search terms; natural language is allowed, e.g. 'inflation cpi'. | |
| source | No | Optional case-insensitive source-name substring, e.g. 'OpenDOSM'. | |
| licence | No | Optional exact licence name or supported alias, e.g. 'CC BY 4.0'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context beyond the schema: the corpus size (412 datasets), ranked-match behavior, and the exact fields returned (id, title, source, licence, status, 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?
The description is three sentences with no redundancy. It front-loads the core search action, then covers filters, return fields, and typical use cases in a compact, scannable way.
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 read-only search tool with a fully documented input schema and an output schema present, the description is complete: it states what to search, how to filter, what is returned, and when to use it. There is no critical missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant parameter meaning beyond the schema; examples like 'CC BY 4.0' and 'OpenDOSM' are already present in the schema's examples and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Search'), a concrete resource ('DataPulse MY's 412 Malaysian public datasets'), and the natural-language query mechanism. It is clear enough to be distinguished from more specialized siblings like get_dataset, though it does not explicitly contrast itself with find_by_licence despite overlapping in licence filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use when' statement covering topic-, agency-, and licence-based discovery, which tells an agent when this tool is appropriate. It stops short of naming alternatives or describing when NOT to use this tool, even though nearby siblings such as find_by_licence and get_dataset represent plausible alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return published attestation facts, the unsigned methodology-versioned trust score, numeric components, and component_availability reasons, plus existing health/trend/drift/reconciliation evidence for one canonical dataset id, e.g. 'fuelprice'. This tool does not re-probe or verify the signature; call verify_attestation separately.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Canonical dataset identifier to aggregate, e.g. 'fuelprice'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond annotations: the trust score is unsigned, the call does not re-probe or verify, and evidence is 'existing' rather than newly generated. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the main return categories, and the second delivers the key usage exclusion and alternative call in one clean, actionable clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter, full schema coverage, a detailed output schema, and read-only/idempotent annotations. The description covers what is returned, the scope, and the important non-behavior, making it complete 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?
Schema description coverage is 100% and the dataset_id parameter is already documented with an example. The description repeats 'one canonical dataset id' and 'e.g. fuelprice' but adds no substantive meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Return published attestation facts, the unsigned methodology-versioned trust score, numeric components...') tied to a concrete resource ('one canonical dataset id'). It also distinguishes itself from verify_attestation by explicitly saying it does not verify signatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when not to use this tool ('does not re-probe or verify the signature') and names the alternative ('call verify_attestation separately'). It does not broadly contrast with all sibling tools, but provides clear routing for the most likely source of confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate one buyer's audit-ledger usage for an inclusive ISO date range, e.g. 2026-08-01 to 2026-08-07. Returns total_calls, by_tool, by_dataset, trust_distribution (per-status counts of cited datasets) for the inclusive range.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | Inclusive ISO start date YYYY-MM-DD, e.g. '2026-08-01'. | |
| until | Yes | Inclusive ISO end date YYYY-MM-DD, e.g. '2026-08-07'. | |
| buyer_id | Yes | Buyer identifier, e.g. 'pro-default' or 'anonymous'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context by specifying the return fields (total_calls, by_tool, by_dataset, trust_distribution) and confirms the inclusive date range, which is helpful beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant wording, front-loaded with the main action and scope. The return field list is compact and useful.
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 simple read-only aggregation nature and the presence of an output schema, the description adequately covers all necessary context: buyer scope, date range, and return fields. Sibling differentiation is clear through the focus on usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the description does not need to add parameter details. It mentions an example date range but does not go beyond the schema's own descriptions. This is the baseline score for full schema coverage.
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 a specific action ('Aggregate one buyer's audit-ledger usage') on a well-defined resource (audit ledger) with a date range. It distinguishes itself from sibling analysis tools by focusing on usage aggregation rather than anomaly detection or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for a single buyer's usage over an inclusive date range. It does not explicitly name alternatives or exclusion criteria, but the scope is evident and distinct from siblings like find_anomalies or trust_verdict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a published Ed25519 probe attestation by canonical dataset id or safe relative digest reference, e.g. 'fuelprice' or 'attestations/2026-08-15/fuelprice.json'. L1 checks signature/key validity; optional L2 replays daily heads to a Git-tag anchor; L3 is provided by verify_evidence. Returns levels.L1.signature_valid and levels.L2.satisfied for signature and replay status.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | Dataset id or relative digest reference, e.g. 'fuelprice'. | |
| replay_chain | No | Replay daily heads to the newest tag anchor, e.g. true for an auditor. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral depth by explaining L1 signature/key checks, L2 replay behavior, and the returned fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: main action, verification levels, and return values. No fluff or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, verification levels, return fields, and the L3 alternative. Since an output schema exists, detailed return structure is not required. Annotations cover safety semantics. Minor gap: no explicit statement about idempotence/open-world behavior, but those are already in annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions and examples for both parameters. The description adds contextual meaning by defining 'reference' as a canonical dataset id or relative digest reference and explaining L2 replay behavior (related to replay_chain), but it does not explicitly map each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Verify' and resource 'published Ed25519 probe attestation', provides concrete examples of references, and distinguishes from sibling tools by explicitly noting that L3 is handled by verify_evidence. This clearly differentiates it from other verification and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool performs L1 and optional L2 verification, and explicitly points to verify_evidence for L3, providing an alternative. However, it does not explicitly state when not to use this tool or contrast with other sibling tools beyond the L3 mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one dataset before trust in a single read-only call. Returns dataset metadata, the published health and evidence rows, and a fail-closed Sigstore per-dataset receipt verification result with artifact references. Use verify_dataset('fuelprice') before relying on a dataset claim.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Canonical dataset identifier to verify before trust, e.g. 'fuelprice'. | |
| include_proof_steps | No | Include bounded Cosign verifier output for audit steps, e.g. false. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: it is fail-closed, returns specific bundled results, and includes artifact references. It does not fully explain failure behavior, but 'fail-closed' conveys the key trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core purpose is front-loaded, the return substance is summarized compactly, and the usage example 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?
With an output schema present and rich annotations, the description covers purpose, usage timing, result contents, fail-closed behavior, and a concrete example. Nothing essential is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description adds an example value 'fuelprice' but does not meaningfully expand on include_proof_steps or parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Verify one dataset before trust in a single read-only call.' It clearly distinguishes this from sibling tools by targeting a single dataset and bundling metadata, health, evidence rows, and a Sigstore receipt verification result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call it: 'Use verify_dataset('fuelprice') before relying on a dataset claim.' It provides a concrete context and example, though it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a rate-limited live streamed GET for one direct-access dataset and compare transport receipts with the latest published evidence, e.g. verify_evidence('fuelprice'). Content dates, row counts, and shape fingerprints remain pipeline-only and are explicitly reported as unverified; results are ephemeral and never update health artifacts. Returns a dict with transport receipt fields and a verdict for downstream trust checks without re-fetching.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Canonical direct-access dataset identifier to re-fetch, e.g. 'fuelprice'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the readOnlyHint and idempotentHint annotations: it is rate-limited, live streamed, results are ephemeral, never update health artifacts, and content dates/row counts/shape fingerprints are explicitly unverified. This fully discloses behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-punctuated sentences that front-load the core action, then provide important caveats and return value. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter), strong annotations, and presence of an output schema, the description is complete. It covers purpose, limitations, ephemerality, and return structure, making it sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single dataset_id parameter, which already includes an example and description. The tool description only reiterates 'one direct-access dataset' and the example, adding no meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a live GET request for a direct-access dataset and compares transport receipts with published evidence. It distinguishes itself from siblings like verify_attestation and trust_verdict by focusing on transport evidence re-verification, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—'for downstream trust checks without re-fetching'—and notes it is rate-limited, suggesting caution. It does not explicitly mention alternatives or exclusions, but the usage context is clear enough to guide an agent.
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. Dates show when Glama detected each change.
get_freshness_summaryverify_datasetcheck_reconciliationfind_anomaliesfind_deterioratingfind_recoveringfind_schema_driftfind_unreliableget_evidencetrust_verdictusage_summaryverify_attestationverify_evidencefind_by_licence1 field changedInput schema / properties / licence / examplesAdded value: +[
+ "Creative Commons Attribution 4.0",
+ "CC BY 4.0",
+ "OGL"
+]find_stale1 field changedInput schema / properties / max_age_hours / examplesAdded value: +[
+ 24,
+ 72
+]get_dataset1 field changedInput schema / properties / dataset_id / examplesAdded value: +[
+ "dosm_cpi_state"
+]search_datasets3 fields changedInput schema / properties / licence / examplesAdded value: +[
+ "CC BY 4.0",
+ "Open Government Licence (Malaysia)"
+]Input schema / properties / query / examplesAdded value: +[
+ "inflation cpi"
+]Input schema / properties / source / examplesAdded value: +[
+ "OpenDOSM",
+ "data.gov.my",
+ "MET Malaysia"
+]find_by_licence2 fields changedInput schema / properties / licence / descriptionAdded value: +"Exact licence name or supported alias, e.g. 'Creative Commons Attribution 4.0'."Input schema / properties / licence / minLengthAdded value: +1find_stale2 fields changedInput schema / properties / max_age_hours / descriptionAdded value: +"Maximum acceptable age of the latest health check in whole hours; non-negative integer, e.g. 72."Input schema / requiredAdded value: +[]get_dataset2 fields changedInput schema / properties / dataset_id / descriptionAdded value: +"Canonical dataset identifier, e.g. 'dosm_cpi_state'. See the registry catalogue for valid IDs."Input schema / properties / dataset_id / minLengthAdded value: +1get_provenance2 fields changedInput schema / properties / dataset_ids / descriptionAdded value: +"JSON array of 1 to 50 canonical dataset IDs, e.g. ['fuelprice', 'pricecatcher']."Input schema / properties / dataset_ids / examplesAdded value: +[
+ [
+ "fuelprice",
+ "pricecatcher"
+ ]
+]search_datasets4 fields changedInput schema / properties / licence / descriptionAdded value: +"Optional exact licence name or supported alias, e.g. 'CC BY 4.0'."Input schema / properties / limit / descriptionAdded value: +"Maximum ranked matches to return; integer from 1 to 50, e.g. 10."Input schema / properties / query / descriptionAdded value: +"Free-text search terms; natural language is allowed, e.g. 'inflation cpi'."Input schema / properties / source / descriptionAdded value: +"Optional case-insensitive source-name substring, e.g. 'OpenDOSM'."Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
data.gov.my / OpenDOSM (Department of Statistics Malaysia) — official Malaysian open-data API.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Add one secure layer between your agents and this server.
Each tool targets a distinct workflow—search, detail retrieval, freshness checking, licence enumeration, and citation metadata. The only mild overlap is between get_dataset and get_provenance, both exposing metadata, but their descriptions differentiate full health/freshness detail from citation-ready provenance.
All tool names follow a clear verb_noun pattern in snake_case: find_, get_, and search_ prefixes are used consistently. Minor stylistic variation between find_by_licence and find_stale does not undermine predictability.
Five tools is well-scoped for a dataset catalog server, covering discovery, inspection, health assessment, licence scoping, and citation. No redundant or excessive tools are present.
The core lifecycle is covered: search to find datasets, get_dataset for full detail, find_stale for freshness risk, and get_provenance for citation. A minor gap is the lack of a general list-all or status filter beyond stale, but the domain is narrow enough to work around this.