Skip to content
PartnerMCPPartnerMCP

§00Product

Early access

The integration engineer that doesn’t leave when the project ends.

Most integrations stop at handover: the people who built them move on, and every change becomes a new project. PartnerMCP builds the integration from what you describe, then stays to operate it, explain it, repair it within your policy and change it when you ask.

Start BuildingSee the architecture
Build by talkingProject handoverevery change loops back through plan · build · test · approval01IntentYou describe02DiscoveryIt reads03PlanIt proposes04BuildIt generates05TestIt proves06DeployYou approve07OperateIt operates08ChangeYou ask
On this page
  1. 01Intent
  2. 02Discovery
  3. 03Plan
  4. 04Build
  5. 05Test
  6. 06Deploy
  7. 07Operate
  8. Self-healing
  9. 08Change
  10. Architecture
  11. The spec
  12. Glossary
§01—Build by talkingStages 01–06

Build it by talking.

Say what should happen. PartnerMCP reads both systems, proposes a plan, builds it, proves it in a sandbox, and ships it when you approve.

01IntentYou describe

Start with the outcome, in your words.

No canvas, no connector catalogue. Describe what should happen the way you would brief an engineer. PartnerMCP marks what it recognised: the systems, the trigger, the actions.

  • Systems it knows, or one it learns from an API spec
  • Anything ambiguous becomes a question, not a guess
New integration
Draft

What should happen?

When an Opportunity is Closed Won, create or update the customer in Priority, create the sales order, and send delivery and invoice status back to Salesforce.

What PartnerMCP understood

SourceSalesforce · Opportunity
TriggerIsWon = true
TargetPriority ERP · CUSTOMERS, ORDERS
Sync backfulfillment + invoice status
Product preview · sample data

02DiscoveryIt reads

It reads both systems before it writes a line.

With read-only, least-privilege access, PartnerMCP reads each system's objects, fields, events and limits, plus the rules that quietly break integrations.

  • Schemas from each system's own metadata
  • Limits and quirks from the vendor's documentation
  • Nothing is written during discovery
Discovery
Sandbox
Salesforce connected
Interface
REST + Pub/Sub API
Objects
Account · Opportunity · OpportunityLineItem · Product2
Changes
Change Data Capture (Pub/Sub API)
Trigger
IsWon = true
Priority connected
Interface
REST (OData v4)
Forms
CUSTOMERS · ORDERS · ORDERITEMS_SUBFORM · DOCUMENTS_D · AINVOICES
Changes
$since polling · BPM webhooks
Limits
100 calls/min per API user · 15 requests in flight

Rules that break naive integrations

  • CUSTNAME is the customer number, not the nameNames map to CUSTDES
  • Priority assigns order numbers (ORDNAME)Store the Opportunity ID; check before every create
  • $batch has no rollbackIdempotency keys; resume from the failed line
  • REST skips row-level data privilegesLeast-privilege API user; PartnerMCP applies its own scoping
Product preview · sample data

03PlanIt proposes

A plan you can read, and argue with.

Before anything is built, PartnerMCP writes down what it will do, step by step, and asks you the questions only you can answer, like which system owns pricing.

Plan
Draft

I will:

  1. 1.Detect Opportunities that move to Closed Won in Salesforce.
  2. 2.Match or create the customer in Priority.
  3. 3.Create the sales order with its products, quantities and prices.
  4. 4.Monitor delivery and invoicing in Priority.
  5. 5.Write fulfillment and invoice status back to Salesforce.
  6. 6.Retry temporary failures automatically.
  7. 7.Send unresolved errors for review.

Decision recorded

Which system owns pricing?

Test in sandboxReview architectureDeploy
Product preview · sample data

04BuildIt generates

Then it builds exactly that plan.

Each step becomes part of the integration: the mappings, the idempotency key, the retry policy, and the review queue for records that shouldn't go through.

  • Generated from the plan, never improvised
  • Output: a versioned spec your team can review
Acme Industrial
Draft
  1. SalesforceOpportunity · Closed WonTrigger · Change Data Capture
  2. PartnerMCPCustomer lookupAccount ⇄ CUSTOMERS
  3. PartnerMCPSchema mappingfields · products · prices
  4. PriorityCreate / update customerCUSTOMERS
  5. PriorityCreate sales orderORDERS + ORDERITEMS_SUBFORM
  6. PartnerMCPMonitor orderstatus · delivery · invoice
  7. PrioritySync fulfillmentDOCUMENTS_D
  8. PrioritySync invoice statusAINVOICES
  9. SalesforceUpdate Opportunityfulfillment · invoice status
spec v1.0 · draft10 field mappingsidempotency key: Opportunity IDretries: 429 · 5xx onlyreview queue for held records
Product preview · sample data

