Single tool with well-structured definition. Tool name 'scan_ambiguity' is action-verb clear and specific. Description is comprehensive (194 chars) and explains WHAT, WHEN, and constraints. Input schema properly defined with type, min/max length constraints, and clear description. Output schema is documented as dict[str, object] but lacks field-level documentation. Error handling present (InvalidAssetInput, InvocationLimitReached mapped to ToolError) but recovery guidance is minimal. No tool annotations (readOnlyHint, idempotentHint) despite being a READ_ONLY operation. Follows most patterns but output structure and error messaging could be more explicit for LLM reasoning.

• Document output schema explicitly: define fields like 'signals' (array of {type, text, position}), 'ambiguity_score' (0-100), 'summary' (string). Use Pydantic model or JSON Schema to make structure machine-readable.
• Enhance error messages with recovery guidance: 'Text exceeds 10,000 chars (got {len}). Truncate or split into multiple calls.' and 'Rate limit reached. Retry after 60 seconds.' instead of generic ToolError.
• Add tool annotations: @server.tool(name='scan_ambiguity', readOnlyHint=True, idempotentHint=True) to signal safe retry semantics.
• Clarify what 'signals' are in the description: 'Returns a list of potential ambiguities (vague timing, undefined quantities, unclear references) with positions in text. Signals are possible issues, not proof of ambiguity.'
• Consider adding a 'confidence' or 'severity' field to each signal so LLM can prioritize which ambiguities to address.

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry