How PartnerMCP works

PartnerMCP is an AI Integration Engineer. You tell it which systems should connect and what should happen between them. It discovers both systems, proposes a plan, builds the integration, proves it in a sandbox, deploys it when you approve, and keeps operating it. This page walks through each stage, and the one principle that shapes all of them.

Intelligence at design time, determinism at runtime#

PartnerMCP's intelligence does the engineering work: reading schemas, proposing mappings, generating integration logic, writing tests and diagnosing failures. What runs in production is different in kind. It is a versioned integration spec that someone on your team approved, executed step by step, the same way every time.

Nothing improvises against your ERP. When PartnerMCP finds a better way to do something — a mapping fix, a validation step, a slower request rate — it proposes a new version, proves it in a sandbox and applies it only within your policies. Changes outside the classes you pre-approved wait for a person.

The lifecycle#

Every integration moves through the same eight stages. The first five happen at design time. Deploy, operate and change repeat for as long as the integration runs.

01Describe

You state the systems and the outcome in plain language: “When an Opportunity is Closed Won in Salesforce, create the customer and the sales order in Priority, and send delivery and invoice status back.” PartnerMCP restates what it understood — source, trigger, target, what flows back — before it touches anything.

02Discover

PartnerMCP reads both systems through their supported interfaces: objects, fields, required columns, keys, authentication, rate limits and the ways each system can report changes. For Priority that means the OData metadata ($metadata, or GetMetadataFor for one entity); for a custom system, its OpenAPI, GraphQL or WSDL description. Discovery is read-only.

03Plan

It proposes an “I will:” plan — the steps, the field mappings with a confidence and a reason for each, and the questions only you can answer, such as which system owns pricing or how existing customers should be matched.

04Build

Once you accept the plan, PartnerMCP writes the integration as a spec: the trigger, the steps, the mappings, the policies — retries, rate limits, duplicate protection, what happens to a record that fails validation — and the tests.

05Test

The spec runs against sandbox environments with fixtures: the happy path, duplicate events, missing data, rate limiting, rejected records. A failing case is fixed or shown to you with an explanation; nothing is promoted with a known failure hidden.

06Deploy

Promotion to production requires an approval from the people your policy names. Each deployment is a numbered version, and the previous version stays one step away.

07Operate

In production, PartnerMCP watches every run. It retries what is safe to retry — HTTP 429 and 5xx responses, for example — holds records that fail validation for review instead of retrying them blindly, and notices when a system's schema changes.

08Change

When you need something different — “don't create ERP orders below $500”, “notify the sales manager when an order above $100K fails” — you ask. PartnerMCP answers with a diff, its expected impact and fresh test results, and the change ships as the next version.

What an integration is made of#

The spec is the integration. It is readable, diffable and versioned, and it is what your reviewers approve. An abridged example:

integration: salesforce-priorityversion: 1.4trigger:  on: salesforce.Opportunity           # Change Data Capture  when: IsWon = true                   # stage labels differ per orgsteps:  - match: priority.CUSTOMERS          # stored customer number first, then VAT number  - create: priority.ORDERS            # lines go to ORDERITEMS_SUBFORM    idempotency: Opportunity.Id  - writeback: salesforce.Opportunity  # ORDNAME, ORDSTATUSDESpolicies:  retry: [429, 5xx]  on_validation_error: hold-for-reviewtests: fixtures/*.yaml

Field mapping explains how the mappings inside a spec are decided; Change management explains how versions move between environments.

What stays with you#

• Approval. Production changes wait for the people your policy names for that integration.
• Credentials. Each connection uses a least-privilege account you create. For systems inside your network, credentials can stay there — see Edge Agent.
• History. Every request, plan, test run, approval and deployment is recorded with who or what initiated it.
• Understanding. The spec says what the integration does in terms your team can read, so the knowledge doesn't live in one person's head.