Connects to a Supabase database to manage website projects, browse professionally crafted design styles and color palettes, and retrieve AI-powered design recommendations for local businesses.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WebForge MCP Server suggest a design style and color palette for a local pet grooming shop"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for WebForge - Create and manage websites for local businesses through any MCP-compatible IDE.
🎨 100 Design Styles - Access to professionally crafted design styles
🎭 40 Color Palettes - Curated color schemes for different business types
🤖 Smart Recommendations - AI-powered style+palette combinations based on business type
📊 Project Management - Create and manage website projects
🔄 Compatibility Matrix - Intelligent scoring system for design combinations
🔧 MCP Protocol - Works with Claude Code, Cursor, Google Antigravity, and other MCP clients
Related MCP server: @designjs/mcp-server
npm install -g @joytorm/webforge-mcpAdd to your Claude configuration:
{
"mcpServers": {
"webforge": {
"command": "webforge-mcp",
"args": []
}
}
}Install the package: npm install -g @joytorm/webforge-mcp
Add to Cursor's MCP settings:
{
"webforge": {
"command": "webforge-mcp"
}
}Install: npm install -g @joytorm/webforge-mcp
Configure in Antigravity's MCP servers section:
{
"name": "webforge",
"command": "webforge-mcp",
"transport": "stdio"
}You need to create the required database tables in your Supabase instance. Execute this SQL in your Supabase SQL Editor:
-- WebForge MCP Database Setup
-- Execute this SQL in the Supabase SQL Editor
-- 1. Create design_styles table
CREATE TABLE IF NOT EXISTS design_styles (
id TEXT PRIMARY KEY,
name TEXT NOT NULL,
industry TEXT NOT NULL,
style_dna JSONB NOT NULL,
dos TEXT[] NOT NULL DEFAULT '{}',
donts TEXT[] NOT NULL DEFAULT '{}',
tokens TEXT NOT NULL,
raw_length INTEGER NOT NULL DEFAULT 0,
businesses TEXT[] NOT NULL DEFAULT '{}',
category TEXT NOT NULL,
category_label TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT TIMEZONE('utc'::TEXT, NOW()) NOT NULL,
updated_at TIMESTAMP WITH TIME ZONE DEFAULT TIMEZONE('utc'::TEXT, NOW()) NOT NULL
);
-- 2. Create design_palettes table
CREATE TABLE IF NOT EXISTS design_palettes (
id TEXT PRIMARY KEY,
name TEXT NOT NULL,
mood TEXT[] NOT NULL DEFAULT '{}',
industries TEXT[] NOT NULL DEFAULT '{}',
category TEXT NOT NULL,
primary_light TEXT NOT NULL,
primary_dark TEXT NOT NULL,
accent_light TEXT NOT NULL,
heading_font TEXT NOT NULL,
body_font TEXT NOT NULL,
border_radius TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT TIMEZONE('utc'::TEXT, NOW()) NOT NULL,
updated_at TIMESTAMP WITH TIME ZONE DEFAULT TIMEZONE('utc'::TEXT, NOW()) NOT NULL
);
-- 3. Create style_palette_compatibility table
CREATE TABLE IF NOT EXISTS style_palette_compatibility (
style_id TEXT NOT NULL REFERENCES design_styles(id) ON DELETE CASCADE,
palette_id TEXT NOT NULL REFERENCES design_palettes(id) ON DELETE CASCADE,
score INTEGER NOT NULL CHECK (score >= 1 AND score <= 5),
created_at TIMESTAMP WITH TIME ZONE DEFAULT TIMEZONE('utc'::TEXT, NOW()) NOT NULL,
PRIMARY KEY (style_id, palette_id)
);
-- 4. Create indexes for better performance
CREATE INDEX IF NOT EXISTS idx_design_styles_category ON design_styles(category);
CREATE INDEX IF NOT EXISTS idx_design_styles_industry ON design_styles(industry);
CREATE INDEX IF NOT EXISTS idx_design_styles_businesses ON design_styles USING GIN(businesses);
CREATE INDEX IF NOT EXISTS idx_design_palettes_category ON design_palettes(category);
CREATE INDEX IF NOT EXISTS idx_design_palettes_mood ON design_palettes USING GIN(mood);
CREATE INDEX IF NOT EXISTS idx_design_palettes_industries ON design_palettes USING GIN(industries);
CREATE INDEX IF NOT EXISTS idx_compatibility_style_score ON style_palette_compatibility(style_id, score DESC);
CREATE INDEX IF NOT EXISTS idx_compatibility_palette_score ON style_palette_compatibility(palette_id, score DESC);
CREATE INDEX IF NOT EXISTS idx_compatibility_score ON style_palette_compatibility(score DESC);
-- 5. Enable Row Level Security
ALTER TABLE design_styles ENABLE ROW LEVEL SECURITY;
ALTER TABLE design_palettes ENABLE ROW LEVEL SECURITY;
ALTER TABLE style_palette_compatibility ENABLE ROW LEVEL SECURITY;
-- 6. Create RLS policies for read access
DROP POLICY IF EXISTS "Allow read access to design_styles" ON design_styles;
CREATE POLICY "Allow read access to design_styles" ON design_styles FOR SELECT USING (true);
DROP POLICY IF EXISTS "Allow read access to design_palettes" ON design_palettes;
CREATE POLICY "Allow read access to design_palettes" ON design_palettes FOR SELECT USING (true);
DROP POLICY IF EXISTS "Allow read access to style_palette_compatibility" ON style_palette_compatibility;
CREATE POLICY "Allow read access to style_palette_compatibility" ON style_palette_compatibility FOR SELECT USING (true);
-- 7. Create trigger function for updated_at
CREATE OR REPLACE FUNCTION update_updated_at_column()
RETURNS TRIGGER AS $$
BEGIN
NEW.updated_at = TIMEZONE('utc'::TEXT, NOW());
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- 8. Create triggers for automatic updated_at
DROP TRIGGER IF EXISTS update_design_styles_updated_at ON design_styles;
CREATE TRIGGER update_design_styles_updated_at
BEFORE UPDATE ON design_styles
FOR EACH ROW
EXECUTE FUNCTION update_updated_at_column();
DROP TRIGGER IF EXISTS update_design_palettes_updated_at ON design_palettes;
CREATE TRIGGER update_design_palettes_updated_at
BEFORE UPDATE ON design_palettes
FOR EACH ROW
EXECUTE FUNCTION update_updated_at_column();After creating the tables, run the seeding script to populate them with WebForge's design data:
npm run seednpm install -g @joytorm/webforge-mcpgit clone https://github.com/joytorm/webforge-mcp.git
cd webforge-mcp
npm install
npm run build
npm linkwebforge_list_styles - List all 100 available design styles
webforge_list_palettes - List all 40 available color palettes
webforge_recommend_design - Get top 5 style+palette recommendations for a business type
webforge_get_style_details - Get complete style information including CSS tokens
webforge_get_palette_details - Get complete palette information including all colors
webforge_create_project - Create a new website project
webforge_list_projects - List existing projects with filtering
webforge_get_project - Get detailed project information
webforge_update_project - Update project settings
// Ask for recommendations for a restaurant
await webforge_recommend_design({ business_type: "restaurant" })// Create a project for a dental clinic
await webforge_create_project({
name: "Smile Dental Clinic",
business_type: "dental clinic",
description: "Modern dental practice website",
style_id: "S15", // Optional: assign a style
palette_id: "P08" // Optional: assign a palette
})// Get complete details for a specific style
await webforge_get_style_details({ style_id: "S01" })The MCP server connects to the WebForge Supabase instance automatically. No additional environment configuration is required.
Supabase URL: https://supabase.optihost.pro
Authentication: Handled automatically via service keys
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run tests
npm test
# Lint code
npm run lint
# Format code
npm run formatThe recommendation system uses a compatibility matrix that scores style+palette combinations from 1-5 based on:
Industry alignment - How well the style fits the business type
Visual harmony - Color theory and design compatibility
Brand perception - Mood and professional appropriateness
User experience - Usability for the target audience
Minimalist - Clean, modern designs with lots of whitespace
Creative - Bold, artistic layouts with unique elements
Professional - Traditional business-focused designs
E-commerce - Product-focused layouts with strong CTAs
Local Business - Community-oriented designs with local appeal
Professional - Conservative colors for business credibility
Friendly - Warm, welcoming colors for service businesses
Modern - Contemporary color schemes for tech/startups
Elegant - Sophisticated palettes for premium brands
Energetic - Vibrant colors for fitness/entertainment
Fork the repository
Create your feature branch: git checkout -b feature/amazing-feature
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
GitHub Issues: https://github.com/joytorm/webforge-mcp/issues
Email: contact@joytorm.com
Documentation: WebForge MCP Docs
Built with ❤️ by the Joytorm team
Create a new website project in WebForge
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name | |
| business_type | Yes | Type of business | |
| description | No | Optional project description | |
| style_id | No | Optional style ID to assign | |
| palette_id | No | Optional palette ID to assign | |
| domain | No | Optional custom domain |
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. While 'Create' implies a write operation, it doesn't mention permissions required, whether the operation is idempotent, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'website project' entails, what happens after creation, or any behavioral nuances. Given the complexity of creating a resource with 6 parameters, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond implying that 'name' and 'business_type' are required (which is already clear from the schema). This 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new website project in WebForge'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'webforge_update_project' or explain what distinguishes creation from updating, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'webforge_update_project' or 'webforge_list_projects'. It lacks any context about prerequisites, typical scenarios, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete details for a specific color palette including all colors
| Name | Required | Description | Default |
|---|---|---|---|
| palette_id | Yes | Palette ID (e.g., "P01", "P02") |
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. It states it 'gets' details, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'complete details' entails beyond colors. This leaves gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource. It avoids unnecessary words and directly communicates the tool's function without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, and output expectations, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'palette_id' well-documented in the schema. The description adds no additional meaning beyond implying it's for a 'specific color palette', which aligns with the schema but doesn't provide extra context like format examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'complete details for a specific color palette including all colors', making the purpose evident. However, it doesn't explicitly distinguish this tool from its sibling 'webforge_get_style_details' or 'webforge_list_palettes', which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'webforge_list_palettes' for listing palettes or 'webforge_get_style_details' for other details. The description implies usage for a specific palette but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID |
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. It states the tool retrieves 'detailed information,' but does not specify what that includes (e.g., metadata, status, permissions), whether it's a read-only operation, potential errors (e.g., invalid project ID), or performance aspects. This leaves significant gaps in understanding the tool's behavior beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action ('Get detailed information'), making it efficient and easy to parse, which is ideal for conciseness in tool definitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool that retrieves 'detailed information.' It does not explain what details are returned, error handling, or behavioral traits, leaving the agent with incomplete context for effective use. The high schema coverage helps with inputs, but overall completeness is poor due to missing output and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'project_id' documented as 'Project ID.' The description adds no additional semantic context (e.g., format examples, where to find the ID, or constraints), so it relies entirely on the schema. This meets the baseline score of 3 for high schema coverage without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific project'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'webforge_list_projects' (which likely lists multiple projects) or 'webforge_get_palette_details' (which focuses on palettes), leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a project ID), exclusions, or direct comparisons to siblings like 'webforge_list_projects' for listing projects or 'webforge_update_project' for modifications, leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete details for a specific design style including CSS tokens
| Name | Required | Description | Default |
|---|---|---|---|
| style_id | Yes | Style ID (e.g., "S01", "S02") |
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. It states the tool retrieves details, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'complete details' includes beyond CSS tokens. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'complete details' entails, such as the structure of returned data or how CSS tokens are formatted, leaving gaps in understanding the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'style_id' documented in the schema. The description adds no additional parameter semantics beyond implying it's used to fetch details, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('complete details for a specific design style'), specifying what the tool does. It distinguishes itself from siblings like 'webforge_list_styles' by focusing on details for a single style rather than listing. However, it doesn't explicitly differentiate from 'webforge_get_palette_details' beyond the resource type, keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a style ID from 'webforge_list_styles', or compare it to other get-details tools like 'webforge_get_palette_details'. This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available color palettes with basic information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool lists items but doesn't describe return format, pagination, sorting, rate limits, authentication needs, or error conditions. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information. Every word earns its place in the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description should provide more complete context about what 'basic information' includes, the return format, and any behavioral constraints. For a list operation that presumably returns multiple items, the description is too minimal to guide effective use without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and the baseline for this situation is 4. The description appropriately focuses on what the tool does rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('color palettes'), specifying it retrieves 'all available' items with 'basic information'. It distinguishes from siblings like webforge_get_palette_details by focusing on listing rather than detailed retrieval. However, it doesn't explicitly differentiate from webforge_list_projects or webforge_list_styles beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer webforge_get_palette_details for detailed information or how this listing relates to other list tools like webforge_list_projects. Usage context is implied by the tool name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List website projects with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by project status | |
| business_type | No | Filter by business type | |
| limit | No | Maximum number of projects to return (default: 50) | |
| offset | No | Number of projects to skip (default: 0) |
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. It mentions 'optional filtering' but doesn't describe key behaviors like whether this is a read-only operation, if it requires authentication, what the return format looks like, or if there are rate limits. For a list tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for a list tool and wastes no words. Every part of the sentence ('List website projects with optional filtering') contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what 'website projects' are in this context, what fields are returned, or how the filtering works in practice. For a tool with no output schema and no annotations, more context is needed for the agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional filtering' which aligns with the parameters, but adds no specific meaning beyond what the input schema provides. Since schema description coverage is 100%, the baseline score is 3. The description doesn't explain parameter interactions or provide additional context about filtering logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('website projects'), and mentions optional filtering. However, it doesn't specifically differentiate this tool from sibling tools like 'webforge_get_project' or 'webforge_list_palettes' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'webforge_list_projects' instead of 'webforge_get_project' for retrieving a single project, or how it relates to other list tools like 'webforge_list_palettes'. There's only a vague implication of usage through 'optional filtering'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available design styles with basic information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states it 'List all available design styles with basic information', which implies a read-only, non-destructive operation, but doesn't disclose potential limitations like pagination, rate limits, authentication needs, or what 'basic information' entails. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all available design styles') and adds clarifying detail ('with basic information'). There is no wasted text, and it directly communicates the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity is low (0 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral aspects like return format, pagination, or error handling, which are crucial for a listing tool. Without annotations or output schema, the description should compensate more to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional value is required or provided beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('design styles'), specifying it returns 'all available' items with 'basic information'. It distinguishes from siblings like webforge_get_style_details (which likely provides detailed info) and webforge_list_palettes/projects (different resources). However, it doesn't explicitly contrast with webforge_recommend_design, which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when to choose this over webforge_get_style_details (for basic vs. detailed info) or webforge_recommend_design (for listing vs. recommendation). The description implies a general listing function but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top 5 design recommendations (style + palette combinations) for a business type
| Name | Required | Description | Default |
|---|---|---|---|
| business_type | Yes | Type of business (e.g., "restaurant", "cafe", "dental clinic", "law firm") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'top 5 design recommendations,' but does not explain how recommendations are generated, if there are rate limits, authentication needs, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. It wastes no words and clearly communicates the tool's purpose without unnecessary details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not address behavioral aspects like how recommendations are selected, potential errors, or return format, which are crucial for an agent to use the tool effectively in a complex environment with multiple sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'business_type' well-documented in the schema. The description adds no additional parameter semantics beyond implying the tool uses this input to generate recommendations, so it meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top 5 design recommendations (style + palette combinations) for a business type.' It specifies the verb ('Get'), resource ('design recommendations'), and scope ('top 5'), but does not explicitly differentiate from sibling tools like 'webforge_get_style_details' or 'webforge_get_palette_details' that might provide related but different information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare it to siblings such as 'webforge_list_styles' or 'webforge_list_palettes', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing website project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID to update | |
| name | No | New project name | |
| business_type | No | New business type | |
| description | No | New project description | |
| style_id | No | New style ID to assign | |
| palette_id | No | New palette ID to assign | |
| domain | No | New custom domain | |
| status | No | New project status |
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. While 'Update' implies a mutation operation, the description doesn't specify permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with 8 parameters and no annotation coverage, this represents a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with a single, clear sentence that communicates the core function without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address important contextual aspects like what happens on successful update, error conditions, permission requirements, or how this tool relates to the sibling tools in the server's ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 8 parameters. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description doesn't provide additional context about parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing website project'), making the purpose immediately understandable. However, it doesn't differentiate this update operation from other project-related tools like 'webforge_get_project' or 'webforge_create_project', which would require more specific scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'webforge_get_project' for reading and 'webforge_create_project' for creation, there's no indication of when this update operation is appropriate versus creating a new project or using other tools for related functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. The tools cleanly separate into project management (create/get/list/update), palette operations (get/list), style operations (get/list), and design recommendations, with no overlapping functionality.
All tools follow a perfect verb_noun pattern with consistent webforge_ prefix. The naming convention is completely uniform across all 9 tools, making them predictable and easy to understand.
With 9 tools, this server is well-scoped for website design/creation. Each tool earns its place by covering distinct aspects of the domain without being overwhelming or too sparse.
The toolset provides excellent coverage for project management and design element discovery. Minor gaps include the inability to create/update palettes or styles, and no direct deployment/publishing tools, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, edit, preview, publish, and manage web pages from MCP-capable AI clients.
MCP layer for local businesses: discover, query, book, and transact with verified SMB AI agents.
Hosted MCP for creating, checking, deploying, and hosting static sites for AI agents.
AI agent website builder. Create and publish link-in-bio sites via MCP or REST API.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/joytorm/webforge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
