Skip to main content
Glama

SpecPilot

by dev.specpilot
OverviewDiscussionsAdmin

Server Details

Generate and validate a .specs/ bundle for your repo, then hand it to your AI coding agent

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
girishr/SpecPilot
GitHub Stars
37
Server Listing
SpecPilot

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct roles: specpilot_next_questions retrieves gated onboarding questions, while specpilot_generate_specs produces the final file set. There is no meaningful overlap, and the descriptions make the sequential relationship explicit.

Naming Consistency4/5

Both names share the specpilot_ prefix and snake_case formatting, which is predictable. However, 'next_questions' is a noun phrase rather than the verb_noun pattern established by 'generate_specs', a minor deviation.

Tool Count3/5

Only two tools for a spec-generation workflow, with an enormous amount of procedure compressed into the descriptions. The surface is thin but arguably matches the narrow two-phase domain (gather answers, emit files), making it borderline rather than clearly wrong.

Completeness3/5

The lifecycle is covered end-to-end via next_questions then generate_specs, and the agent writes files from returned payloads. But there is no way to regenerate or update a single step, validate existing specs, or reset/cancel the onboarding flow, leaving notable gaps.

Available Tools

2 tools
specpilot_generate_specsSpecPilot: generate the .specs/ filesBInspect

Generates 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
answersYes

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

specpilot_next_questionsSpecPilot: next onboarding questionsAInspect

Returns the still-unanswered SpecPilot onboarding questions of the next incomplete step, gated by the answers supplied so far - questions that do not apply to this kind of project are omitted, and options are filtered, badged or flagged the same way the SpecPilot web chat would. Stateless: send every answer collected so far on each call.

Procedure: (1) Decide whether the repository already has real source code and set isNewBuild accordingly - it changes which onboarding analysis is generated at the end. (2) Infer what the repo already answers rather than asking: platforms from the dependency manifests and layout, languageOverride, ideAgent (you are the IDE - claudecode, cursor, copilot, codex, windsurf), handle from git config or the origin remote, projectName from the package manifest or folder name, and projectDescription from the README only if it plainly says what the project is. (3) Call this tool with what you have; answer what the repo makes obvious and ask the developer the rest, a whole step per message. Send an empty value for an optional question the developer declines, or it will be asked again; send todoSentinel verbatim when they do not know yet. For projectDescription, sending one of the returned chip labels exactly is what infers projectCategory and gates every later question - free prose infers nothing. Confirm any pre-seeded value rather than accepting it silently. (4) Loop until done is true, then call specpilot_generate_specs and follow its nextSteps for where each file goes.

