Skip to main content
Glama

Agency MCP

by com.jiyumarketing.mcp
OverviewDiscussionsAdmin

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

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe business's name as the agency says it
confirmNofalse previews; true creates
crm_locationNoCRM location id
meta_accountNoMeta ad account, act_…
wordpress_site_idNoWordPress site id from wp_list_sites
analytics_propertyNoGA4 property id, digits only
google_ads_accountNoGoogle Ads customer id
search_console_siteNoSearch Console site exactly as listed, e.g. sc-domain:example.com
acknowledge_mismatchNoOnly 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_locationNoBusiness Profile location id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: default preview-versus-create behavior, name-based account lookup with a mismatch flagged in the preview that blocks creation, the acknowledge_mismatch escape hatch, and the side effect that a client with no open seat is created locked. These are exactly the non-obvious traits an agent would otherwise discover only by failing.

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 core action, then the ID rule, then the preview/mismatch mechanics, then the seat constraint. Dense but every clause carries information; slightly long for a single tool, though nothing is padding.

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 10-parameter mutation tool with no output schema, the description covers inputs, preconditions, blocking behavior, and the billing/seat side effect. It stops short of describing what the preview or the created client returns, which would help since no output schema exists.

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 is 3, but the description adds flow-level meaning to confirm (preview vs create) and acknowledge_mismatch (only after a flagged mismatch and human confirmation) that the schema notes alone do not convey.

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?

Opens with a specific verb+resource+scope ('Create one client (one business) and link its accounts') and states the outcome ('every later question can be asked by the business's name'), which separates it cleanly from list_clients, suggest_clients, and link_account.

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 real operational guidance: pull IDs from suggest_clients or the list tools and never invent them, and note that the tool previews unless confirm=true. It does not, however, contrast explicitly with sibling mutations like link_account or connect_platform for accounts that already exist.

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

All Agency MCP toolsInspect
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.

Resources