Connecting an AI application to a business system creates a new question: what should the application be able to do with that connection? Reading a record, editing it and sending it to someone else are different capabilities.

The Model Context Protocol architecture documentation describes how applications discover available tools and invoke them through a consistent interface. Tool definitions describe purpose and inputs, helping an application understand which operations a server exposes.

Connection, capability and permission

These are separate decisions. A connection establishes communication. An exposed capability describes an operation the application can request. Authorization determines whether a particular request is allowed for the relevant user and resource.

That distinction is an implementation concern, not something a product badge settles. A business evaluating an integration should ask which actions the deployed server exposes and how the underlying service enforces access.

A CRM example

Consider an illustrative assistant preparing meeting notes from a CRM. Its initial job may require searching accounts and reading recent interactions. It does not necessarily need to change an opportunity stage, export the customer database or email a contact.

Our suggested pilot would expose the required read operations first. Developers could then test whether the assistant selects the correct customer, handles ambiguous names and reports missing information accurately. Write capabilities could be evaluated separately against a defined need.

Make the interface understandable

A tool named “update” tells the agent very little. A description should explain the affected object, required identifiers, allowed fields and expected outcome. The response should make a successful change distinguishable from an accepted request that is still processing.

Before adding more operations, inspect the confusing ones. Two nearly identical tools with different side effects can create a harder selection problem than a smaller set with clearer boundaries.

Test the inconvenient cases

  • Two customers share the same display name.
  • A record exists but the user cannot access it.
  • The remote service is temporarily unavailable.
  • A write succeeds but the response is interrupted.
  • A record changes between reading and updating it.

These are proposed test cases for a CRM integration. The expected outcome should include when the agent must stop, ask for clarification or return control to the user.

What to inspect before enabling writes

Review the permissions of the connected account, validation performed by the tool and evidence available after an action. Decide how a user can revoke access and how duplicate requests are handled.

MCP can help make integrations consistent. A reliable business workflow still requires careful choices about identity, authority and recovery. Those choices become more important as an agent moves from retrieving information to changing it.