Single tool 'issue' has a well-structured input schema with three object parameters (provider, identity, config) and clear descriptions. Tool description is comprehensive (180+ chars) and explains the two-hop OAuth 2.0 flow with RFC references. However, output schema is not documented in the visible code, no return type specification is evident. Parameter descriptions are present but lack detail on expected formats, constraints, and error conditions. The tool performs a sensitive credential-issuing operation (WRITE risk) but lacks explicit error handling guidance or recovery patterns.

• Document the return type explicitly: 'Returns an object with fields: access_token (string), token_type (string, typically 'Bearer'), expires_in (integer, seconds), scope (string, space-separated).'
• Expand 'config' parameter description to enumerate valid sub-fields and their types: 'Optional object with keys: audience (string), redeem_token_url (string), resource (string). Overrides provider-level config.'
• Add error handling section to tool description: 'On failure, returns error with code (invalid_subject_token, idp_unreachable, upstream_as_rejected) and actionable message. Retryable errors include network timeouts; non-retryable include invalid credentials.'
• Specify subject_token format in 'identity' parameter: 'Object containing subject_token (JWT or SAML assertion as string) and optional subject_token_type (defaults to urn:ietf:params:oauth:token-type:id_token per RFC 8693).'
• Document timeout and retry behavior: 'Each hop has a configurable timeout (default 5000ms per config.timeout_ms). Network errors are retryable; authentication errors are not. Agents should implement exponential backoff.'

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

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