Loading ToolBench
Config-driven JWT-minting credential_issuer plugin for MCPG. Mints freshly-signed JWTs per request, asserting the caller's identity to downstream services. Supports HS256, RS256, and EdDSA algorithms. Pure CPU crypto, fully offline with no outbound network.
Two tools with complete input schemas and detailed descriptions. Tool naming follows verb_noun pattern (issue, revoke). Descriptions are substantive (150-200 chars), explaining WHAT the tool does and WHEN to use it. Input schemas are well-structured with nested objects and array types. However, output schemas are not documented, LLMs cannot infer what fields the issued credential contains or what the revoke response looks like. The 'revoke' tool is semantically problematic: it documents itself as a no-op for stateless JWTs, which raises questions about its utility and when an agent should call it. Parameter descriptions are comprehensive and include trust level semantics, claim mapping details, and authorization rules.
Issues a JWT credential for a given target and identity. Mints a freshly-signed JWT asserting the caller's identity to a downstream service. Returns the token as a string credential with metadata including algorithm and optional key ID.
Revokes a previously issued JWT credential. This is a no-op for stateless JWT tokens since they cannot be revoked (tokens are self-contained and do not require server-side state).
Output schemas not documented. LLMs cannot infer what fields the 'issue' tool returns (e.g., token string, algorithm, kid, expiry, metadata structure). Without documented output, agents cannot chain this tool to downstream operations or extract required fields.
'revoke' tool is documented as a no-op for stateless JWTs. This creates semantic confusion: when should an agent call it? What does it return? If it's truly a no-op, it should be removed or redesigned to support stateful credential tracking (e.g., revocation lists, token blacklists).
No error handling guidance. Tool descriptions do not explain what errors can occur (invalid target, authorization failure, signing key misconfiguration) or how agents should recover. Missing error classification (retryable vs. user-fixable vs. fatal).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Parameter 'target' accepts arbitrary strings but is constrained by operator config. No enum or validation hint in the description. Agents cannot discover valid targets without calling a separate discovery tool (which does not exist).
Identity object is complex with many optional fields (issuer, auth_provider, kind, scopes, attributes). No guidance on which fields are required vs. optional, or how missing fields affect claim mapping and authorization checks.