Loading ToolBench
A Next.js-based web application for building creator brands with sites, booking systems, and stores
This is not an MCP server. The codebase is a Next.js web application (echo-rework) with a single email submission API endpoint, not a Model Context Protocol server. The repo contains a marketing landing page, database schema for waitlist emails, and a POST API route. No MCP server framework is present, no tool registration mechanism exists, and the transport is HTTP REST (Next.js API route), not MCP-compliant. The single 'tool' (email_submission) is actually just an API endpoint description, not a properly registered MCP tool with full schema documentation. Critical issues: (1) No MCP server infrastructure, this is a Next.js app, not an MCP implementation; (2) Tool description is minimal (50 chars) and lacks context on when/why to use it; (3) Input schema shown partially in the eval but not in the actual source code, the route.ts file contains only runtime validation via regex, not a formal JSON Schema declaration; (4) No output schema documented; (5) No error handling guidance beyond a generic 400/201 response; (6) No security patterns (no permission checks, no audit logging, no rate limiting visible); (7) No composition or idempotency guarantees stated.
Accepts email addresses for waitlist registration via POST request
Not an MCP Server, This is a Next.js web application, not a Model Context Protocol server. No MCP framework, tool registration, or protocol compliance.
Tool Description Too Short, 'Accepts email addresses for waitlist registration via POST request' (50 chars) lacks actionable context. Does not explain when to use it, what it returns, or failure modes.
Input Schema Not Visible in Source Code, The eval shows a schema, but src/app/api/email/route.ts contains only inline regex validation (/^\S+@\S+\.\S+$/), not a formal JSON Schema declaration. Cannot verify schema is actually defined.
Output Schema Missing, No documentation of response structure. Route returns { error, exists, added } but LLMs cannot plan downstream actions without knowing what fields are returned and when.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 21 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error Handling Not Actionable, Returns { error: 'Invalid email' } on 400, but does not guide the agent to retry, validate input format, or check the email pattern. Raw error codes leave LLMs with no recovery path.
No Idempotency Guarantee, The tool checks if email exists and returns { exists: true } on duplicate, but does not state whether it is safe to retry. Agents need explicit idempotency markers.
Naming Ambiguous, 'email_submission' is passive and vague. Does not start with a clear action verb. 'add_email_to_waitlist' or 'register_email_for_waitlist' would be explicit about the operation.
No Security Audit Trail, No logging of who called the tool, when, or with what input. Sensitive operations (email collection) should be traceable.
No Rate Limiting Visible, POST endpoint vulnerable to rapid-fire requests. No rate limiting, throttling, or quota enforcement shown. An agent in a loop could spam the endpoint.
Email Validation Pattern Too Permissive, Regex /^\S+@\S+\.\S+$/ allows invalid emails (e.g., 'user@example.c' is valid by this pattern). Should use RFC 5322 or a stricter heuristic.