Loading ToolBench
MCP quality gate that prevents AI agents from building sloppy apps, websites, and SaaS products.
ProjectGuard has 18 tools with complete input schemas and descriptions. Naming follows verb_noun convention (start_, classify_, analyze_, create_, review_, recommend_, final_). Descriptions are present and contextual (avg ~150 chars), exceeding the 10-char minimum. However, descriptions lack LLM-optimized specificity: they state WHAT but rarely explain WHEN to use each tool or dependencies between them. Parameter descriptions are generic ('The type of project', 'Project description') without format constraints, ranges, or examples of valid values. Output schemas are not documented, callers cannot predict response structure. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Tool composition is reasonable (each tool has one responsibility), but chaining is implicit rather than explicit (e.g., start_project_review returns 'next_tool: create_project_brief' as a string hint, not a structured reference). Security is adequate (no secrets in params, READ_ONLY risk classification), but no audit logging or permission gates are visible.
Check whether a project request is detailed enough before coding starts.
Analyze what ProjectGuard missed during the session to improve future reviews.
Classify project risk and decide which ProjectGuard reviews are required.
Return strict build rules to prevent low-quality AI-generated projects.
Create a structured project brief that the coding agent must follow.
Calculate the final project score and approval status based on code, UX, security, SEO, and paid launch scores.
Recommend focused defensive security reviews based on project type, files, and features.
Output schemas not documented. Callers cannot predict response structure, forcing LLMs to guess at field names and types. This breaks tool chaining and increases hallucination risk.
Parameter descriptions lack format constraints, ranges, and valid value enums. E.g., 'project_type' accepts any string; no enum of valid types (app, website, saas, api, script). LLMs will hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Review API authorization, BOLA/IDOR, admin route, GraphQL, and API rate-limit risks.
Run code-quality checks: secrets, TODOs, debug statements, risky commands, large files, and tests.
Review Dockerfile and Compose hardening issues.
Review a proposed file structure before the AI creates or edits files.
Review paid launch readiness for payment, account balance, proxy, VPN, email API, scanner, or other abuse-sensitive services.
Review payment webhook signature, idempotency, amount checks, balance ledger, and refund/dispute handling.
Detect AI slop, fake content, filler text, boilerplate phrases, fake metrics, and placeholders.
Run baseline security checks for web/API/SaaS code.
Review SEO for public HTML pages. Provide FULL rendered HTML source for each page (starting with <html> or <!DOCTYPE html>). Do NOT pass descriptions, URLs, or plain text.
Review basic UX completeness using explicit checklist signals.
Start here before building any app, website, SaaS, dashboard, API, or script. Returns the required ProjectGuard workflow, risk flags, missing details, required review gates, hard rules, and the next tool the coding agent should call.
No error handling guidance. Tools return dict[str, Any] with no documented error cases, retryability, or recovery paths. LLMs cannot distinguish transient failures from user errors.
Tool descriptions lack WHEN-to-use context and dependency hints. E.g., 'review_code_quality' does not state it should be called after 'review_file_plan' or that it requires file contents. Descriptions state WHAT but not WHEN.
Tool chaining is implicit (string hints like 'next_tool: create_project_brief') rather than explicit. No structured references or IDs to enable programmatic tool sequencing. Agents must parse string hints.