Skip to main content
Glama

Create a project

create_project
Destructive

Create and deploy a project. With serviceId: deploy into that existing service (the same as a deploy). Without serviceId: store the archive (the uploadId of an upload made without a serviceId, or archive as base64 under 1 MiB), analyse it, quote the cheapest server that fits, create the order and return actionId and approveUrl (also mailed to the person; one hour): the person opens it, sees the whole order (server, cost, card) and pays with one click; nothing is charged without that click. domain takes a name found available: the page offers it outside the total and the person adds it with one click (domainNote in the answer says when it could not be offered, or was offered before the registry answered). Once paid, the project deploys on the new server by itself. A partner account can instead have the client pay: payer client with clientEmail and secrets with a value for each secret the project declares; nothing is minted for the partner, the client gets a signup and payment link by mail and pays the regular price in their own account, and the answer carries inviteId. This fits only when the pre-flight needs list has a payer entry. An active partner with servers for client sites (services of kind host) can put the new site on one: hostId with the host's id puts it there for the site fee alone (the answer's mode is on-host and names the server's fit), hostId new buys a server of its own; left out, the site goes where the website's order form would put it. A full server refuses.

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": {
      "name": "<name>"
    },
    "name": "create_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesthe project name shown on the dashboard
payerNowho pays for a new site: self (default, the person approves and pays) or client (a partner sends the client a signup and payment link)
domainNoa full name: one found available (offered on the approval page, added with one click, never charged without it), or one the account already holds (heldDomains), which rides the order for free and points at the new server after its first deploy
hostIdNopartner hosts only: the id of one of the account's services of kind host, or new for a server of its own; left out, the best-fitting host with room, else a new server
archiveNo
secretsNopayer client only: a value for each secret the project declares (handsome.json secrets), by name; never echoed back
uploadIdNo
mailboxesNooptional: the mailbox names at the site's domain the person chose, up to five, such as info or sales; [] for none; left out, info is set up
preflightNothe pre-flight report of the checks run on the person's machine; required: the call refuses without a passing one
serviceIdNothe id of a service on this account
clientEmailNopayer client only: the client's address

Output Schema

NameRequiredDescriptionDefault
okYes
dataNo
errorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / mailboxes
      Added value: +{
      +  "description": "optional: the mailbox names at the site's domain the person chose, up to five, such as info or sales; [] for none; left out, info is set up",
      +  "items": {
      +    "maxLength": 64,
      +    "type": "string"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
  2. Changed5 schema fields changed
    • changedInput schema / properties / clientEmail / description
      Previous value: -"payer client only: the client's address, read back to the person before the call"New value: +"payer client only: the client's address"
    • changedInput schema / properties / domain / description
      Previous value: -"a full name: one the builder found available with search_domain (offered on the approval page, added with one click, never charged without it), or one the account already holds (list_services heldDomains), which rides the order for free and points at the new server after its first deploy"New value: +"a full name: one found available (offered on the approval page, added with one click, never charged without it), or one the account already holds (heldDomains), which rides the order for free and points at the new server after its first deploy"
    • changedInput schema / properties / hostId / description
      Previous value: -"partner hosts only: a host's id from list_services (kind host), or new for a server of its own; left out, the best-fitting host with room, else a new server"New value: +"partner hosts only: the id of one of the account's services of kind host, or new for a server of its own; left out, the best-fitting host with room, else a new server"
    • changedInput schema / properties / preflight / description
      Previous value: -"the pre-flight report from the preflight tool protocol; required: the call refuses without a passing one"New value: +"the pre-flight report of the checks run on the person's machine; required: the call refuses without a passing one"
    • changedInput schema / properties / serviceId / description
      Previous value: -"the service id from list_services"New value: +"the id of a service on this account"
  3. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false/destructiveHint=true; the description goes far beyond by disclosing the full approval flow (actionId/approveUrl, one-hour window, 'nothing is charged without that click'), that a domain is offered outside the total and never charged without a click, that payer=client mints nothing for the partner and returns inviteId, and that a full server refuses. This is exactly the mutation/authorization cost context the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, but the body is a dense run-on of semicolon-joined clauses and nested parentheses (domainNote, registry timing) that is costly to parse. Most sentences do encode a distinct mode, but the parenthetical asides could be trimmed without losing routing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't explain return values, yet it helpfully names actionId, approveUrl, inviteId and mode. The notable gap is preflight: the schema marks it required and says 'the call refuses without a passing one', but the description never mentions this gate, nor mailboxes or preflight.formSendTo, for an 11-parameter destructive tool.

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?

Two opaque schema fields are explained: archive is 'base64 under 1 MiB' (the schema only shows a raw maxLength of 1398106) and uploadId is tied to 'an upload made without a serviceId'. hostId's three-way behaviour (existing host / new / omitted) and payer=client's secrets/clientEmail pairing are also spelled out. Coverage is 82% so the baseline is 3, and the added meaning clears it.

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 opening 'Create and deploy a project' gives a specific verb and resource, and the following text splits the tool into two distinct modes (existing service vs new server via stored archive). It weakens slightly by admitting the serviceId mode is 'the same as a deploy' without telling the agent to use the deploy sibling instead, so the boundary with deploy is stated but not resolved.

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

Usage Guidelines3/5

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

Several strong conditionals are present ('This fits only when the pre-flight needs list has a payer entry', hostId new vs existing host id vs left out). However, with sibling tools deploy, create_wordpress and request_upload available, the description never says when to pick create_project over those alternatives — it only acknowledges the overlap.

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