The server defines 10 read-only tools with consistent naming (all start with verb 'meraki_get_'). Tool names follow verb_noun pattern and are appropriately specific. However, descriptions are uniformly minimal (9 - 38 characters), falling well below the 50 - 200 char baseline for LLM-optimized tooling. Parameter descriptions exist but are sparse. Input schemas are present and properly structured with JSON Schema, but most lack constraints (enums, patterns, min/max) beyond basic type and description. No output schemas are documented, making it unclear what fields downstream tools should expect. All tools are read-only (no state mutation), but descriptions do not explicitly state this, missing an opportunity to signal safety to agents. Error handling and recovery guidance are absent from the codebase excerpts. Pagination is mentioned in some descriptions (perPage, timespan) but limits are not enforced in the observable schema.

• Expand all tool descriptions to 50 - 200 characters. Follow the pattern: [WHAT] This tool retrieves X. [WHEN] Use it when you need to Y. [RETURN] Returns a list of Z with id, name, and status fields. Example: 'Get all Meraki organizations you have access to. Use this to discover organization IDs before querying networks. Returns a list with id, name, and management status.'
• Document the output schema for each tool. Specify which fields are returned and their types. Example: 'Output: {organizations: [{id: string, name: string, management: {details: object}}]}'. This enables downstream tool chaining.
• Add min/max constraints to numeric parameters. Replace 'Time span in seconds (default 86400)' with 'Time span in seconds, 1 - 2592000 (max 30 days). Default: 86400 (1 day).'
• Add pagination (limit/offset or cursor) to list tools. Limit default to 20, max to 100. Example: 'Limit results to 20 organizations by default. Pass limit=50 and offset=0 to paginate. Returns total count for pagination.'
• Clarify parameter formats. Add notes like 'organizationId format: alphanumeric string (e.g. 'org_123abc')' in each parameter description.
• Implement and document error recovery. For a 404, return: 'Network N not found. Available networks: [list]. Did you mean one of these? Call meraki_get_networks(organizationId) to refresh the list.'
• Add tool annotations (destructiveHint: false, readOnlyHint: true, idempotentHint: true) to signal that all tools are safe to retry and do not mutate state.
• Consider adding a batch tool (e.g., meraki_get_multiple_networks) to allow agents to fetch data for multiple resources in one call, reducing latency and token overhead.

Inferred effective spec: <=2025-11-25.

• Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)