Search datasets
search_datasetsFull-text search over the dataset catalog. Returns matching dataset ids and descriptions. Free of look-ahead concerns; no as_of needed.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text. |
search_datasetsFull-text search over the dataset catalog. Returns matching dataset ids and descriptions. Free of look-ahead concerns; no as_of needed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text. |
Changes observed during successful MCP inspections.
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 meaningful context beyond those: it clarifies that the operation is free of look-ahead concerns and requires no as_of parameter, and it states what is returned (dataset ids and descriptions).
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 focused sentences with no wasted words. The purpose is front-loaded, and the return plus as_of note follow efficiently.
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 one-parameter search tool with rich annotations, the description is nearly complete: it covers purpose, return values, and the as_of exemption. It only lacks explicit usage guidance relative to sibling tools like describe_dataset.
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 there is only one parameter, so the schema already defines 'query' as search text. The description does not add any formatting or filtering details beyond the schema, making the baseline 3 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 and resource: 'Full-text search over the dataset catalog,' and adds the return shape ('matching dataset ids and descriptions'). It distinguishes itself from most siblings by the dataset catalog scope, but does not explicitly contrast with describe_dataset, which would be needed for a 5.
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 says 'Free of look-ahead concerns; no as_of needed,' which is a behavioral note rather than usage guidance. It does not say when to use this tool versus alternatives like describe_dataset, nor does it provide any when/when-not conditions.
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.