The Salesforce MCP server gives an agent access to your org: standard and custom objects, records, and reports. Salesforce holds the commercial history of a business and makes getting anything non-standard out of it a project, which is what makes agent access valuable here.
What it actually does
The server authenticates through OAuth and exposes the org’s data model. The agent can describe objects to learn their fields, query records with filters, follow relationships between objects, and read reports. Object description is the critical step, because every org’s schema is different and the field that matters is usually a custom one with a name only your team would guess.
Practical patterns:
- ‘Which opportunities closed lost this quarter, and what reason was recorded?’
- ‘Find accounts with no activity in 90 days that have an open opportunity.’
- ‘What custom fields exist on the Contact object, and which are actually populated?‘
Why use it
Getting a specific answer out of Salesforce normally means building a report, which means knowing the report builder and the schema. Most people who have the question do not have both, so the question does not get asked. An agent that can describe the schema and query it removes that gate, and the last example above is one almost every admin wants answered and almost nobody has time to check.
Gotchas
Org customisation is the recurring problem. Field names, picklist values and record types are all local conventions, and an agent will interpret an ambiguously named field the obvious way rather than your way. Sanity-check any number before circulating it. Use a dedicated integration user with a narrow permission set; Salesforce’s sharing model is real security in a way that instructions in a prompt are not. Writes are riskier than in a plain database because they fire workflows, validation rules and alerts that colleagues will see.
