MCP server for build-my-own - AI-powered project learning tool
Single tool with moderate naming but significant gaps in description completeness, parameter validation, output documentation, and error handling. The tool name uses verb_noun pattern appropriately, but the description lacks context on when to use this vs. other approaches. Input schema is present but minimal. No documented output schema. No error guidance for common failure modes (invalid URL, network errors, disk space). The implementation shows direct filesystem operations and git cloning with minimal validation, creating security and reliability concerns not mitigated by the tool interface.
Use it when the user says they want to build their own `x`. This will clone github project and setup prompts for AI tools. AI tools then will be able to guide them rebuilding the project from 0 to 1.
Tool description lacks actionable context. Does not clearly state: (a) What constitutes a valid GitHub URL beyond '.git' suffix; (b) When to use this vs. manual setup; (c) What happens if the URL is unreachable, repo is too large, or disk space is insufficient; (d) What the returned structure contains or how to use it. Current description is 238 chars but focuses on output behavior rather than decision criteria.
No output schema documented. Tool returns a structured object with fields (success, message, projectName, projectPath, originalPath, myOwnPath, rulesFiles) but LLM has no visibility into this structure. LLM cannot predict downstream field availability or plan chained operations. Response is returned as text only, obscuring the actual data structure.
Input parameter lacks validation guidance. 'github_url' description only states 'must end with .git' but does not specify: (a) expected format (https://github.com/owner/repo.git vs. git@github.com:owner/repo.git); (b) whether private repos are supported; (c) timeout behavior for slow networks; (d) maximum URL length. Parameter lacks type constraints that could be enforced client-side.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No error recovery guidance. Tool can fail at multiple points (invalid URL, unreachable repo, disk I/O errors, git not installed) but implementation provides no error messages or recovery hints to the LLM. 'cloneAndSetupProject' throws generic errors without actionable context. LLM cannot determine if failure is retryable, user-fixable, or fatal.
Security: Tool accepts arbitrary GitHub URLs and executes 'git clone' with user-supplied input. While the '.git' suffix check provides minimal validation, no additional safeguards against malicious repos, zip-bomb attacks, or large repos consuming disk space. 'utils.ts' uses spawnSync without timeout, risking hung processes. No rate limiting or repository size validation.
Missing idempotency semantics. Tool creates directories with project names derived from URL. Calling tool twice with same URL will fail on second call (directory exists). Tool does not support upsert or idempotent retry, agents cannot safely retry on ambiguous failures without manual cleanup.
Tool description uses vague language ('This will clone github project and setup prompts') rather than precise action semantics. Does not clarify: (a) creates local directories; (b) modifies filesystem; (c) clones potentially large repositories; (d) what 'setup prompts for AI tools' entails. LLM cannot reason about side effects or plan multi-step sequences.
Parameter schema uses Zod validation (.describe) but Zod runtime validation is not exported to JSON Schema in input schema registration. Schema registered with McpServer contains only top-level type ('github_url': z.string()) without formatting constraints. LLM cannot see Zod constraints and will not validate before calling.