Four well-named, read-only tools with clear descriptions (avg 180 chars) and complete input schemas. All parameters are typed and described. Tool names follow verb_noun pattern (search_, list_, dataset_). Descriptions explain WHAT, WHEN, and WHAT IS RETURNED. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. No error handling guidance. No pagination metadata (total count, next_cursor) documented for list tools. Parameter constraints (rows 1-1000, limit 1-1000) are stated in descriptions but not enforced via JSON Schema enums/min/max. Missing output schema documentation is the primary gap preventing a higher score.

• Document output schemas for all four tools. Example for search_datasets: 'Returns {count: number, results: [{id, title, organization, resources: [{url, format, name}]}]}'. This enables LLMs to extract dataset IDs for dataset_details calls.
• Add JSON Schema constraints: search_datasets.rows and list_organizations.limit should have 'minimum': 1, 'maximum': 1000. search_datasets.start should have 'minimum': 0. This prevents invalid input before it reaches the API.
• Document pagination behavior: 'Returns up to {rows} results. Use start parameter to fetch next page. No total count available from CKAN; stop when results < rows.' This guides LLM pagination logic.
• Enhance error messages in ckanGet(). Distinguish: 'Dataset not found (404), try search_datasets() to find the correct ID' vs 'CKAN service unavailable (503), retry in 30s' vs 'Invalid filter syntax, see https://docs.ckan.org/en/latest/api/'. Return structured error objects with error_type and recovery_hint.
• Add a link to CKAN Solr filter documentation in the 'fq' parameter description, or provide 3-5 common filter examples (organization, res_format, tags) with expected syntax.