Skip to main content
Glama
flydev-fr
by flydev-fr

lazarus.clean

Clean Lazarus build artifacts to remove temporary files and reduce project size. Specify a Lazarus project file path to execute lazbuild --clean command.

Instructions

Clean Lazarus build artifacts using lazbuild --clean

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectYesPath to a Lazarus project file (.lpi)
lazbuildPathNoPath to lazbuild (defaults to "lazbuild")

Implementation Reference

  • The inline asynchronous handler function for the 'lazarus.clean' MCP tool. It calls the lazarusClean helper, processes the result, and returns a formatted MCP response with stdout/stderr and success status.
    }, async (req: any) => {
      const { code, stdout, stderr } = await lazarusClean(req);
      const ok = code === 0;
      return {
        content: [
          { type: 'text', text: ok ? `Lazarus clean succeeded for ${basename(req.project)}` : `Lazarus clean failed for ${basename(req.project)}` },
          { type: 'text', text: `Exit code: ${code}` },
          { type: 'text', text: '--- STDOUT ---\n' + stdout },
          { type: 'text', text: '--- STDERR ---\n' + stderr }
        ],
        isError: !ok
      };
    });
  • The main helper function implementing the clean logic by running 'lazbuild --clean' on the Lazarus project file (.lpi), with validation and proper working directory.
    async function lazarusClean({ project, lazbuildPath }: { project: string; lazbuildPath?: string; }) {
      const projPath = resolve(project);
      if (!existsSync(projPath)) {
        throw new Error(`Project not found: ${projPath}`);
      }
      if (!isLazarusProject(projPath)) {
        throw new Error('Unsupported project type. Provide a .lpi file');
      }
      const args: string[] = ['--clean', '"' + projPath + '"'];
      const lazbuild = lazbuildPath || 'lazbuild';
      return await runCommand(lazbuild, args, { cwd: dirname(projPath) });
    }
  • Zod-based input schema defining the parameters for the lazarus.clean tool: required project path and optional lazbuild path.
    const LazarusCleanInput = {
      project: z.string().describe('Path to a Lazarus project file (.lpi)'),
      lazbuildPath: z.string().optional().describe('Path to lazbuild (defaults to "lazbuild")')
    };
  • src/server.ts:286-289 (registration)
    The mcpServer.registerTool call that registers the 'lazarus.clean' tool with its description, input schema, and handler function.
    mcpServer.registerTool('lazarus.clean', {
      description: 'Clean Lazarus build artifacts using lazbuild --clean',
      inputSchema: LazarusCleanInput,
    }, async (req: any) => {

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It mentions the command 'lazbuild --clean' but doesn't disclose behavioral traits such as whether it's destructive (likely yes, as it cleans artifacts), permission requirements, or error handling. This leaves gaps for a mutation tool.

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 a single, efficient sentence with zero waste. It front-loads the purpose clearly and uses minimal words to convey the essential action and method.

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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, and return values, which are critical for understanding how to use the tool effectively in context.

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%, so the schema already documents both parameters. The description adds no additional meaning beyond implying the 'project' parameter is used with 'lazbuild --clean', which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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?

The description clearly states the action ('clean') and target ('Lazarus build artifacts') using a specific command ('lazbuild --clean'). It distinguishes from siblings like 'lazarus.build' by focusing on cleanup rather than building, though it doesn't explicitly contrast them.

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 on when to use this tool versus alternatives like 'delphi.clean' or 'fpc.build'. The description implies usage for cleaning Lazarus projects but lacks context about prerequisites, timing, or comparisons with sibling tools.

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

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/flydev-fr/mcp-delphi'

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