Skip to main content
Glama

Detect Stack

detect_stack

Analyze project directories to identify technology stacks, including runtime environments, frameworks, databases, and frontend components.

Instructions

Quickly detect the technology stack of a project. Faster and lighter than inspect_project, returns runtime, framework, database hints, and frontend info.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the project directory

Implementation Reference

  • The primary handler function executing the detect_stack tool logic: validates path, scans files shallowly, detects languages/frameworks/databases/frontend, and returns stack info.
    export async function detectStack({ path: projectPath }) {
        // Validate path exists
        try {
            const stats = await fs.stat(projectPath);
            if (!stats.isDirectory()) {
                return createError(ErrorCodes.PATH_NOT_DIRECTORY);
            }
        } catch (err) {
            if (err.code === 'ENOENT') {
                return createError(ErrorCodes.PATH_NOT_FOUND);
            }
            if (err.code === 'EACCES') {
                return createError(ErrorCodes.ACCESS_DENIED);
            }
            return createError(ErrorCodes.SCAN_ERROR, err.message);
        }
    
        try {
            // Quick scan with shallow depth
            const { files } = await scanTree(projectPath, {
                maxDepth: 2,
                maxFiles: 500
            });
    
            // Parse dependencies
            const dependencies = await parseDependencies(projectPath, files);
    
            // Detect languages
            const languages = await detectLanguages(projectPath, files);
    
            // Detect frameworks
            const frameworks = await detectFrameworks(projectPath, files, languages, dependencies);
    
            // Detect database hints
            const databaseHints = await detectDatabaseHints(dependencies);
    
            // Check for frontend
            const frontendFrameworks = ['React', 'Vue.js', 'Angular', 'Svelte', 'Next.js', 'Vite'];
            const frontend = frameworks
                .filter(f => frontendFrameworks.some(ff => f.name.includes(ff)))
                .map(f => f.name);
    
            // Build result
            const result = {
                runtime: languages.map(l => l.name)
            };
    
            if (frameworks.length > 0) {
                result.framework = frameworks.map(f => f.name);
            }
    
            if (databaseHints.length > 0) {
                result.databaseHints = databaseHints;
            }
    
            // Only include frontend if detected
            if (frontend.length > 0) {
                result.frontend = frontend;
            }
    
            return result;
    
        } catch (err) {
            return createError(ErrorCodes.SCAN_ERROR, err.message);
        }
    }
  • Input schema validation using Zod for the detect_stack tool, defining the required 'path' parameter.
    export const detectStackSchema = {
        path: z.string().describe("Path to the project directory")
    };
  • index.js:43-61 (registration)
    MCP tool registration in the main stdio MCP server, using detectStackSchema and wrapping detectStack handler for MCP content format.
    server.registerTool(
        "detect_stack",
        {
            title: "Detect Stack",
            description: "Quickly detect the technology stack of a project. Faster and lighter than inspect_project, returns runtime, framework, database hints, and frontend info.",
            inputSchema: detectStackSchema
        },
        async (params) => {
            const result = await detectStack(params);
            return {
                content: [
                    {
                        type: "text",
                        text: JSON.stringify(result, null, 2),
                    },
                ],
            };
        }
    );
  • server.js:46-57 (registration)
    Tool definition/registration for HTTP/SSE server mode, with inline inputSchema and direct detectStack handler reference.
    detect_stack: {
        name: "detect_stack",
        description: "Quickly detect the technology stack of a project. Faster and lighter than inspect_project, returns runtime, framework, database hints, and frontend info.",
        inputSchema: {
            type: "object",
            properties: {
                path: { type: "string", description: "Path to the project directory" }
            },
            required: ["path"]
        },
        handler: detectStack
    },
  • api/index.js:10-13 (registration)
    Simple tool mapping for Vercel serverless API handler, directly assigning detectStack to detect_stack key.
    const tools = {
        inspect_project: inspectProject,
        detect_stack: detectStack,
        list_key_files: listKeyFiles
Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions performance characteristics ('faster and lighter') and output scope ('returns runtime, framework, database hints, and frontend info'), which adds useful context. However, it doesn't describe error handling, permission requirements, or what happens with invalid paths, leaving some behavioral aspects unclear.

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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides comparative context and output details. No wasted words, front-loaded with the main action.

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

Completeness4/5

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description provides good contextual coverage. It explains what the tool does, how it compares to alternatives, and what information it returns. The main gap is lack of output format details, but for a detection tool with no output schema, this is a minor limitation.

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?

Schema description coverage is 100% with one parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (path to project directory). The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 description clearly states the specific action ('detect the technology stack'), resource ('project'), and scope ('runtime, framework, database hints, and frontend info'). It explicitly distinguishes from sibling 'inspect_project' by noting it's 'faster and lighter', providing clear differentiation.

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?

The description provides explicit guidance on when to use this tool versus alternatives: 'Faster and lighter than inspect_project' directly compares it to a sibling tool. This gives clear context for choosing between detection methods based on speed vs. thoroughness.

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/QoutaID/qoutaMcp'

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