05TestIt proves

It proves the plan in a sandbox.

Twelve test transactions against a Priority test company, including the cases that break integrations in production: duplicates, rate limits, partial failures, unknown products.

Sandbox run #14
Test transactions · Priority test company12 / 12
  1. 01New customercreated in CUSTOMERS · number written back
  2. 02Existing customermatched on the stored customer number
  3. 03Duplicate eventignored — idempotency key
  4. 04Order with 5 linesORDERS + ORDERITEMS_SUBFORM
  5. 05Unknown product codeheld for review — not in LOGPART
  6. 06HTTP 429backed off · retried · succeeded
  7. 07Line 3 rejectedresumed from line 3 · no duplicate lines
  8. 08Order totalsDISPRICE reconciled with Opportunity.Amount
  9. 09Closed Lostno order created
  10. 10Request over 3 minre-queued · not duplicated
  11. 11DeliveryDOCUMENTS_D status written back
  12. 12Invoicewaits for the final invoice number
12 / 12 behaved as specified1 held for review, by design0 duplicatesproduction untouched
Product preview · sample data

06DeployYou approve

You approve. It ships. Rollback stays one step away.

Promotion to production is a reviewed step with production credentials of its own. Every deployment is a version you can switch back to.

Promote v1.0
Production
  • Tests12 / 12 in sandbox run #14
  • CredentialsProduction API users · least privilege
  • RollbackOne step · v1.0 can be switched off
  • ApprovalApproved by the integration owner
v1.0 · livechange #208 recordedrollback ready
Product preview · sample data
§02—Operate by talkingStage 07

Operate it by talking.

Once it's live, PartnerMCP runs it, watches it and answers for it, in plain language with the evidence attached.

07OperateIt operates

Ask your integration anything.

What failed, why, what's waiting, what changed. Every answer points to the traces behind it and reconciles against the systems themselves.

  • Answers come from traces, not guesses
  • Reconciled against Priority's own records
Operations
Production
Orders today
412
Failed
0
In review
2
p95 latency
1.4 s

Why are two orders waiting for review?

Both customers have no VAT number in Priority. An Israeli tax invoice above the threshold needs an allocation number from the Tax Authority, and that needs the customer's VAT number.

I held both orders before submission, so nothing was rejected in Priority.

Harbor Supply · renewal$18,400held 2 h
Delta Metals · new order$6,950held 25 min

2 held records · traces pmc-7f3a, pmc-7f3b

Product preview · sample data

07Self-healingWithin policy

Self-healing, inside the lines you draw.

When something breaks, PartnerMCP diagnoses it, proposes a fix and proves it in a sandbox. Fixes in classes you've pre-approved apply on their own and are logged. Everything else waits for a person.

Applies on its own

Classes you pre-approve

  • Retry temporary failures (HTTP 429, 5xx)
  • Slow down under a rate limit
  • Hold a record that fails validation
  • Resume a batch from the failed line

Proposed, then approved

A person decides

  • Map a field that just became required
  • Change a transformation
  • Add a validation step
  • Write to a new object or system

Never automatic

Outside any policy

  • Widen credentials or scopes
  • Delete records
  • Change production outside a versioned release

Defaults shown. You decide which classes apply on their own; nothing in the last column can be pre-approved. How change classes work

Incidents
Production

Rate limit · Thursday

  1. 09:12:04Priority Cloud returned HTTP 429 — fair-use limit, 100 calls/min per API user
  2. 09:12:05Class: rate limit · pre-approved
  3. 09:12:05Concurrency 10 → 4 · backoff with jitter
  4. 09:18:40Queue drained · resumed from the last committed line
Applied on its own · 0 orders lost · logged

Schema drift · today

  1. 02:14Salesforce added a new required field
  2. 02:14Schema drift detected on the write-back step
  3. 02:15Corresponding Priority field identified · fix proposed
  4. 02:1512 sandbox tests executed · 12 passed
Mapping change · waiting for approval

While the drift fix waited, affected records were held — nothing was written with a missing field, and the rest kept flowing.

Product preview · sample data
§03—Change by talkingStage 08

Change it by talking.

Business rules change. Instead of a change request and a new project, you say what's different. PartnerMCP shows the impact, the diff and the tests, then waits for approval.

08ChangeYou ask

A sentence becomes a reviewed diff.

PartnerMCP finds the production integration you mean, writes the change against its current version, replays recent traffic to show the impact, and ships it as a new version once approved.

  • Impact shown before you approve
  • One condition added, nothing else touched
Acme Industrial
Productionv1.4

Don't create ERP orders below $500 anymore.

I’ll add a minimum order value condition to the Salesforce → Priority production integration.

Based on the last 30 days, this rule would have excluded 17 orders.

Apply this change?

