get_schemaFetch schema JSON declared by a dataset's immutable public manifest. If schema_name is omitted, returns all declared schemas (currently capped at 10).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | Dataset family ID such as D02, or its catalog slug. | |
| schema_name | No |
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 meaningful context: the manifest is immutable and public, and omitting schema_name returns all schemas with a current cap of 10. 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 tightly scoped sentences with no filler. The primary action is front-loaded, and the second sentence adds a behaviorally important edge case 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 two parameters and no output schema, the description covers the key calling behavior and the main optional-parameter nuance. It stops short of describing the return JSON shape, but given the tool name and purpose that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that schema_name is optional and explains the behavior when omitted, which the input schema leaves undocumented. However, it does not add detail about schema_name's meaning or value format, so it only partially compensates for the 50% schema description 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 uses a specific verb ('Fetch') and resource ('schema JSON declared by a dataset's immutable public manifest'), making the tool's function immediately clear. It is visually and semantically distinct from siblings like get_dataset_metadata and get_download_url.
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 purpose implies when to use it: whenever a caller needs schema JSON for a dataset. However, it does not explicitly compare against alternatives or state when not to use it, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct operation: catalog discovery (list/search), metadata retrieval, download URL retrieval, schema retrieval, and checksum verification. The only potential overlap is between metadata and download URL, but the descriptions make their boundaries explicit.
Tool names consistently follow a snake_case verb_noun pattern: get_*, list_datasets, search_datasets, verify_checksum. The naming style is uniform and every verb accurately reflects the action.
Six tools is a well-scoped set for a public dataset metadata and access server. Each tool covers a necessary step in the discovery-to-download workflow without redundancy.
The workflow is complete for the stated domain: discover datasets, inspect metadata and schema, obtain download URLs, and verify checksums. Direct dataset bytes are intentionally not proxied, so this is not a gap given the server's defined purpose.