Agency Autopilot

Create client

create_client

Create one client (one business) and link its accounts, so every later question can be asked by the business's name. Use the IDs exactly as suggest_clients or the list tools returned them — never invent one. Every account is looked up by name and checked against the client's name: an account that looks like a different business is flagged in the preview and blocks creation until the person confirms it. Previews unless confirm is true. Does not change billing: if the agency has no open seat the client is created locked and waits for a seat.

Input Schema

Name	Required	Description
`name`	Yes	The business's name as the agency says it
`confirm`	No	Leave false to preview: nothing changes and the preview shows exactly what would happen. Set true only after the user has agreed to this exact change.
`website`	No	The client's website address, e.g. https://acmefence.com — for a site built in code that has no WordPress or Search Console link yet
`contact_name`	No	Who at the client gets the weekly Autopilot report, e.g. "Dana Reyes" (the owner)
`crm_location`	No	CRM location id
`meta_account`	No	Meta ad account, act_…
`contact_email`	No	That person's email address; the weekly report is sent there once the agency says send
`report_language`	No	The language the client reads the weekly report in: en (default), es, pt, it, tr, id, fr or de. Blank or en = English.
`wordpress_site_id`	No	WordPress site id from wp_list_sites
`analytics_property`	No	GA4 property id, digits only
`google_ads_account`	No	Google Ads customer id
`search_console_site`	No	Search Console site exactly as listed, e.g. sc-domain:example.com
`acknowledge_mismatch`	No	Only after the preview flagged an account as looking like a different business AND the person has confirmed it does belong to this client.
`business_profile_location`	No	Business Profile location id
`more_analytics_properties`	No	Other GA4 property ids of the SAME business, one per extra site (e.g. a second website). analytics_property stays the main one; up to 3 in all, paid plans only

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / more_analytics_properties / description

Previous value: -"Other GA4 property ids of the SAME business, one per extra site (e.g. a second website). analytics_property stays the main one; up to 5 in all"New value: +"Other GA4 property ids of the SAME business, one per extra site (e.g. a second website). analytics_property stays the main one; up to 3 in all, paid plans only"

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / more_analytics_properties

Added value: +{
+  "description": "Other GA4 property ids of the SAME business, one per extra site (e.g. a second website). analytics_property stays the main one; up to 5 in all",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 4,
+  "type": "array"
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / report_language

Added value: +{
+  "description": "The language the client reads the weekly report in: en (default), es, pt, it, tr, id, fr or de. Blank or en = English.",
+  "maxLength": 20,
+  "type": "string"
+}

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / contact_email

Added value: +{
+  "description": "That person's email address; the weekly report is sent there once the agency says send",
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / contact_name

Added value: +{
+  "description": "Who at the client gets the weekly Autopilot report, e.g. \"Dana Reyes\" (the owner)",
+  "maxLength": 80,
+  "type": "string"
+}

Changed1 schema field changedOct 13, 2026

changedInput schema / properties / confirm / description

Previous value: -"false previews; true creates"New value: +"Leave false to preview: nothing changes and the preview shows exactly what would happen. Set true only after the user has agreed to this exact change."

Changed1 schema field changedOct 9, 2026

addedInput schema / properties / website

Added value: +{
+  "description": "The client's website address, e.g. https://acmefence.com — for a site built in code that has no WordPress or Search Console link yet",
+  "type": "string"
+}

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / acknowledge_mismatch

Added value: +{
+  "default": false,
+  "description": "Only after the preview flagged an account as looking like a different business AND the person has confirmed it does belong to this client.",
+  "type": "boolean"
+}

First observedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: the default dry-run preview, the name-mismatch flag that blocks creation until confirmed, and the seat-limit consequence of creating a locked client. Annotations only say it is a non-destructive, non-idempotent write; the description supplies the real operational consequences. It does not address duplicate-name handling, which is the main remaining gap for a non-idempotent create.

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-loads the purpose and then layers constraints in short, purposeful sentences; every sentence carries operational information. It is dense for a single paragraph but not padded, and the preview/confirm rule is easy to locate.

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 15-parameter create tool with no output schema, the description covers the important unknowns: dry-run default, blocking mismatch condition, and seat-locked outcome. Return-shape detail is unnecessary since previews are self-describing, but the absence of guidance on duplicate clients leaves a modest hole.

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 coverage is 100%, so all 15 parameters are already documented, and the description adds only a little beyond that — chiefly the provenance rule for IDs and the mismatch/confirm interplay. Most parameter meaning still comes from the schema itself, matching the baseline for fully covered schemas.

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 ("Create one client (one business) and link its accounts") and adds the downstream rationale that the business name becomes the addressing key. This clearly separates it from update_client, list_clients, and suggest_clients without needing the 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 concrete sourcing guidance (use IDs exactly as suggest_clients or the list tools returned them, never invent one) and describes the preview-then-confirm workflow, which tells the agent how to sequence the call. It stops short of naming alternatives such as update_client for existing businesses, so it is clear but not fully exclusive.

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

All Agency Autopilot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Create client

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources