Loading ToolBench
Model Context Protocol server providing tools for z/OS mainframe operations including data sets, jobs, UNIX System Services, and certificate management
The Zowe MCP server implements 9 certificate management tools with generally complete schemas and descriptions. All tools have non-empty descriptions (range: 86 - 237 characters, within baseline 34 - 392 range) and visible input parameter schemas with types. Naming is action-verb-forward (show, connect, delete, export, import, set, trust, rename, refresh), aligning with pattern:tool expectations. However, several tools exhibit parameter design issues: mutually exclusive parameters (fromRing vs fromDatabase in connectCertificate, importCertificate) are documented in descriptions but not formally enforced via schema constraints. Output schemas are not explicitly documented in any tool, no visible return type declarations. Error handling is minimal; no recovery guidance, error categorization, or actionable messages are present in the visible code. The server lacks idempotency guarantees and dry-run/confirmation patterns for destructive operations (deleteCertificate is IRREVERSIBLE but has no confirmation mechanism). Security model assumes server-side z/OS SAF integration (no secrets in params, which is correct), but no visible permission gate or audit logging. Tool composition is clean, each tool has one responsibility and produces outputs suitable for chaining (owner, keyring, label inputs/outputs align). This is solid domain-specific work with minor schema and error-handling gaps.
Connect a certificate to a key ring. The underlying SAF call requires the certificate bytes, so the certificate is read from a ring it is already on (fromRing) or from the security database (fromDatabase) and reconnected to the target ring.
Disconnect a certificate from a key ring, or delete it from the security database with database (which removes it entirely, not just from one ring). When the security product reports that the DIGTCERT class must be refreshed, run refreshCertificateClass so the change takes effect everywhere.
Export a certificate as PEM or certificate+key as PKCS#12. Returns the bytes as base64-encoded string, suitable for writing to a file.
Import a certificate or certificate+key into a key ring. The certificate can come from a PEM file, a PKCS#12 file, or an LDAP source.
Refresh the DIGTCERT class so certificate changes take effect everywhere. This is normally called automatically after certificate operations, but can be called explicitly if needed.
Output schemas are not documented. Tool descriptions state what is returned (e.g., 'certificate's owner, usage, trust status'), but no explicit output schema with typed fields is visible. LLMs cannot plan downstream tool calls without knowing response structure.
Mutually exclusive parameters lack formal schema constraints. connectCertificate and importCertificate both document that fromRing/fromDatabase (or fromFile/fromLdap) are mutually exclusive, but this is only stated in descriptions. JSON Schema should use oneOf or enum discriminators to enforce exclusivity and guide LLM input generation.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 35 | 1.27.1+ | v1 |
Rename a certificate in a key ring.
Set a certificate as the default for its key ring. The default certificate is used by applications when no certificate is explicitly specified.
Show a certificate's owner, usage, trust status, default flag, key size, serial number, and validity dates. Validity and serial come from decoding the certificate.
Mark a certificate as trusted (or not trusted) in its key ring.
No error handling guidance. Descriptions contain no recovery paths (e.g., 'If the certificate is not found, try showCertificate with the owner and keyring'). Tools like deleteCertificate mark operation as IRREVERSIBLE but offer no confirmation step or dry-run option (pattern:confirmation-request).
No idempotency guarantees documented. Agent retry logic assumes tools are safe to call multiple times with identical input. Silence on idempotency for tools like setDefaultCertificate or trustCertificate leaves agents uncertain whether repeated calls are safe.
No visible permission checks or permission scopes declared. Tools operate on z/OS resources (owner, keyring) but do not state what permissions (read:certificates, write:certificates, admin:certificates) are required. Audit logging is not visible.