Amply MCP Server: What Shipped Since Launch

Two grants got wider without asking

On 30 July, seven tools were added to scopes that already existed. Every unexpired token holding those scopes gained the new tools immediately. No new consent screen appeared, because from OAuth's point of view nothing about the grant changed — only what the scope covers.

• prices:write gained five tools: price_entry_update, price_batch_delete, price_index_create, price_index_update and price_index_delete. Editing and deleting a draft, and managing custom per-territory multiplier sets.
• campaigns:read gained applications_list, which returns the applications in a project. It carries no secrets, and targeting.application is unusable without it.

If you granted prices:write or campaigns:read before 30 July, your existing tokens can now do more than they could when you approved them. Review your authorizations and re-issue anything you would not grant today.

The mirror case is apps:write, which is a brand-new scope rather than a widened one. Existing clients do not have it and cannot reach the provisioning tools until they reconnect. If you want an agent to create projects or applications, that reconnection is required work.

Behaviour changes that need no code from you

Targeting is one flat conjunction — there is no OR

The campaign schema previously described targeting as OR-ed groups. That was the flat opposite of what the engine does: every targeting element is combined with AND, and there is no OR anywhere in Amply targeting. The description was corrected on 30 July.

This is the one change here that could have produced wrong campaigns rather than refused ones. If an agent built targeting for you before 30 July and split conditions expecting either branch to match, it was selecting a narrower audience than intended. Re-read any campaign with more than one targeting condition.

Repeat rules that could never fire are now refused

As of 6 August, a repeat rule with no values is rejected at every nesting level, and so is a repeat count below 1. Both were previously accepted and both produced a campaign that could never fire: an empty value list compiles to a condition the SDK evaluates as false, which then kills the surrounding rule.

Calls that used to succeed quietly now fail loudly. That is the fix rather than a regression — a refused call is recoverable, a campaign that silently never fires is not.

New: the campaign surface matches the dashboard

Before 30 July, an agent could build most of a campaign and then hand you a half-configured draft to finish by hand, which is worse than no agent at all. The parity work closed that gap.

Five targeting conditions were added. All nine slots the admin panel offers are now accepted: country, application, app_version, os_version, plus the new app_install_version, custom_property, install_date, event_count and event_date. The last two target on event history — how many times someone did something, or how long ago they last did it.

{
  "project_id": "8f3c1d20-4a5b-4c7e-9f10-2b6d8e4a1c33",
  "name": "Win-back offer for lapsed non-premium users",
  "type": "DeepLink",
  "content": { "url": "happens://offer/winback" },
  "triggering": {
    "event": { "name": "SessionStart", "type": "system" },
    "repeat": {
      "repeat_type": "every",
      "repeat_entity": "session",
      "repeat_value": [3]
    }
  },
  "targeting": [
    {
      "custom_property": {
        "key": "is_premium",
        "compare_type": "equal",
        "value": "false",
        "value_type": "boolean"
      }
    }
  ]
}

That call now succeeds where it would previously have been refused for the custom_property element alone. Note that repeat_value is always an array, even for a single number, and that every targeting element is ANDed with the rest.

campaign_update lets an assistant correct its own work. Before it existed, an agent that got a campaign slightly wrong could only create another draft alongside the first. One caveat matters more than the feature: the tool replaces rather than patches. Every field you omit is overwritten with nothing, so leaving out targeting wipes the audience.

An update always returns the campaign to Draft — including a campaign that is currently live, which comes off users immediately. That is why the tool sits under campaigns:write and not campaigns:publish: an edit can only ever take a campaign away from users, never put one in front of them.

Three smaller additions land in the same wave. sub_repeat expresses one nested repeat rule, for “every second session, then every third event within it”. A campaign can finally say it has no frequency limit at all, which is both the admin panel's default and the commonest configuration in production, and was previously inexpressible. And campaign_get now returns campaigns in the same vocabulary the write tools accept, so an agent can read a campaign, change one field, and write it back without translating between two shapes.

Trigger event parameter filters are also carried now instead of being silently dropped. Previously a trigger meant for one custom property fired on every property the app reported.

New: provisioning from nothing

With apps:write, an agent can take an empty account to a working setup: project_create, then application_create, then api_key_create. All three require your Amply user to be an administrator of the organization, a check the tools add on top of the scope.

Two of these return live credentials. application_create hands back an SDK secret in its response, and api_keys_list returns the existing keys of an application with their secrets in plaintext. That is why a nominal read like api_keys_list is filed under a write scope: it is the only scope whose consent text tells a person that a key obtained this way keeps working after the grant is revoked.

Note the asymmetry. Reading keys needs the scope but not administrator rights, because those keys are already readable by any organization owner in the Amply UI. Creating one needs both.

What has not changed

None of the above touched the permission model, which is worth restating because it is the part people most often assume works differently.

The split that does the work is between write and publish. campaigns:write can build anything and ship nothing. A client granted it without campaigns:publish is a correct configuration, not a broken one — if a draft will not go live, check the grant before treating it as a bug. The same separation governs prices: creating a price change and sending it to Apple or Google are different permissions.

A tool whose scope you did not grant is absent from the tool list entirely, rather than present and refusing. An agent holding only campaigns:read cannot see that campaign_activate exists.

There are 32 tools in total: 31 behind those eight scopes, plus amply_ping, which needs none. Revoking a grant takes effect on the client's next request.

Some things remain outside MCP by design. Amply does not send push notifications, email or SMS, and never has. Amply does not render UI — a popup is your app responding to a deeplink Amply fired. There is no built-in A/B testing with statistical significance. Rounding, promotional offers and introductory offers stay in the web UI rather than the price tools.

Availability

The MCP server is available on every plan. The campaign, statistics, provisioning and ping tools carry no plan gate.

The price tools are the exception, and the gate is on the pricing features rather than on MCP: the read, draft and dispatch tools require price management on your plan, and the three custom-index tools require the custom price index feature separately. The two toggle independently, so one refusing while the other works is your plan doing what it is configured to do.

Connecting

There is nothing to install and no key to paste. The agent asks for access in your browser, you approve the scopes it requested, and you can revoke the grant later from the Amply admin.

claude mcp add --transport http amply https://api.amply.tools/mcp

Any MCP client that speaks HTTP can connect to the same endpoint. Start by granting the read scopes only, let the agent describe your campaigns back to you, and add write and publish once you can see what it does with them.

The Takeaway

• Check your existing grants. Seven tools were added to scopes that were already granted, so tokens issued before 30 July can now do more than they could when approved.
• Re-read multi-condition targeting built before 30 July. Targeting is one flat conjunction; the schema previously described it as OR-ed groups.
• The campaign surface now accepts every shape the dashboard does, including the five added targeting conditions, nested repeat rules, and campaign_update.
• campaigns:write still cannot put anything in front of a user. Only campaigns:publish does that, and it is granted separately.