Skip to main content
Glama
Sign In

AdCopilot

by cloud.adcopilot.mcp
OverviewDiscussionsAdmin

AdCopilot: save business notes and progress

save_org_context
Destructive

Stores what the user has said about their business, the onboarding stage reached, an optional decision record, an optional routine, and a note about this session, so a later conversation can continue from it. Partial merge — fields not sent are left unchanged; a field that is sent replaces its saved value, and the earlier value is not kept. stage accepts one of: new, profile, first_read, first_build, first_enable, routine, done. Some profile fields are server-owned (what is verified, what was activated, the decision log) and are not writable here; the first campaign is recorded by the server when it is built. A routine with a daily entry signs the workspace up for AdCopilot's emailed daily check-in. A decision is added to a log; once it is full, a new one pushes out the oldest. Only the workspace owner can sign up for the daily check-in, which is emailed only to the owner's own address. Returns saved, refused and warnings describing what the server did with the request.

Tools revision: d80f65c0.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_org_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
patchNo
stageNo
routineNo
decisionNo
customer_idNoA Google Ads customer id. With it, the business fields in `patch` are saved to that account's business profile, and the other fields to the workspace's.
own_businessNoWith `customer_id`: true when that account is the user's own business (its business fields are then saved to the workspace's profile), false when it is a client's.
session_noteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / $defs / Budget / description
      Previous value: -"Major units in the account currency — never micros (spec §5.8/§8.3)."New value: +"Amounts in the account's currency, in ordinary units, never micros."
    • changedInput schema / $defs / FirstCampaign / description
      Previous value: -"Write-once, and only while null (§5.2). `enabled_seen_at` and\n`walkthrough_shown_at` are server-owned and are deliberately absent here."New value: +"The first campaign built for this workspace. It is saved once; a\ndifferent campaign is not accepted after that."
    • changedInput schema / $defs / ProfilePatch / description
      Previous value: -"Exactly the model-writable §6.1 v1 keys — a test pins this field set to\n`tenants.PROFILE_KEYS`, the store's list, so the schema can never advertise\na key the store then refuses. `business_type` and `brand_terms` exist for\nSpec C's checks G05/G46 — P1 populates, never reads (§2.2)."New value: +"The business profile fields to save. A field left out keeps what is\nalready saved."
    • changedInput schema / $defs / RoutineSpec / description
      Previous value: -"`in_app` is absent by design, from `status` and from `surface` alike: a\nserver-side run is switched on only where we can prove a human clicked\n(§8.4, res. 3). The caps and the audit columns are server-owned and absent\nfor the same reason."New value: +"A daily or weekly check-in. From here it can be recorded as set up in\nthe user's own AI client, skipped or off. AdCopilot's own emailed\ncheck-in is switched on, paused or moved in the dashboard's Check-ins,\nnot from here."
  2. Changed2 schema fields changed
    • addedInput schema / properties / customer_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A Google Ads customer id. With it, the business fields in `patch` are saved to that account's business profile, and the other fields to the workspace's.",
+  "title": "Customer Id"
+}
    • addedInput schema / properties / own_business
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "With `customer_id`: true when that account is the user's own business (its business fields are then saved to the workspace's profile), false when it is a client's.",
+  "title": "Own Business"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Against annotations that only flag destructive=true and idempotent=false, the description explains exactly what is destroyed: partial merge, sent fields replace saved values, and prior values are not kept. It also discloses the decision-log FIFO eviction, the owner-only emailed check-in restriction, and the returned `saved`/`refused`/`warnings` envelope, so write semantics and authorization limits are both explicit and consistent with the annotations.

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 primary purpose before the merge rules and edge cases, and nearly every sentence carries distinct operational information. It is dense and sentence-length is long, but the density is justified by the low schema coverage rather than 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 seven-parameter mutation with no output schema and thin schema descriptions, the definition covers the parts an agent would otherwise get wrong: merge semantics, stage values, server-owned fields, and the return envelope. Minor gaps remain — no pointer to the read counterpart and no description of the `accounts`/`brand_terms` structures.

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 coverage is only 29%, and the description compensates substantially: the `stage` parameter is typed as a bare string in the schema, and the description supplies the full accepted set (new, profile, first_read, first_build, first_enable, routine, done). It also clarifies merge behavior for `patch` and the meaning of `routine.daily`. Coverage of the remaining nested fields (`customer_id`, `own_business`, `session_note`) is left to the three parameter descriptions already in the schema, and fields like brand_terms and accounts get no mention.

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 sentence gives a specific verb-plus-resource set: it stores business notes, the onboarding stage, an optional decision record, an optional routine, and a session note so a later conversation can resume. That is far more than a restatement of the name and makes the payload unmistakable. It loses a point only because it never names the read-side sibling (`get_org_context`), so the save/load pairing is left to be inferred from the tool name.

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?

Usage context is clear — persist state across sessions — and it adds real preconditions: server-owned profile fields are not writable here, the first campaign is recorded by the server, and only the workspace owner can enable the emailed check-in. What it lacks is an explicit routing statement such as 'read current state with get_org_context before calling' or a when-not-to-use exclusion.

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

All AdCopilot 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