Single tool with comprehensive schema and reasonable descriptions. Tool naming follows verb_noun pattern ('axe_scan_url'). Input schema is well-defined with Zod validation covering 14 parameters with types, defaults, and constraints. Description is adequate (73 chars) but could be more detailed about when to use this tool vs alternatives. Output structure is documented in code but not formally in schema. No parameter-level descriptions visible in the schema itself, descriptions are embedded in Zod validators but not exposed to LLM. Error handling provides recovery hints for common failures (missing browsers). No output schema formally documented for LLM consumption. Missing any guidance on result pagination (not applicable here but impacts generality). Tool has no destructive operations but also lacks any hint annotations. Overall solid foundation with room for description depth and formal output schema documentation.

• Convert Zod schema to expose parameter descriptions in JSON Schema format. Every parameter (url, tags, browser, viewport, etc.) needs a 'description' field visible in the inputSchema JSON. Example: AxeScanSchema should generate JSON Schema where each property has explicit description field.
• Document the full output schema structure in code comments or a formal schema definition. Include the response object signature: {success: boolean, url: string, summary: {violations: number, passes: number, incomplete: number, inapplicable: number}, analysis: object, summaryText?: string}. This lets LLMs understand what fields to extract.
• Expand tool description to ~150-200 chars explaining: (1) what axe accessibility scanning is, (2) when to use (e.g., 'before deploying web apps to catch WCAG violations'), (3) what it returns (violation count and detailed rules), (4) prerequisite (valid URL, public or network-accessible).
• Add readOnlyHint and idempotentHint annotations when registering the tool. The tool makes no changes, so register it with {inputSchema: ..., readOnlyHint: true} if the SDK supports this.
• Constrain timeout parameters in descriptions. Change 'Navigation timeout in milliseconds (positive integer)' to 'Navigation timeout in milliseconds (100 - 60000; typical 5000 - 30000). Longer timeouts wait for slower pages but may block the scan indefinitely.'
• Add parameter relationship documentation in descriptions. Document that 'runOnlyRules' and 'tags' are mutually exclusive: 'If runOnlyRules is provided, tags is ignored. Either specify specific rules to run OR tags to check against, not both.'