Three well-named, read-only tools with complete input schemas and clear descriptions. All tools follow verb_noun naming (search_, query_, layer_info). Descriptions are 150 - 250 chars, within the 10 - 1024 baseline. All parameters have type definitions and descriptions. However, output schemas are not documented, callers must infer structure from API responses. Error handling is minimal (generic HTTP status errors). No parameter validation guidance (e.g., 'limit must be 1 - 50') is visible in descriptions, though code enforces it. SSRF guard in layerUrl() is a security plus. Missing: output schema documentation, actionable error messages, parameter constraint examples.

• Document output schemas for all three tools. Example for search_datasets: 'Returns {total: number, count: number, datasets: [{id, name, summary, org, org_id, record_count, type, url}]}'. This enables LLMs to plan chained calls (e.g., extract url and pass to query_layer).
• Enhance error messages with recovery guidance. E.g., 'ArcGIS Hub returned 404. Verify the org_id is correct (e.g., "RmCCgQtiZLDCtblq" for LA County). Try search_datasets with a different keyword.' This guides the agent's next step.
• Add constraint documentation to parameter descriptions. E.g., 'limit: Max datasets (1 - 50, default 20). Values outside this range are clamped.' This makes constraints machine-readable and prevents LLM guessing.
• Implement rate limiting and quota tracking. Add a meter field or cost tracking to prevent agents from overwhelming ArcGIS services. Consider returning a 'rate_limit_remaining' field in responses.
• Shape search_datasets response to match agent expectations. Rename fields: id→dataset_id, attributes.name→name, attributes.snippet→summary. Omit internal fields (type, source). This reduces token waste and improves clarity.