Sandbox replay · last 30 days · 17 excluded · 0 errors

v1.4 live · rollback to v1.3 available
salesforce-priority.integration.yamlv1.3 → v1.4
  trigger:    on: salesforce.Opportunity    when: IsWon = true+   condition: Amount >= 500+   else: skip-and-log  steps:    - match: priority.CUSTOMERS    - upsert: priority.CUSTOMERS    - create: priority.ORDERS    - writeback: salesforce.Opportunity

One condition added. No other step changes.

Product preview · sample data
§04—Architecture

Intelligence at design time. Determinism at runtime.

PartnerMCP is split in two. The control plane is where it reasons: it plans, tests and asks for approval. The data plane runs the version you approved, and only that. Systems inside your network are reached through the Edge Agent, over a connection opened from inside.

Control planereasons · design timeData planequeues · idempotency · review · vaultCloudreached directlyYour networkbehind your firewallFirewalloutbound onlyConversationyou askPlannerdiff vs. specApprovalsyour policySandboxproves itAudit logevery changeSpec registryevery versionExecutorruns approved versions onlySalesforceHubSpotStripeEdge Agentoutbound onlyPriority ERPon-premSQL Serverread-only

Walk through it

  1. 01You ask for a change: “Don't create ERP orders below $500 anymore.”
  2. 02The planner writes it as a diff against the current spec, 1.3.
  3. 03The sandbox runner replays the last 30 days to prove the impact.
  4. 04The integration owner reviews the diff and approves it. Nothing ships before this, and the approval is logged.
  5. 05The approved spec is stored as version 1.4, with its diff, its tests and its approver.
  6. 06The data plane picks up 1.4 and runs exactly that. No model sits in the request path.
§05—The integration spec

The integration is a versioned, reviewable artifact.

What PartnerMCP builds doesn't live in a canvas or in someone's head. It's a spec your team can read, review, diff and roll back. Every version starts as a sentence.

Readable
Plain text your team can review — no canvas to reverse-engineer.
Versioned
Every change is a new version with its diff, tests and approver.
Tested
Fixtures run on every version before it can reach production.
Reversible
Roll back to any approved version, the same way you approve one.

History · Salesforce → Priority ERP

Illustrative spec
salesforce-priority.integration.yamlv1.4
# written by PartnerMCP · reviewed by youintegration: salesforce-priorityversion: 1.4trigger:  on: salesforce.Opportunity  when: IsWon = true   # CDC  condition: Amount >= 500  else: skip-and-logsteps:  - match: priority.CUSTOMERS    by: Priority_Customer_No__c -> CUSTNAME    else: create  - upsert: priority.CUSTOMERS    map:      CUSTDES: Account.Name   # name, not CUSTNAME      HOSTNAME: Account.Website      PHONE: Account.Phone    writeback: CUSTNAME -> Priority_Customer_No__c  - validate: CUSTOMERS.VATNUM present    else: hold-for-review  - create: priority.ORDERS    lines: OpportunityLineItem -> ORDERITEMS_SUBFORM    idempotency: Opportunity.Id -> ACME_SFOPPID    reconcile: DISPRICE vs Opportunity.Amount  - writeback: salesforce.Opportunity    fields: [ORDNAME, ORDSTATUSDES, TOTPRICE]alerts:  - when: failed and Amount > 100000    notify: slack · sales managerpolicies:  rate_limit: 100/min   # Priority Cloud, per API user  retry: [429, 5xx]  on_validation_error: hold-for-reviewtests: fixtures/*.yaml   # 17 cases
Names follow Salesforce's and Priority's documentation; PartnerMCP confirms them against each tenant's metadata during discovery.
§06—Glossary

The words on this page.

Integration spec
The readable definition of an integration: trigger, steps, mappings, policies and tests. Every version is kept.
Version
An approved state of the spec. Production runs exactly one version at a time; any earlier one is a rollback away.
Sandbox
A test environment for each system — for Priority, a test company — where every plan and change is proven first.
Change class
A kind of change — a retry, a new mapping, a wider scope — with its rule: applies on its own, needs approval, or never automatic.
Review queue
Where records that shouldn't go through wait, with the reason, until a person fixes or releases them.
Idempotency key
A stable ID checked before every create — here, the Opportunity ID — so a retried event never makes a second order.
Schema drift
A system's fields changing under a running integration: a new required field, a renamed column, a removed value.
Control and data plane
Where PartnerMCP reasons — plans, tests, approvals — and where integrations run: approved versions only.
Edge Agent
Architecture concept: a small agent in your network that connects out to PartnerMCP, so internal systems need no inbound access.

§07Next step

Describe your first integration.

Tell PartnerMCP which systems should connect and what should happen. You'll see the plan before anything is built.

Start BuildingTalk to an engineer