Skip to main content
Glama

setup_project

Initialize a new feature project by returning the mandatory folder structure, copy commands, and design rules. Must be called before any build step to avoid broken output.

Instructions

⚠️ CALL THIS FIRST before building any page. Returns mandatory folder structure, copy commands, icon reference table, CSS/JS link patterns, and critical rules (NO CDN, NO inline CSS, NO inline SVG). Skipping this tool will produce broken output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feature_nameYesName for the feature folder under figma-export/ (e.g. 'windows-startup', 'dashboard')

Implementation Reference

  • Handler function for setup_project MCP tool. It accepts a 'feature_name' parameter, sanitizes it, and returns a static SETUP_PROJECT string with variable replacements.
    server.tool("setup_project", "⚠️ CALL THIS FIRST before any other tool. Returns the complete build instructions, CDN URLs, available CSS/JS files, and workflow steps. You MUST follow the workflow it returns. Output is always a SINGLE index.html file with all assets loaded from CDN.", { feature_name: z.string().describe("Name for the page being built (e.g. 'windows-startup', 'dashboard', 'alerts'). Used only as a label — no folders are created.") }, async ({ feature_name }) => {
      const name = feature_name.replace(/[^a-zA-Z0-9_-]/g, "-").toLowerCase();
      return { content: [{ type: "text" as const, text: SETUP_PROJECT.replace(/your-feature-name/g, name).replace(/\$FEATURE/g, name) }] };
    });
  • Input schema for setup_project: a single required 'feature_name' string parameter, validated with Zod.
    server.tool("setup_project", "⚠️ CALL THIS FIRST before any other tool. Returns the complete build instructions, CDN URLs, available CSS/JS files, and workflow steps. You MUST follow the workflow it returns. Output is always a SINGLE index.html file with all assets loaded from CDN.", { feature_name: z.string().describe("Name for the page being built (e.g. 'windows-startup', 'dashboard', 'alerts'). Used only as a label — no folders are created.") }, async ({ feature_name }) => {
  • The static SETUP_PROJECT constant containing the full build instructions, CDN URLs, workflow steps, and DO NOT rules returned by the tool.
    const SETUP_PROJECT = `# Elegant 1.0 — Build Instructions
    
    ## How This Works
    You are connected to the Elegant Agent MCP server. ALL component HTML, wiki documentation, page blueprints, icons, and screenshots are available ONLY through the MCP tools listed below. There are NO local files to read — everything comes from this server.
    
    ## CDN Base URL
    \`\`\`
    ${CDN_BASE}
    \`\`\`
    
    ## Workflow (follow this order)
    1. ✅ You already called setup_project — good
    2. Call \`get_page_blueprint(page)\` — get exact layout for the target page
    3. Call \`get_screenshot(query)\` — see what the real page looks like
    4. Call \`get_recipe(shell)\` — get shell type (A/B/C/D) instructions
    5. Call \`get_shell(shell)\` — get the HTML skeleton with CDN links
    6. Call \`get_component(name)\` — get HTML for each component you need
    7. Call \`get_topnavbar()\` — get the complete TopNavBar HTML
    8. Call \`get_chart_snippet(chart_type)\` — get chart JS code
    9. Write a SINGLE index.html file — that's your only output
    
    ## Output Rules
    - Output = **ONE index.html file** — nothing else
    - ALL CSS via CDN: \`<link href="${CDN_BASE}/components/FILENAME.css">\`
    - ALL JS via CDN: \`<script src="${CDN_BASE}/components/FILENAME.js">\`
    - ALL icons via CDN: \`<img src="${CDN_BASE}/assets/icons/ICON.svg">\`
    - Logo: \`<img src="${CDN_BASE}/assets/icons/logo-log360.svg">\`
    - Fonts load automatically via tokens.css
    
    ## Available CSS Files
    tokens.css, layout.css, topnavbar.css, sidemenu.css, header.css, classic-tab.css, line-tab.css, table.css, table-type2.css, form-input.css, form-dropdown.css, drawer.css, rpt-chart-floater.css, widget.css, echarts-widget.css, note-container.css, notification-banner.css, responsive.css
    
    ## Available JS Files
    topnavbar.js, sidemenu.js, classic-tab.js, line-tab.js, table.js, form-input.js, form-dropdown.js, drawer.js, rpt-chart-floater.js, widget.js, echarts-widget.js, echarts-elegant-theme.js, icon-engine.js, notification-banner.js, lib/echarts.min.js
    
    ## ⛔ DO NOT
    - Do NOT search for or read any local files — no .md files, no data/ folders, no local HTML. Everything comes from MCP tools
    - Do NOT create folders or copy files
    - Do NOT write inline CSS for component styles
    - Do NOT write inline SVG when an icon file exists
    - Do NOT look for reference HTML in the user's workspace — use get_page_blueprint and get_screenshot instead
    - ALL data you need comes from the MCP tools above — you have everything`;
  • api/mcp.ts:563-569 (registration)
    Registration of the setup_project tool on the MCP server via the createMcpHandler callback. It's registered as the first tool with the name 'setup_project'.
    const handler = createMcpHandler(
      (server) => {
        /* 1. setup_project */
        server.tool("setup_project", "⚠️ CALL THIS FIRST before any other tool. Returns the complete build instructions, CDN URLs, available CSS/JS files, and workflow steps. You MUST follow the workflow it returns. Output is always a SINGLE index.html file with all assets loaded from CDN.", { feature_name: z.string().describe("Name for the page being built (e.g. 'windows-startup', 'dashboard', 'alerts'). Used only as a label — no folders are created.") }, async ({ feature_name }) => {
          const name = feature_name.replace(/[^a-zA-Z0-9_-]/g, "-").toLowerCase();
          return { content: [{ type: "text" as const, text: SETUP_PROJECT.replace(/your-feature-name/g, name).replace(/\$FEATURE/g, name) }] };
        });
Behavior3/5

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

Without annotations, the description carries full burden. It explains what the tool returns (folder structure, commands, etc.) and its critical role. However, it does not disclose any potential side effects, authentication needs, or rate limits, though such details may be irrelevant for a non-mutating setup 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 extremely concise with two sentences. It begins with a clear imperative warning, lists the outputs, and ends with a consequence. Every word adds value, making it highly efficient.

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?

Given the tool's role as a mandatory setup step with multiple outputs, the description adequately covers what the tool returns and its importance. No output schema is provided, but the description lists the outputs clearly. It is complete for the tool's purpose.

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 input schema has 100% coverage for the single parameter 'feature_name', and the schema description explains its purpose. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.

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 that the tool returns mandatory folder structure, copy commands, icon reference table, CSS/JS link patterns, and critical rules. It emphasizes that it must be called first before building any page, distinguishing it from sibling tools that deal with specific components.

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

Usage Guidelines4/5

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

The description explicitly instructs to call this tool first and warns that skipping it leads to broken output. This provides clear usage context, though it does not discuss when not to use it or alternatives, which is acceptable given its mandatory nature.

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/Anguraj-zoho/elegant-mcp'

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