Loading ToolBench
LLMReadyMCP has 3 tools with basic schemas and annotations, but significant quality gaps. All tools have input schemas and descriptions present, but descriptions are short (10-85 chars) and lack depth around use cases, return types, and error guidance. Parameter documentation is minimal, most parameters have 1-2 line descriptions without constraints, ranges, or format specifications. No output schemas are documented for any tool. Error handling is absent from tool definitions. Tool naming follows verb_noun patterns but lacks clarity on when to use each tool vs. alternatives (e.g., flexible-api-request overlaps with get-github-file-code). The flexible-api-request tool exposes a generic HTTP gateway, which is a composition and security concern. No idempotency markers, permission scopes, or recovery guidance present.
Make a flexible API request (GET, POST, etc.) with support for custom headers, JSON body, and optional auth.
Fetch the code of a file from a provided GitHub file URL.
Turn the website inot LLM Ready Markdown
No output schemas documented. LLMs cannot predict what fields are returned (markdown text structure, JSON object shape, HTTP response format, error format). Forces LLMs to guess downstream field names and invites failed chaining.
Parameter descriptions are minimal (10-30 chars) and lack actionable constraints. 'This is the website url' (36 chars) does not specify format, length limits, or how non-HTML content is handled. 'The full GitHub URL to the file' (30 chars) does not clarify expected format or what 'full' means (web vs. raw URL). No enum constraints, ranges, or examples.
flexible-api-request is a generic HTTP gateway with no input validation, auth handling guidance, or CORS/security constraints documented. Tool accepts arbitrary headers, bodies, and methods. No rate limiting, timeout, or retry guidance. This pattern invites misuse (SQL injection via body, command injection via headers) and conflicts with principle of single responsibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No error handling guidance in tool definitions or service implementations (src/services/apiFetch.ts shows raw error throws like 'Invalid GitHub file URL format' but no recovery hints). LLMs receive bare error messages with no context on whether to retry, ask user, or try alternatives.
Tool annotations present (title field in annotations object) but incomplete. Missing destructiveHint (flexible-api-request can POST/PUT/DELETE), readOnlyHint (website-to-markdown, get-github-file-code), and idempotentHint. Annotations should follow MCP spec structure: { readOnly: boolean, destructive: boolean, idempotent: boolean }.
Tool descriptions are generic and do not answer 'WHEN to use this instead of alternatives' or 'WHAT constraints apply'. E.g., website-to-markdown does not mention: supported content types (HTML only?), max page size, timeout, returned markdown structure (frontmatter? tables? code blocks?). get-github-file-code description omits: file size limits, binary file handling, authentication requirements (public vs. private repos). flexible-api-request does not document: JSON-only support (title says so, but description does not), auth method details, rate limits, timeout policy.
Parameter headers and body in flexible-api-request are typed as 'object' with additionalProperties but lack format constraints, length limits, or security warnings. No documentation on header validation (Host, Content-Type, etc.), body payload size limits, or injection attack prevention. LLMs will pass arbitrary JSON without awareness of security risks.
No permission scopes declared for any tool. Agents calling these tools do not advertise what access is required (read:web, read:github-api, write:api). This prevents least-privilege configuration and breaks audit trails.