Skip to main content
Glama

Create website from template

create_website_from_template

Instantly make a finished website in the person's own WeInc account from one of WeInc's ready-made designs, personalised with their business name and details. Takes about a second and returns the editor link where they can see it, change anything and publish. A few general sections (such as service highlights) are placeholder text for the person to edit. Can be called with only the business name; other details are optional and the person can change anything afterwards. Pass template_id from find_templates, or leave it out and give business_type and/or description so the best design is picked. Only pass details the person actually gave; never invent a phone number, email or city. The new site is not published; offer publish_website afterwards if the person wants it live.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "business_name": "<business_name>"
    },
    "name": "create_website_from_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoTown or city it serves, if given.
emailNoContact email, if given.
phoneNoPhone number, if given.
descriptionNoA sentence or two about the business, in the person's words.
template_idNoDesign id from find_templates (optional).
business_nameYesThe business name, exactly as the person gave it.
business_typeNoWhat the business is, e.g. 'bakery' or 'plumber'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / publish
      Removed value: -{
      -  "description": "Also put it live on weinc.app right away (same as publish_website). Only when the person asked for it to go live.",
      -  "type": "boolean"
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / publish
      Added value: +{
      +  "description": "Also put it live on weinc.app right away (same as publish_website). Only when the person asked for it to go live.",
      +  "type": "boolean"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write, and the description is consistent with that. It adds value beyond the annotations by disclosing the returned editor link, the roughly one-second latency, placeholder sections the person must edit, and the crucial state fact that the new site is NOT published. It stops short of saying what happens on failure or whether repeat calls create duplicates (relevant given idempotentHint=false).

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?

Front-loaded with the action and outcome, then call-shape variants, then the safety constraint, then the follow-up. Every sentence carries information, though the two separate speed claims ('Instantly' and 'Takes about a second') are mild redundancy in a fairly long description.

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?

There is no output schema, and the description compensates by naming the return value (editor link). Combined with the unpublished-site state, placeholder caveat, and follow-up routing to publish_website, an agent has everything needed to call this correctly and to set expectations afterwards.

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 description coverage is 100%, so the baseline would be 3; the description earns a notch more by explaining the conditional relationship between template_id and business_type/description and by naming find_templates as the source of template_id. It also constrains value provenance ('only pass details the person actually gave'), which the schema alone does not convey.

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?

States a specific verb and resource ('make a finished website ... from one of WeInc's ready-made designs') and ties it to the find_templates and publish_website siblings, so an agent can place it in the workflow. It does not address how this differs from the sibling start_website, which is the one remaining ambiguity about which creation tool to pick.

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?

Gives explicit call shapes: 'Can be called with only the business name', then 'Pass template_id from find_templates, or leave it out and give business_type and/or description', and states the follow-up condition 'offer publish_website afterwards if the person wants it live'. It also warns to pass only details the person actually gave, which is a real behavioural constraint on invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources