Skip to main content
Glama

Start a company (no account yet)

start_signup

Creates the company in Guest Logic (a hotel in free test mode) and e-mails the owner one approval link. Use only when the owner has no Guest Logic account. The reply names everything still missing and the tool that fills each. No sign-in needed.

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": {
      "owner_name": "<owner_name>",
      "email": "<email>",
      "business_name": "<business_name>",
      "kind": "<kind>",
      "tools": "<tools>"
    },
    "name": "start_signup"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesWhat the business is
emailYesOwner e-mail (becomes the sign-in)
toolsYesThe tools wanted; pms only with kind hotel
mobileNoOwner mobile number, if you have it; a hotel owner is asked at the approval link otherwise
websiteNoCompany website
time_zoneNoTime zone, e.g. America/New_York
legal_nameNoLegal name of the company
owner_nameYesOwner full name
business_nameYesCompany name: letters, digits, spaces and & ' . - only, up to 60 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the generic profile (not read-only, not idempotent, not destructive, closed-world). The description goes well beyond them by disclosing an external side effect (one approval-link e-mail to the owner), the environment state (free test mode), an auth exemption ('No sign-in needed'), and the shape of the reply ('names everything still missing and the tool that fills each').

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?

Four short sentences, front-loaded with what the tool does before the precondition and the reply format. The parenthetical '(a hotel in free test mode)' is slightly muddled, but no sentence is filler.

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?

For a 9-parameter creation tool with no output schema, the description covers the side effects, the auth situation, the precondition, and what the response contains. It leaves failure paths (duplicate e-mail, retry behavior) unstated, which is the main remaining gap.

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 every one of the 9 parameters is already documented, including the enum constraints and the 'pms only with kind hotel' rule. The description adds no syntax or format detail beyond that, so the baseline 3 is correct.

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?

States a specific verb and resource ('Creates the company in Guest Logic') plus the two effects that matter: the company is created in free test mode and one approval link is e-mailed to the owner. Combined with the title's 'no account yet', an agent can tell this apart from set_company without opening either schema.

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?

Gives an explicit precondition and exclusion: 'Use only when the owner has no Guest Logic account.' That is a real when-not rule rather than an implication, though it never names the sibling (set_company) that should be used when an account already exists.

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