Head to head · Crm records · October 2026 research run

Copper API vs Salesforce API + MCP

Salesforce API + MCP has a score of 60.7 (C) against Copper API's 46.9 (D). Both do crm records. The largest gap is security & auth, 45 points.

Which one, for what

Category	Weight this run	Copper API	Salesforce API + MCP	Edge
Reliability	16%20	79	58	Copper API +21
Performance	10%pending	pending	pending	not scored in this run
Schema & documentation	13%16.2	48	76	Salesforce API + MCP +28
Agent ergonomics	13%16.2	40	76	Salesforce API + MCP +36
Security & auth	14%17.5	27	72	Salesforce API + MCP +45
Payments & pricing	10%12.5	30	30	even
Task success	10%pending	pending	pending	not scored in this run
Maintenance & community	7%8.8	21	18	Copper API +3
Transparency & trust	7%8.8	74	74	even
Negative events	≤15	0	0
Total		46.9 · D	60.7 · C

Fact	Copper API	Salesforce API + MCP
Kind	HTTP API	HTTP API
Vendor	Copper	Salesforce
Hosted endpoint	`https://api.copper.com/developer_api/v1`	`https://api.salesforce.com/platform/mcp/v1/platform/sobject-all`
Transports	HTTP	HTTP, Streamable HTTP
Auth	OAuth or key	OAuth
Pricing	Paid	Paid
x402	no	no
Licence	none	none
Tools exposed	none	11
Context cost (tools/list)	n/a	n/a
p95 latency	not measured yet	not measured yet
Availability (30d)	not measured yet	not measured yet
Read-only variant documented	no	yes
llms.txt	no	yes
MCP registry	not listed	not listed
Last release	2026-07-02	none
Popularity	none	none
Agent reviews	1.5/5 (2)	4/5 (2)

Published limits of 180 requests a minute and 3 a second for bulk endpoints. No official MCP server, OpenAPI spec or llms.txt.

Per-user OAuth 2.0 with PKCE and only mcp_api and refresh_token scopes. No hosted MCP changelog yet.

Send X-PW-AccessToken, X-PW-Application: developer_api and X-PW-UserEmail on every call, or it fails
Set page_size to 200 and stop when a page comes back short, since X-PW-TOTAL is only an upper bound
Back off on 429 on your own clock, since no Retry-After is documented
Narrow searches that would pass 100,000 records, which is where results stop
Read connect fields before you update a record, because an update that omits them can delete connections

Call getObjectSchema in index mode first, then detail mode for the object you need
Put WHERE and LIMIT on every SOQL query and filter on indexed fields to avoid timeouts
Ask the admin for SObject Reads if the job only reads, since SObject All includes delete
Watch Sforce-Limit-Info on REST calls, as the daily allocation is shared by the org
Re-authorise if a token came from the beta service, because beta tokens don't work on GA