ANP Bridge defines 7 tools with German descriptions and basic parameter schemas. All tools have descriptions (10-200 chars, mostly adequate) and input schemas with type definitions. However, critical gaps emerge: (1) No output schemas documented, LLMs cannot predict return structure or chain tools; (2) Parameters lack enums for constrained values (e.g., message_type accepts 'text|task|response|error' but no enum constraint); (3) No error handling guidance, exceptions return raw JSON with minimal recovery hints; (4) Tool names are descriptive but descriptions could better explain WHEN to use each tool vs. alternatives (e.g., discover_anp_agents vs. fetch_agent_wellknown); (5) No pagination support despite discover_anp_agents accepting a 'limit' parameter, no mention of total count or next_cursor. All tools are READ_ONLY (safe), but composition is weak: no tool returns IDs needed for downstream calls (e.g., resolve_agent_did returns a DID document, but format_anp_message needs sender_did, unclear if the resolved DID can be used directly).

• Document output schemas for all 7 tools. Include field names, types, and descriptions. E.g., resolve_agent_did returns {did: string, verificationMethods: array, serviceEndpoints: array, ...}.
• Convert constrained parameters to enums: message_type → enum ['text', 'task', 'response', 'error']; protocol_a/protocol_b → enum ['ANP', 'A2A', 'MCP', 'ACP', 'AGP', 'AGNTCY', 'UTCP'].
• Enhance error responses with recovery hints. E.g., 'DID resolution failed: invalid format. Expected did:web:example.com or did:key:z6Mk... Try resolve_agent_did with a valid DID.'
• Add pagination to discover_anp_agents: return {agents: [...], total_count: int, has_more: bool, next_cursor?: string}. Document limit range (1-100).
• Clarify tool selection in descriptions. E.g., fetch_agent_wellknown: 'Use when you know the agent's base URL. For discovery by name/capability, use discover_anp_agents first.'