Skip to main content
Glama
restforge

@restforge-dev/mcp-server

Official
by restforge

Detect RESTForge Project Names

runtime_detect_project
Read-onlyIdempotent

Scans src/modules/ for .js files to detect and list available RESTForge project names.

Instructions

Detect RESTForge project names by scanning the conventional 'src/modules/' folder. Each .js file in that folder represents one RESTForge project; the filename without extension is the project name.

USE WHEN:

  • The user asks "which projects are available?", "what RESTForge projects are in this folder?", "list project saya"

  • Before generating a launcher script — to confirm the project name to pass as --project=

  • Before invoking 'runtime_generate_launcher' — to determine whether the user must specify a project name or one can be auto-detected

  • The user requests to run the server but the project name is unknown or ambiguous

DO NOT USE FOR:

  • Listing config files -> use 'runtime_detect_config'

  • Listing payload spec files -> use generic Read or filesystem tools

  • Listing database tables -> use 'codegen_list_tables'

  • Validating runtime preflight -> use 'runtime_validate_preflight'

Preconditions:

  • The 'src/modules/' folder must exist at /src/modules/. If missing, the precondition response will say so.

PRESENTATION GUIDANCE:

  • Match the user's language. If the user writes in Indonesian, respond in Indonesian.

  • Never mention internal tool names in the reply to the user.

  • When exactly one project is found, proceed without asking. When multiple are found, ask the user to pick one before generating the launcher.

  • The project name comes from the filename in src/modules/ (without the .js extension); explain this in plain language if asked.

  • When a precondition is not met (folder missing), frame it as a question or next-step suggestion rather than an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdYesAbsolute path of the project folder root (must contain src/modules/)

