Agent Master Data

Get Reference Data

get_reference_data

Read-onlyIdempotent

Paid x402 tool. Get governed public reference data and controlled vocabulary values such as country, currency, unit of measure, industry, status, category, or code mappings. Returns codes, labels, definitions, validity dates, mappings, provenance, and version. Price ID: price.reference.v1.

Input Schema

Name	Required	Description	Default
`codes`	No	Exact codes wanted. Set membership, never a substring match; omit it to narrow nothing.
`limit`	No	Page size, applied after query, codes, and validity have narrowed the list.
`query`	No	Optional code or label search: a case-insensitive substring match against a value's code OR its label. Omit it to match every value.
`cursor`	No	Opaque continuation cursor from a prior identical request. Bound to the operation, the normalized request, and the data_version it paged.
`domain`	Yes	Reference-data domain identifier, as get_master_data_schema names it.
`locale`	No	Language tag echoed on every served value and in the answer. Labels are served exactly as the snapshot stores them; there is no translation layer.	en
`valid_at`	No	The instant to evaluate each value's validity interval at. Defaults to the request clock. A value whose source DECLARES its interval is active when valid_from <= valid_at < valid_to, an absent or null bound open on its side. A value whose source states no interval at all is neither: it is served active: null and carries the reference_value_validity_unknown warning.
`include_inactive`	No	Whether values not KNOWN to be active at valid_at are served. False excludes them; true serves them flagged - active: false for a value declared inactive, beside the reference_value_inactive warning, and active: null for one whose source states no validity interval, beside reference_value_validity_unknown - so an intentionally excluded value is distinguishable from an accidental match. Either warning is carried when such a value is WITHHELD too, so the omission is never silent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely new context: it is a paid tool with a specific price ID and it enumerates return fields including provenance and version. It omits pagination/rate-limit behavior, but the paid-upfront disclosure is valuable.

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

Conciseness5/5

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

Three short sentences, front-loaded with the paid flag and the core purpose. Every sentence contributes (payment, scope/domains, return shape, price ID) with no redundancy.

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

Completeness4/5

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

With no output schema, the description usefully enumerates the returned fields (codes, labels, definitions, validity dates, mappings, provenance, version), so the agent knows what to expect. Combined with a fully documented schema, only usage-vs-sibling guidance is notably absent.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries the heavy semantic load (e.g., codes as set membership, cursor binding). The description adds nothing about individual parameters beyond the domain concept, so the baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource ('Get governed public reference data and controlled vocabulary values') and enumerates concrete domains (country, currency, unit of measure, etc.). It clearly conveys what the tool returns (codes, labels, definitions, mappings, provenance, version), though it never explicitly contrasts itself with siblings like get_master_data_golden_record or search_master_data.

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

Usage Guidelines2/5

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

There is no explicit when-to-use/when-not guidance and no named alternatives among the six sibling tools. The only routing signal is the 'Paid x402 tool' flag, which tells the agent about cost but not about selection vs. the master-data siblings.

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

All Agent Master Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?