A custom MCP server that provides HTTP method tools for making API requests
api-mcp provides 7 HTTP tools with explicit schemas and descriptions. However, critical gaps limit production readiness: (1) descriptions are generic and lack actionable guidance (e.g., 'Make a GET HTTP request' vs 'Fetch data from an API endpoint; returns JSON or text'); (2) no output schemas documented, LLMs cannot predict response structure or chain tools; (3) error handling absent, no guidance on retries, timeouts, or recovery; (4) parameter descriptions lack constraints (e.g., 'url' has no format/pattern, 'headers' no type hints); (5) auth mechanism stores tokens in plaintext folders, creating security risk; (6) no pagination support despite HTTP tools potentially returning large datasets. Tool naming is clear (verb_noun pattern), but composition lacks idempotency guarantees and confirmation for destructive ops.
Authenticate against an API, extract a JWT, and store it locally for reuse
Remove a specific user or clear the token store
Make a DELETE HTTP request
Make a GET HTTP request
List stored users and tokens from a token store
Make a pOST HTTP request
Make a PUT HTTP request
No output schemas documented. LLMs cannot predict response structure, field names, or types. Breaks tool chaining and forces agents to guess at downstream parameter mappings.
Descriptions are generic and lack actionable context. 'Make a GET HTTP request' does not explain when to use this vs alternatives, what it returns, or prerequisites. Baseline: A+ tools average 194 chars with clear WHAT/WHEN/RETURN guidance.
No error handling or recovery guidance. Tools do not document retryable vs fatal errors, timeouts, or what the LLM should do on failure. Agents cannot self-correct.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Parameter 'url' lacks format/pattern constraints. No validation that input is a valid HTTP(S) URL. LLMs may pass malformed URLs, file:// paths, or injection payloads.
Plaintext token storage in folders (tokens.json) is a security risk. No encryption, no access control, no audit trail. Credentials should use server-side secret injection via environment variables or vault.