Loading ToolBench
MCP server providing access to SDLC Assist project artifacts (Supabase) and agent-delegated tools (Vertex AI)
SDLC Assist MCP exhibits solid definition quality with well-structured input schemas, clear parameter descriptions, and proper enum usage. All 6 tools have explicit schemas with type definitions and parameter descriptions. Tool names follow verb_noun convention appropriately (list, get, generate). However, tool descriptions vary in completeness and some lack actionable dependency hints. Output schemas are undocumented in the visible code, only input schemas are defined. Error handling is basic (generic _handle_error helper). The server demonstrates good practices (pydantic models for input validation, proper enum constraints) but falls short of A-grade due to missing output documentation and generic error guidance.
Generate Traditional vs AI-Assisted cost estimates for a project. Calls a Vertex AI agent to produce detailed cost breakdowns (labor, infrastructure, tools) comparing traditional development with AI-assisted development. Requires all upstream artifacts (PRD, architecture, data model, API contract, implementation plan) to be generated first.
Fetch the content of a specific artifact from a project. Artifacts include PRD, Architecture Overview, Data Model, API Contract, Sequence Diagrams, Implementation Plan, Design System, CLAUDE.md, and Corporate Guidelines. Returns the full text content of the artifact.
Get a detailed summary of a single SDLC project. Returns the project name, status, tech stack preferences, which artifacts have been generated (and when), and the number of UI screens. Does NOT return artifact content — use sdlc_get_artifact for that.
List all UI screens defined for a project. Returns screen metadata (name, description, layer/index). Optionally includes the full HTML prototype content for each screen (very large). Useful for understanding the UI structure and referencing screens in architecture or implementation discussions.
Output schemas are not documented. Tool docstrings describe what data is returned (e.g., 'Markdown-formatted list' for sdlc_list_projects, 'full text content' for sdlc_get_artifact), but the actual schema structure (fields, types, nesting) is not formally specified. LLMs cannot predict downstream field names or structures without documented return schemas.
Error handling is generic and provides limited recovery guidance. The _handle_error helper catches HTTP status codes (404, 401) and type names, but does not guide the LLM on what action to take next. For example, a 404 returns 'Check that the project_id is correct', it should suggest 'Try sdlc_list_projects() to discover valid project IDs'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Fetch the tech stack preferences chosen for a project. Returns a JSON object with technology choices for backend, frontend, database, deployment, etc. These preferences guide implementation decisions.
List all SDLC Assist projects with their status and artifact completion. Returns a summary of every project including which artifacts have been generated (PRD, Architecture, Data Model, etc.) and how many UI screens exist. Use this to discover project IDs for other tools.
Missing dependency documentation in sdlc_generate_estimation. The description states 'Requires all upstream artifacts (PRD, architecture, data model, API contract, implementation plan) to be generated first' but does not guide the LLM on how to verify these prerequisites or what to do if they are missing. Should suggest: 'Call sdlc_get_project_summary() first to check artifact completion status.'
sdlc_get_tech_preferences has a minimal description (68 chars) that lacks context on what 'tech stack preferences' includes (backend, frontend, database, deployment, etc.). Description should be expanded to ~100-150 chars to clarify the scope and help LLMs decide when to call this tool.
No pagination parameters or result limits documented. sdlc_list_projects returns all projects with no limit or cursor. If a deployment has hundreds of projects, this could exhaust context window. Should add optional 'limit' and 'offset' parameters with defaults (limit=20) and document in the return schema.