specpilot_generate_specsGenerates the complete SpecPilot .specs/ file set plus the matching IDE rules and slash-command files from a full answer set - identical to what the SpecPilot web chat produces for the same answers. Requires projectName and projectDescription. Returns the files to write and the steps to follow after writing them.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / answers / properties / accessControl / descriptionAdded value: +"The access control model. Drives the security spec auth/authorization section and the permission model."Input schema / properties / answers / properties / accessibilityNotes / descriptionAdded value: +"Anything further on accessibility or constraints, in free text."Input schema / properties / answers / properties / activeUsers / descriptionAdded value: +"Roughly how many active users are expected, as a range."Input schema / properties / answers / properties / apiResponseTime / descriptionAdded value: +"Target API response time."Input schema / properties / answers / properties / apiStyle / descriptionAdded value: +"API style - REST, GraphQL, gRPC or tRPC. Shapes how the architecture spec documents client-server communication."Input schema / properties / answers / properties / authStrategy / descriptionAdded value: +"Auth approach - a protocol built in-house (JWT/OAuth/SAML) or a managed service (Clerk, Auth0, Firebase). Feeds the security spec."Input schema / properties / answers / properties / availability / descriptionAdded value: +"Availability SLA target as a fraction of uptime; higher percentages allow far less downtime per year."Input schema / properties / answers / properties / buildTimeline / descriptionAdded value: +"How long the build is expected to take."Input schema / properties / answers / properties / cicd / descriptionAdded value: +"CI/CD practices - automatically running tests and deploying on every change."Input schema / properties / answers / properties / compliance / descriptionAdded value: +"Compliance regimes that apply - GDPR, HIPAA, SOC 2. Pick by the actual situation (EU users, health data, payments), since getting it wrong has legal consequences."Input schema / properties / answers / properties / constraintDescription / descriptionAdded value: +"More detail on whatever was named in technicalConstraints."Input schema / properties / answers / properties / customUserType / descriptionAdded value: +"A user type in free text, when none of the userTypes options fit."Input schema / properties / answers / properties / dataSyncStrategy / descriptionAdded value: +"How conflicting local and server state gets reconciled once the device is back online."Input schema / properties / answers / properties / databases / descriptionAdded value: +"Database kinds in use - SQL, NoSQL, cache/key-value, vector. As many as apply."Input schema / properties / answers / properties / deploymentTargets / descriptionAdded value: +"Where this ships - cloud hosting, a package registry, a browser store. The option list depends on the project type."Input schema / properties / answers / properties / handle / descriptionAdded value: +"The developer GitHub handle. Optional; it namespaces generated task IDs (e.g. CD-jsmith-001). Infer from git config or the origin remote."Input schema / properties / answers / properties / ideAgent / descriptionAdded value: +"The editor or AI IDE in use - claudecode, cursor, copilot, codex, windsurf. You are the IDE, so set this yourself; it decides which rules and config files are generated."Input schema / properties / answers / properties / integrations / descriptionAdded value: +"Third-party integrations keyed by category, e.g. { payments: [\"stripe\"] }. Only categories relevant to the project type apply."Input schema / properties / answers / properties / isNewBuild / descriptionAdded value: +"True for a greenfield project, false when adding onto an existing codebase. Decides which onboarding analysis is generated at the end."Input schema / properties / answers / properties / languageOverride / descriptionAdded value: +"Primary language, when it should override what SpecPilot infers from the repo."Input schema / properties / answers / properties / localDatabases / descriptionAdded value: +"On-device stores backing offline support. Leave empty when offline is not needed."Input schema / properties / answers / properties / nonGoals / descriptionAdded value: +"What this project explicitly will NOT do. Becomes the non-goals section of the specs."Input schema / properties / answers / properties / offlineSupport / descriptionAdded value: +"Whether this has to work offline. Set automatically when localDatabases is non-empty."Input schema / properties / answers / properties / otherApis / descriptionAdded value: +"External APIs or services not covered by integrations."Input schema / properties / answers / properties / platforms / descriptionAdded value: +"Platforms this should run on, e.g. web, ios, android, desktop. Infer from the dependency manifests and repo layout."Input schema / properties / answers / properties / projectCategory / descriptionAdded value: +"Project archetype. Normally inferred from projectDescription when it exactly matches a returned chip label - send it only if you already know it."Input schema / properties / answers / properties / projectDescription / descriptionAdded value: +"One line saying what the project is. Required by specpilot_generate_specs. Sending one of the chip labels returned by specpilot_next_questions verbatim is what infers projectCategory and gates every later question; free prose infers nothing."Input schema / properties / answers / properties / projectName / descriptionAdded value: +"Short name for the project. Required by specpilot_generate_specs. Infer from the package manifest or the folder name."Input schema / properties / answers / properties / realtimeEnabled / descriptionAdded value: +"Whether anything updates live without a refresh. Set automatically when realtimeTypes is non-empty."Input schema / properties / answers / properties / realtimeTypes / descriptionAdded value: +"Realtime transports - WebSockets, SSE, polling. Leave empty when nothing needs to update live."Input schema / properties / answers / properties / scaleTier / descriptionAdded value: +"Expected scale of the system. Drives infrastructure and architecture choices."Input schema / properties / answers / properties / securityConcerns / descriptionAdded value: +"Security measures to plan for - encryption, rate limiting, audit logging."Input schema / properties / answers / properties / specialConsiderations / descriptionAdded value: +"Cross-cutting concerns that apply, such as accessibility, internationalisation or offline support."Input schema / properties / answers / properties / systemPattern / descriptionAdded value: +"Architecture pattern - monolith, modular monolith, or microservices."Input schema / properties / answers / properties / teamSize / descriptionAdded value: +"How many people are building this."Input schema / properties / answers / properties / technicalConstraints / descriptionAdded value: +"Hard constraints - budget, existing infrastructure, legacy systems, a fixed deadline."Input schema / properties / answers / properties / testingStrategy / descriptionAdded value: +"Testing approaches this project will use."Input schema / properties / answers / properties / userTypes / descriptionAdded value: +"Who is going to use this system, e.g. end users, admins, internal staff."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real value: 'Returns the files to write and the steps to follow after writing them' clarifies that the tool returns content rather than mutating the filesystem itself, and that an agent action follows. It still omits idempotency, error behavior when answers are incomplete, and whether any files are actually written server-side.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the output artifact and followed by prerequisites and return behavior. No wasted clauses, though the middle prerequisite sentence could be folded into the schema rather than repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, highly nested tool with no annotations and no output schema, the description covers what is produced and that files/steps are returned, which is the key gap-filler. It stops short of the end-to-end workflow (where the answers come from, likely specpilot_next_questions) and of failure modes, so it is only partially complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one top-level parameter (answers) with no description at 0% top-level schema coverage, though its numerous nested properties are individually documented in the schema. The description adds two required nested fields (projectName, projectDescription) that the nested schema does not mark as required, which is useful but also somewhat inconsistent with the schema's only required key being 'answers'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and a concrete resource set: 'Generates the complete SpecPilot .specs/ file set plus the matching IDE rules and slash-command files from a full answer set.' The scope ('identical to what the SpecPilot web chat produces') further pins down intent. It never names specpilot_next_questions, so sibling differentiation is left to inference, keeping it out of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'from a full answer set' and the stated prerequisites (projectName, projectDescription), which suggests this runs after collection is complete. However, it never states the relationship to specpilot_next_questions (i.e. call that first, then generate) or any when-not conditions. Adequate but leaves the sibling ordering for the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.