Skip to main content
Glama

speckit_specify

Generate detailed project specifications from user requirements to define what to build, enabling structured planning and implementation workflows.

Instructions

Describe what to build

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestNoThe user's requirement (e.g., speckit: add new user)

Implementation Reference

  • The core handler function for the 'speckit_specify' tool. It constructs a user message prompting the LLM to read a specification template from the commands directory and describe what to build based on the provided request.
        const userRequest = request || "No specific requirement provided.";
        return {
            messages: [
                {
                    role: "user",
                    content: {
                        type: "text",
                        text: `Please read the specification template at 'commands/speckit.specify'[Note that if this file exists, it is generally in the current directory's commands/ directory,Scan this folder directly to obtain it,And the suffixes of each project are not consistent: speckit.specify.xxx] [It's important. You must read it]. Combine this template with the User Requirement: '${userRequest}' to describe what to build.`,
                    },
                },
            ],
        };
    }
  • Input schema definition for the 'speckit_specify' tool, specifying a required 'request' string parameter.
    inputSchema: {
        type: "object",
        properties: {
            request: {
                type: "string",
                description: "The user's requirement (e.g., speckit: add new user)",
            },
        },
    },
  • src/index.ts:144-156 (registration)
    Tool registration in the tools/list response, including name, description, and input schema.
    {
        name: "speckit_specify",
        description: "Describe what to build",
        inputSchema: {
            type: "object",
            properties: {
                request: {
                    type: "string",
                    description: "The user's requirement (e.g., speckit: add new user)",
                },
            },
        },
    },
  • src/index.ts:203-205 (registration)
    Dispatch case in the CallToolRequestSchema handler that routes 'speckit_specify' calls to the handleSpecify function.
    case "speckit_specify":
        result = await this.handleSpecify(commandsPath, args.request as string);
        break;
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Describe what to build' suggests this is a specification/definition tool, but it doesn't reveal whether this creates a persistent artifact, triggers downstream processes, requires specific permissions, has side effects, or what format the output takes. The agent has minimal information about how this tool actually behaves.

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

Conciseness5/5

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

The description is extremely concise at just three words. While this represents under-specification rather than ideal conciseness, from a pure structural perspective, it's front-loaded with zero wasted words. Every word earns its place, even if that place is inadequate.

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

Completeness2/5

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

Given the complexity implied by having four sibling tools in what appears to be a development/specification system, and with no annotations or output schema, the description is severely incomplete. It doesn't explain what this tool produces, how it differs from related tools, or what context it operates within. The agent would struggle to understand when and how to use this tool effectively.

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?

The schema has 100% description coverage with one parameter 'request' clearly documented as 'The user's requirement'. The description doesn't add any meaningful parameter semantics beyond what the schema already provides. The example in the schema ('speckit: add new user') gives more context than the tool description itself. Baseline 3 is appropriate when schema coverage is complete.

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

Purpose2/5

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

The description 'Describe what to build' is a tautology that essentially restates the tool name 'speckit_specify' (specify = describe). It doesn't specify what type of artifact is being described or what domain this operates in. While it implies some creation/development context, it lacks the specificity needed to distinguish it from sibling tools like speckit_plan or speckit_tasks.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool versus the sibling tools (speckit_constitution, speckit_implement, speckit_plan, speckit_tasks). The description doesn't indicate whether this is an initial requirements gathering step, a refinement step, or how it fits into a workflow. There's no mention of prerequisites or alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anyiba/spec-kit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server