search_datasetsSearch Île-de-France Open Data for datasets by keyword (regional services, transport, education, environment & economy). Returns dataset_ids (pass to query/dataset_info), titles, themes and record counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max datasets (1-100, default 20). | |
| query | No | Keyword(s) to search dataset titles/descriptions. | |
| offset | No | Pagination offset (default 0). |
Changes observed during successful MCP inspections.
Input schema / examplesAdded value: +[
+ {
+ "query": "transport"
+ },
+ {
+ "limit": 10,
+ "offset": 0,
+ "query": "education schools"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that results include dataset_ids, titles, themes, and record counts, which is useful but not critical. No behavioral traits beyond annotations are disclosed.
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 front-loaded sentence with a parenthetical listing scope and a follow-up detailing return values. Every word serves a purpose; no fluff.
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 no output schema, the description adequately covers return values (dataset_ids, titles, themes, record counts) and hints at the downstream usage. Parameter coverage is complete. A search tool with this level of detail is fully 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 coverage is 100% with descriptions for all parameters. The description adds minor context (e.g., 'pass to query/dataset_info') but does not enhance parameter meaning beyond what the schema already 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?
Description clearly states the action (search), resource (Île-de-France Open Data datasets), and what is returned (dataset_ids, titles, themes, record counts). It distinguishes itself from siblings like dataset_info and query by indicating that the returned IDs can be passed to those 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 implies usage context (searching a specific dataset catalog) and hints at a workflow (pass dataset_ids to query/dataset_info), but lacks explicit when-to-use vs. when-not or clear exclusions. It is clear enough for most cases but misses explicit alternative differentiation.
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.