Server defines 5 tools with complete input schemas and descriptions. All tools are read-only, well-named with action verbs (search_, dataset_, datastore_, list_), and include parameter descriptions. However, output schemas are entirely undocumented, LLMs cannot plan downstream calls or extract structured data. Parameter descriptions lack constraints (e.g., no enum for sort fields, no regex for resource_id format). Error handling is minimal: ckanGet() throws generic errors without recovery guidance. No pagination metadata (total count, next_cursor) documented despite tools accepting limit/offset. Tool descriptions are adequate (100-200 chars) but could better explain when to use each tool vs. alternatives.

• Document output schemas for all 5 tools. Example for search_datasets: 'Returns {count: number, results: [{id, title, description, organization, tags, resources: [{id, name, datastore_active}]}]}'. This enables LLMs to extract resource_id for datastore_query calls.
• Add enum constraints to 'sort' parameter in search_datasets. Document valid sort fields: 'metadata_modified', 'name', 'score' with direction (asc/desc). Replace free-form string with enum or pattern.
• Enhance error messages with recovery guidance. Example: 'Dataset "vaccine-codes-lot-nachlieli" not found. Try search_datasets(query="vaccine") to find similar datasets.' Categorize errors as retryable (network timeout) vs. user-fixable (invalid ID).
• Document pagination behavior in tool descriptions. State: 'Returns up to {limit} results. If result count equals limit, more results may exist, increment offset and retry.' Include total_count or next_cursor in response schema.
• Add dependency hints to descriptions. E.g., search_datasets: 'To filter by organization, call list_organizations() first to see valid org names. Use fq="organization:{org_name}" to narrow results.' This guides multi-step planning.