OAuth 2.0 token-exchange credential_issuer plugin for MCPG (RFC 8693). Exchanges the caller's subject token for a downstream access token so a gateway can act on-behalf-of the end user (impersonation).
Single tool 'issue' has a detailed description (180+ chars) and structured input schema with object types, but critical gaps remain. The schema defines three parameters (provider_name, identity, call_config) with type declarations, but parameter descriptions are embedded in the schema object descriptions rather than per-parameter. The identity and call_config parameters are typed as 'object' with no nested schema detail visible, this violates JSON Schema best practices and leaves LLMs unable to understand the required structure. Output schema is not documented. Error handling is not visible in the tool definition. The tool performs a sensitive operation (token exchange) but the schema does not declare required permissions or security constraints.
Issues an exchanged OAuth 2.0 access token by performing RFC 8693 token exchange. Exchanges the caller's subject token (from identity.attributes["subject_token"]) for a downstream access token via the configured STS endpoint. Requires a Verified caller identity.
Object parameters lack nested schema detail. 'identity' and 'call_config' are typed as 'object' with descriptions in the parent, but no properties, required fields, or nested types are visible. LLMs cannot infer the structure of these complex inputs.
Output schema not documented. The tool description does not specify what fields the exchanged token response contains, how to extract the access_token, or what metadata is returned. LLMs cannot plan downstream use of the result.
No error handling guidance. The tool description does not explain what errors can occur (invalid provider, missing subject_token, STS failure, timeout) or how to recover. A bare error response leaves the LLM unable to self-correct.
Security constraints not declared. The tool requires 'Verified caller identity' but does not specify what trust_level is required, what happens if trust_level is insufficient, or what permissions the agent needs. No scope declaration (e.g., 'token:exchange') is visible.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Parameter descriptions are vague. 'call_config' is described as 'Optional per-call issuer config allowing caller to override audience and resource' but does not specify which fields are valid, their types, or constraints. LLMs will guess at the structure.