Loading ToolBench
MCP server for https-wrench. Use resources and prompts to author requests YAML, inspect certs and JWTs, and generate JWKS. Execution tools return structured JSON directly; when building CLI commands for automated or agent use, pass format: "json" (or use --format json) for machine-readable output without ANSI styling.
https-wrench provides 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (validate_requests_config, build_cli_command, run_requests). Descriptions are present and moderately detailed (100-200 chars typical), explaining what each tool does and its CLI equivalent. However, descriptions lack actionable guidance on WHEN to use each tool vs. alternatives, and parameter descriptions are minimal. Output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (errorReporting=true but no recovery guidance visible in definitions). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Parameter validation rules (e.g., timeout ranges, enum constraints for HTTP methods) are not explicit in descriptions.
Build a shell-ready https-wrench CLI command for certinfo, jwtinfo, jwks, or requests (defaults to --format json, e.g. 'https-wrench certinfo --tls-endpoint example.com:443 --format json')
Inspect x.509 certificates and keys from local files or a TLS endpoint (returns JSON; CLI: https-wrench certinfo --tls-endpoint example.com:443 --format json)
Generate a JSON Web Key Set from a PEM public key file (returns JSON; CLI: https-wrench jwks --public-key-file path/to/public.pem --format json)
Inspect JWT tokens from a file or token endpoint (no refresh loop) (returns JSON; CLI: https-wrench jwtinfo --token-file path/to/token.jwt --format json)
Generate a starter requests YAML configuration from high-level parameters (use with 'https-wrench requests --config path/to/file.yaml --format json')
Execute https-wrench requests from inline YAML or a config file path (returns JSON; CLI: https-wrench requests --config path/to/file.yaml --format json)
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess what fields are returned and how to chain tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being READ_ONLY. Annotations help LLMs understand safety and retry semantics.
Parameter descriptions lack actionable constraints. E.g., 'timeoutSec' has no min/max bounds; 'method' in requests_config_template has no enum constraint; 'command' in build_cli_command lists valid values in description text rather than as an enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Parse and structurally validate a https-wrench requests YAML configuration (run with 'https-wrench requests --config path/to/file.yaml --format json')
Descriptions do not explain WHEN to use each tool or how they relate. E.g., validate_requests_config vs requests_config_template, when should an LLM choose one over the other? No guidance provided.
Error handling guidance not visible in tool definitions. errorReporting=true but no recovery hints (e.g., 'If validation fails, call requests_config_template to generate a valid config').