Loading ToolBench

Reading the current corpus…

mcpg-plugin-credential-static MCP server · D · ToolBench

mcpg-plugin-credential-static

github.com/mcpg-dev/mcpg-plugin-credential-static

Config-driven static credential_issuer plugin for MCPG (dev.mcpg.credential.static). Operators declare per-target credentials in YAML; the plugin returns them per-request keyed on the target string. Pure offline; no outbound network. Useful for dev / lab / partner integrations + as the integration test foundation for the credential_issuer trait surface.

<=2025-11-251 tools

53/100

Definition Quality66

Protocol Readiness32

Supportability45

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Single tool 'issue' has a well-structured input schema with identity, target, and config parameters, each with type and description. Tool description is comprehensive (180+ chars) and explains authorization enforcement. However, output schema is not documented in the source, the description mentions 'credential value', 'parts', 'TTL', 'issued_at', and 'metadata' but no formal schema definition is visible. Parameter descriptions are present but could be more specific about constraints (e.g., valid trust_level values, target format). No error handling guidance or recovery paths documented.

Tools (1)

issueread onlyauthsource verified66/100

Issues a credential for a given target. Returns the credential value (for single-value credentials) or parts (for multi-part credentials) along with TTL, issued_at timestamp, and metadata. Enforces identity-based authorization rules (Any, Roles, Groups, or Subjects).

Issues (5)

HIGHtool ↗

Output schema not documented. Description mentions 'credential value', 'parts', 'TTL', 'issued_at', 'metadata' but no formal JSON Schema definition is visible in source. LLMs cannot plan downstream operations without knowing return structure.

issue

MEDIUMconstrained-input ↗

Parameter 'trust_level' lacks enum constraint. Description says 'e.g. verified, header_asserted, anonymous' but does not declare these as the only valid values. LLMs may hallucinate other values.

issue

MEDIUMrecovery-guide ↗

No error handling guidance. Authorization failures, invalid targets, and malformed identity objects have no documented recovery paths. LLMs cannot self-correct on failure.

issue

MEDIUMtool-description ↗

Identity parameter structure is complex (nested object with 5 fields). No guidance on which fields are required vs optional, or how missing fields are handled.

issue

Recommendations

Document the complete output schema as JSON Schema. Include field names, types, and descriptions for credential_value (or parts), ttl_seconds, issued_at, and metadata. Example: {"type": "object", "properties": {"value": {"type": "string"}, "ttl_seconds": {"type": "integer"}, ...}}
Convert trust_level description to an enum constraint: trust_level must be one of: 'verified', 'header_asserted', 'anonymous'. Add similar enums for identity.kind if applicable.
Add error handling guidance: 'If authorization fails, the response will indicate which rule (roles/groups/subjects) was not satisfied. Verify the caller's identity attributes match the target's authorize rule.'
Clarify identity parameter requirements: 'identity.subject_id and identity.trust_level are required. roles and groups are optional arrays. kind defaults to the identity provider type.'
Rename tool from 'issue' to 'issue_credential' to follow verb_noun convention and improve LLM discoverability.

Spec posture evidence

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

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

Score history

Overall score trend

First recorded score · v2 rubric

53/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	53	<=2025-11-25	v2