Implementation Reference

  • The main handler function that registers and implements the 'runtime_detect_project' tool. It reads src/modules/ directory, filters .js files, extracts project names, and returns the detection result.
    export function registerRuntimeDetectProject(server: McpServer): void {
      server.registerTool(
        'runtime_detect_project',
        {
          title: 'Detect RESTForge Project Names',
          description: `Detect RESTForge project names by scanning the conventional 'src/modules/' folder. Each .js file in that folder represents one RESTForge project; the filename without extension is the project name.
    
    USE WHEN:
    - The user asks "which projects are available?", "what RESTForge projects are in this folder?", "list project saya"
    - Before generating a launcher script — to confirm the project name to pass as --project=<name>
    - Before invoking 'runtime_generate_launcher' — to determine whether the user must specify a project name or one can be auto-detected
    - The user requests to run the server but the project name is unknown or ambiguous
    
    DO NOT USE FOR:
    - Listing config files -> use 'runtime_detect_config'
    - Listing payload spec files -> use generic Read or filesystem tools
    - Listing database tables -> use 'codegen_list_tables'
    - Validating runtime preflight -> use 'runtime_validate_preflight'
    
    Preconditions:
    - The 'src/modules/' folder must exist at <cwd>/src/modules/. If missing, the precondition response will say so.
    
    PRESENTATION GUIDANCE:
    - Match the user's language. If the user writes in Indonesian, respond in Indonesian.
    - Never mention internal tool names in the reply to the user.
    - When exactly one project is found, proceed without asking. When multiple are found, ask the user to pick one before generating the launcher.
    - The project name comes from the filename in src/modules/ (without the .js extension); explain this in plain language if asked.
    - When a precondition is not met (folder missing), frame it as a question or next-step suggestion rather than an error.`,
          inputSchema: {
            cwd: z
              .string()
              .min(1)
              .describe('Absolute path of the project folder root (must contain src/modules/)'),
          },
          annotations: {
            title: 'Detect Project Names',
            readOnlyHint: true,
            idempotentHint: true,
          },
        },
        async ({ cwd }) => {
          const projectCwd = resolve(cwd);
          const modulesDir = join(projectCwd, 'src', 'modules');
    
          let entries: string[];
          try {
            entries = await readdir(modulesDir);
          } catch {
            return {
              content: [
                {
                  type: 'text',
                  text: `Precondition not met: the modules folder does not exist.
    
    Project path: ${projectCwd}
    Expected folder: ${modulesDir}
    
    For the assistant:
    - The user is trying to detect RESTForge projects, but the conventional location 'src/modules/' is missing in this directory.
    - Suggest verifying that the user is at the correct project root, or ask the user where the project files are located.
    - Match the user's language. Do not mention internal tool names.`,
                },
              ],
              isError: false,
            };
          }
    
          const projects = entries
            .filter((name) => name.endsWith('.js'))
            .map((name) => name.replace(/\.js$/, ''));
    
          const envelope = {
            cwd: projectCwd,
            modules_dir: modulesDir,
            projects,
            count: projects.length,
          };
          const prettyJson = JSON.stringify(envelope, null, 2);
    
          if (projects.length === 0) {
            return {
              content: [
                {
                  type: 'text',
                  text: `No RESTForge project files were found in src/modules/.
    
    Project path: ${projectCwd}
    Modules folder: ${modulesDir}
    Count: 0
    
    --- Detection Result (JSON) ---
    ${prettyJson}
    --- end Detection Result (JSON) ---
    
    For the assistant:
    - The src/modules/ folder exists but contains no .js files.
    - A RESTForge project is conventionally a single .js file inside src/modules/ (e.g. mini-inventory.js -> project name 'mini-inventory').
    - Suggest the user creates a project file there first, or verify they are at the right project root.
    - Match the user's language. Do not mention internal tool names.`,
                },
              ],
              isError: false,
            };
          }
    
          const isSingle = projects.length === 1;
          const summary = isSingle
            ? `One RESTForge project detected: '${projects[0]}'.`
            : `${projects.length} RESTForge projects detected: ${projects.map((p) => `'${p}'`).join(', ')}.`;
    
          return {
            content: [
              {
                type: 'text',
                text: `${summary}
    
    Project path: ${projectCwd}
    Modules folder: ${modulesDir}
    Count: ${projects.length}
    
    --- Detection Result (JSON) ---
    ${prettyJson}
    --- end Detection Result (JSON) ---
    
    For the assistant:
    - ${
                  isSingle
                    ? `Only one project was found, so the runtime can use '${projects[0]}' without further input.`
                    : `Multiple projects were found. Ask the user which one to launch before proceeding.`
                }
    - The project name comes from the filename in src/modules/ (without the .js extension). It is the value passed as --project=<name> when invoking the RESTForge runtime.
    - Match the user's language. Do not mention internal tool names.`,
              },
            ],
            isError: false,
          };
        }
      );
  • Input schema for the tool - expects a single 'cwd' string parameter (absolute path to project root)
    inputSchema: {
      cwd: z
        .string()
        .min(1)
        .describe('Absolute path of the project folder root (must contain src/modules/)'),
    },
  • Export/import chain: registerRuntimeTools() calls registerRuntimeDetectProject() which registers the tool on the MCP server
    import { registerRuntimeDetectProject } from './detect-project.js';
    import { registerRuntimeDetectConfig } from './detect-config.js';
    import { registerRuntimeValidatePreflight } from './validate-preflight.js';
    import { registerRuntimeCheckLauncherExists } from './check-launcher-exists.js';
    import { registerRuntimeGenerateLauncher } from './generate-launcher.js';
    import { registerRuntimeCheckStatus } from './check-status.js';
    
    export function registerRuntimeTools(server: McpServer): void {
      registerRuntimeDetectProject(server);
  • src/server.ts:280-280 (registration)
    Top-level registration call: registerRuntimeTools(server) in startServer() registers all runtime tools including runtime_detect_project
    registerRuntimeTools(server);
  • Helper logic that constructs the response envelope containing cwd, modules_dir, project list, and count
    const envelope = {
      cwd: projectCwd,
      modules_dir: modulesDir,
      projects,
      count: projects.length,
Behavior4/5

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

The description adds behavioral context beyond the annotations: it explains that detection scans JS files, mentions preconditions (folder existence), and details presentation rules (language matching, auto-proceed vs. ask user). Since annotations already declare readOnly and idempotent, the description effectively supplements them without contradiction.

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?

The description is well-structured with headers and bullet points, making it easy to scan. While it is longer than minimal, each section (USE WHEN, DO NOT USE FOR, Preconditions, PRESENTATION GUIDANCE) earns its place by adding essential guidance. Could be slightly tightened but remains effective.

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?

The description provides complete context for a simple detection tool: it explains the detection logic, preconditions, usage boundaries, and presentation rules. No output schema is needed because the output is implicitly a list of project names. The description fully equips an AI agent to select and invoke the tool correctly.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'cwd' must contain 'src/modules/' and that the folder's existence is a precondition. This provides meaningful context beyond the schema's basic parameter description.

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 tool's specific verb ('Detect') and resource ('RESTForge project names by scanning the conventional 'src/modules/' folder'). It distinguishes itself from sibling tools like 'runtime_detect_config' by focusing on project names from module files.

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 includes explicit 'USE WHEN' and 'DO NOT USE FOR' sections that list specific user queries and contexts. It names alternative tools for different tasks (e.g., 'runtime_detect_config' for config files), providing clear guidance on when to choose this tool over siblings.

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/restforge/restforge-mcp'

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