ParametersJSON Schema
NameRequiredDescriptionDefault
answersNo

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does so: it declares the tool is stateless and that every answer collected so far must be resent each call (a critical calling convention), that inapplicable questions are omitted, that options are filtered/flaggable, and that projectDescription chips gate all later questions. This is exactly the behavioral context an agent cannot get from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, then a four-step numbered procedure, so structure is strong and nothing is decorative. It is long with some dense multi-clause sentences, but the length is largely justified by the tool's multi-step, stateful-by-convention nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still explains the return-relevant contract: the questions themselves, the chip labels, the omission behavior, and the `done` flag that terminates the loop and triggers specpilot_generate_specs. An agent has everything needed to drive the workflow to completion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The nested schema documents each field, so the description's job is to add semantics beyond it, which it does for the highest-risk fields: how to infer isNewBuild, platforms, ideAgent, handle, projectName, and the chip-vs-prose distinction for projectDescription. The empty-value and todoSentinel conventions are procedural rules not expressible in the schema. It stops short of describing every field, but the important ones are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific resource and scope: 'the still-unanswered SpecPilot onboarding questions of the next incomplete step, gated by the answers supplied so far'. It also distinguishes the tool from its sibling by ending the workflow at specpilot_generate_specs, so an agent can tell the two apart without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit numbered procedure covers when to call it (step 3), what to infer before calling (step 2), how to loop (step 4), and the exit condition plus hand-off to specpilot_generate_specs. Edge cases (declined optional answers, todoSentinel, chip labels) each have stated handling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedspecpilot_generate_specs38 fields changed
      • addedInput schema / properties / answers / properties / accessControl / description
        Added value: +"The access control model. Drives the security spec auth/authorization section and the permission model."
      • addedInput schema / properties / answers / properties / accessibilityNotes / description
        Added value: +"Anything further on accessibility or constraints, in free text."
      • addedInput schema / properties / answers / properties / activeUsers / description
        Added value: +"Roughly how many active users are expected, as a range."
      • addedInput schema / properties / answers / properties / apiResponseTime / description
        Added value: +"Target API response time."
      • addedInput schema / properties / answers / properties / apiStyle / description
        Added value: +"API style - REST, GraphQL, gRPC or tRPC. Shapes how the architecture spec documents client-server communication."
      • addedInput schema / properties / answers / properties / authStrategy / description
        Added value: +"Auth approach - a protocol built in-house (JWT/OAuth/SAML) or a managed service (Clerk, Auth0, Firebase). Feeds the security spec."
      • addedInput schema / properties / answers / properties / availability / description
        Added value: +"Availability SLA target as a fraction of uptime; higher percentages allow far less downtime per year."
      • addedInput schema / properties / answers / properties / buildTimeline / description
        Added value: +"How long the build is expected to take."
      • addedInput schema / properties / answers / properties / cicd / description
        Added value: +"CI/CD practices - automatically running tests and deploying on every change."
      • addedInput schema / properties / answers / properties / compliance / description
        Added 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."
      • addedInput schema / properties / answers / properties / constraintDescription / description
        Added value: +"More detail on whatever was named in technicalConstraints."
      • addedInput schema / properties / answers / properties / customUserType / description
        Added value: +"A user type in free text, when none of the userTypes options fit."
      • addedInput schema / properties / answers / properties / dataSyncStrategy / description
        Added value: +"How conflicting local and server state gets reconciled once the device is back online."
      • addedInput schema / properties / answers / properties / databases / description
        Added value: +"Database kinds in use - SQL, NoSQL, cache/key-value, vector. As many as apply."
      • addedInput schema / properties / answers / properties / deploymentTargets / description
        Added value: +"Where this ships - cloud hosting, a package registry, a browser store. The option list depends on the project type."
      • addedInput schema / properties / answers / properties / handle / description
        Added value: +"The developer GitHub handle. Optional; it namespaces generated task IDs (e.g. CD-jsmith-001). Infer from git config or the origin remote."
      • addedInput schema / properties / answers / properties / ideAgent / description
        Added 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."
      • addedInput schema / properties / answers / properties / integrations / description
        Added value: +"Third-party integrations keyed by category, e.g. { payments: [\"stripe\"] }. Only categories relevant to the project type apply."
      • addedInput schema / properties / answers / properties / isNewBuild / description
        Added value: +"True for a greenfield project, false when adding onto an existing codebase. Decides which onboarding analysis is generated at the end."
      • addedInput schema / properties / answers / properties / languageOverride / description
        Added value: +"Primary language, when it should override what SpecPilot infers from the repo."
      • addedInput schema / properties / answers / properties / localDatabases / description
        Added value: +"On-device stores backing offline support. Leave empty when offline is not needed."
      • addedInput schema / properties / answers / properties / nonGoals / description
        Added value: +"What this project explicitly will NOT do. Becomes the non-goals section of the specs."
      • addedInput schema / properties / answers / properties / offlineSupport / description
        Added value: +"Whether this has to work offline. Set automatically when localDatabases is non-empty."
      • addedInput schema / properties / answers / properties / otherApis / description
        Added value: +"External APIs or services not covered by integrations."
      • addedInput schema / properties / answers / properties / platforms / description
        Added value: +"Platforms this should run on, e.g. web, ios, android, desktop. Infer from the dependency manifests and repo layout."
      • addedInput schema / properties / answers / properties / projectCategory / description
        Added value: +"Project archetype. Normally inferred from projectDescription when it exactly matches a returned chip label - send it only if you already know it."
      • addedInput schema / properties / answers / properties / projectDescription / description
        Added 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."
      • addedInput schema / properties / answers / properties / projectName / description
        Added value: +"Short name for the project. Required by specpilot_generate_specs. Infer from the package manifest or the folder name."
      • addedInput schema / properties / answers / properties / realtimeEnabled / description
        Added value: +"Whether anything updates live without a refresh. Set automatically when realtimeTypes is non-empty."
      • addedInput schema / properties / answers / properties / realtimeTypes / description
        Added value: +"Realtime transports - WebSockets, SSE, polling. Leave empty when nothing needs to update live."
      • addedInput schema / properties / answers / properties / scaleTier / description
        Added value: +"Expected scale of the system. Drives infrastructure and architecture choices."
      • addedInput schema / properties / answers / properties / securityConcerns / description
        Added value: +"Security measures to plan for - encryption, rate limiting, audit logging."
      • addedInput schema / properties / answers / properties / specialConsiderations / description
        Added value: +"Cross-cutting concerns that apply, such as accessibility, internationalisation or offline support."
      • addedInput schema / properties / answers / properties / systemPattern / description
        Added value: +"Architecture pattern - monolith, modular monolith, or microservices."
      • addedInput schema / properties / answers / properties / teamSize / description
        Added value: +"How many people are building this."
      • addedInput schema / properties / answers / properties / technicalConstraints / description
        Added value: +"Hard constraints - budget, existing infrastructure, legacy systems, a fixed deadline."
      • addedInput schema / properties / answers / properties / testingStrategy / description
        Added value: +"Testing approaches this project will use."
      • addedInput schema / properties / answers / properties / userTypes / description
        Added value: +"Who is going to use this system, e.g. end users, admins, internal staff."
    • Changedspecpilot_next_questions38 fields changed
      • addedInput schema / properties / answers / properties / accessControl / description
        Added value: +"The access control model. Drives the security spec auth/authorization section and the permission model."
      • addedInput schema / properties / answers / properties / accessibilityNotes / description
        Added value: +"Anything further on accessibility or constraints, in free text."
      • addedInput schema / properties / answers / properties / activeUsers / description
        Added value: +"Roughly how many active users are expected, as a range."
      • addedInput schema / properties / answers / properties / apiResponseTime / description
        Added value: +"Target API response time."
      • addedInput schema / properties / answers / properties / apiStyle / description
        Added value: +"API style - REST, GraphQL, gRPC or tRPC. Shapes how the architecture spec documents client-server communication."
      • addedInput schema / properties / answers / properties / authStrategy / description
        Added value: +"Auth approach - a protocol built in-house (JWT/OAuth/SAML) or a managed service (Clerk, Auth0, Firebase). Feeds the security spec."
      • addedInput schema / properties / answers / properties / availability / description
        Added value: +"Availability SLA target as a fraction of uptime; higher percentages allow far less downtime per year."
      • addedInput schema / properties / answers / properties / buildTimeline / description
        Added value: +"How long the build is expected to take."
      • addedInput schema / properties / answers / properties / cicd / description
        Added value: +"CI/CD practices - automatically running tests and deploying on every change."
      • addedInput schema / properties / answers / properties / compliance / description
        Added 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."
      • addedInput schema / properties / answers / properties / constraintDescription / description
        Added value: +"More detail on whatever was named in technicalConstraints."
      • addedInput schema / properties / answers / properties / customUserType / description
        Added value: +"A user type in free text, when none of the userTypes options fit."
      • addedInput schema / properties / answers / properties / dataSyncStrategy / description
        Added value: +"How conflicting local and server state gets reconciled once the device is back online."
      • addedInput schema / properties / answers / properties / databases / description
        Added value: +"Database kinds in use - SQL, NoSQL, cache/key-value, vector. As many as apply."
      • addedInput schema / properties / answers / properties / deploymentTargets / description
        Added value: +"Where this ships - cloud hosting, a package registry, a browser store. The option list depends on the project type."
      • addedInput schema / properties / answers / properties / handle / description
        Added value: +"The developer GitHub handle. Optional; it namespaces generated task IDs (e.g. CD-jsmith-001). Infer from git config or the origin remote."
      • addedInput schema / properties / answers / properties / ideAgent / description
        Added 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."
      • addedInput schema / properties / answers / properties / integrations / description
        Added value: +"Third-party integrations keyed by category, e.g. { payments: [\"stripe\"] }. Only categories relevant to the project type apply."
      • addedInput schema / properties / answers / properties / isNewBuild / description
        Added value: +"True for a greenfield project, false when adding onto an existing codebase. Decides which onboarding analysis is generated at the end."
      • addedInput schema / properties / answers / properties / languageOverride / description
        Added value: +"Primary language, when it should override what SpecPilot infers from the repo."
      • addedInput schema / properties / answers / properties / localDatabases / description
        Added value: +"On-device stores backing offline support. Leave empty when offline is not needed."
      • addedInput schema / properties / answers / properties / nonGoals / description
        Added value: +"What this project explicitly will NOT do. Becomes the non-goals section of the specs."
      • addedInput schema / properties / answers / properties / offlineSupport / description
        Added value: +"Whether this has to work offline. Set automatically when localDatabases is non-empty."
      • addedInput schema / properties / answers / properties / otherApis / description
        Added value: +"External APIs or services not covered by integrations."
      • addedInput schema / properties / answers / properties / platforms / description
        Added value: +"Platforms this should run on, e.g. web, ios, android, desktop. Infer from the dependency manifests and repo layout."
      • addedInput schema / properties / answers / properties / projectCategory / description
        Added value: +"Project archetype. Normally inferred from projectDescription when it exactly matches a returned chip label - send it only if you already know it."
      • addedInput schema / properties / answers / properties / projectDescription / description
        Added 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."
      • addedInput schema / properties / answers / properties / projectName / description
        Added value: +"Short name for the project. Required by specpilot_generate_specs. Infer from the package manifest or the folder name."
      • addedInput schema / properties / answers / properties / realtimeEnabled / description
        Added value: +"Whether anything updates live without a refresh. Set automatically when realtimeTypes is non-empty."
      • addedInput schema / properties / answers / properties / realtimeTypes / description
        Added value: +"Realtime transports - WebSockets, SSE, polling. Leave empty when nothing needs to update live."
      • addedInput schema / properties / answers / properties / scaleTier / description
        Added value: +"Expected scale of the system. Drives infrastructure and architecture choices."
      • addedInput schema / properties / answers / properties / securityConcerns / description
        Added value: +"Security measures to plan for - encryption, rate limiting, audit logging."
      • addedInput schema / properties / answers / properties / specialConsiderations / description
        Added value: +"Cross-cutting concerns that apply, such as accessibility, internationalisation or offline support."
      • addedInput schema / properties / answers / properties / systemPattern / description
        Added value: +"Architecture pattern - monolith, modular monolith, or microservices."
      • addedInput schema / properties / answers / properties / teamSize / description
        Added value: +"How many people are building this."
      • addedInput schema / properties / answers / properties / technicalConstraints / description
        Added value: +"Hard constraints - budget, existing infrastructure, legacy systems, a fixed deadline."
      • addedInput schema / properties / answers / properties / testingStrategy / description
        Added value: +"Testing approaches this project will use."
      • addedInput schema / properties / answers / properties / userTypes / description
        Added value: +"Who is going to use this system, e.g. end users, admins, internal staff."
  2. 2 tool updates
    • First observedspecpilot_generate_specs
    • First observedspecpilot_next_questions

Related MCP Connectors

Related MCP Servers

  • Carrot AI PM

    talvinder
    A
    license
    D
    quality
    D
    maintenance
    Spec-driven development tool for AI coding assistants that generates specs, validates code compliance, and provides actionable feedback.
    11
    29
    MIT

  • Tailor

    AmanKtyr
    A
    license
    Not graded
    quality
    B
    maintenance
    Unified AI coding-agent framework combining Spec-Driven Development (SDD), AST semantic code reuse, and progressive project memory (.ai/) for Claude Code, Cursor, Windsurf, and Zed.
    180 npm
    3
    MIT

  • wassden

    tokusumi
    A
    license
    Not graded
    quality
    D
    maintenance
    A Spec-Driven Development toolkit that transforms LLMs into development agents by providing expert-crafted prompts for generating structured specifications and validating documents across the Requirements → Design → Tasks → Code workflow.
    1
    MIT

  • SDS MCP

    salwks
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables automated project analysis and structured development specification generation. Supports multiple export formats and integrates with AI models for comprehensive project documentation and validation.
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources