MCP and Automation Without Losing the Boundaries
DeskcommCRM’s extension problem is the inverse of its safety problem: the product must give agents enough power to operate a real sales demand, but it cannot let every tool caller choose an organization, bypass visibility, or turn a failed action into a success claim. This chapter explains MCP as a governed operating surface and then follows event-driven automation from capture to outcome. The reader should leave able to see why authenticated context—not tool input—determines authority, and why a rule run must distinguish waiting, skipping, partial failure, and success.
MCP, the Model Context Protocol, is useful here because it gives an agent a typed way to discover and call operations in an external system. But the protocol does not make an operation safe. Safety comes from the context around the call: who is calling, which organization the token represents, which role and scopes apply, what records are visible, which effects are allowed, and where the call is audited.
A tool call is a request within authority
The current MCP server registers a catalog of CRM tools with descriptions, input schemas, and minimum role and scope. A tool can search or read a contact, inspect a conversation, query a lead, change a stage, manage a tag, or request a human handoff. That catalog gives an agent an operating vocabulary, but it is not a second data model. The tool handler still works against DeskcommCRM’s organization, records, and existing policy boundaries.
Authentication establishes the first boundary. The server extracts a bearer token from the authorization header, hashes the presented value, and looks up the stored token record. The plaintext token is not the organization selector; the token’s stored association is. The current implementation also checks revocation and expiry, derives actor information from scopes, and rejects a token format that does not match the server’s contract. A request without a recognized token is not allowed to become an anonymous CRM action.
The organization is deliberately absent from governance-tool input. An agent cannot call a tool with one organization identifier while presenting a token for another. The server constructs the execution context from the authenticated token and passes that context to the handler. This matters especially in a multi-tenant system because a tool argument is user-controlled data. It can be validated as a UUID and still be the wrong organization. Authority must be derived from the credential, not from a field that the caller is free to write.
Role and scope form separate gates. A token may be allowed to read but not write. An agent role may be able to participate in conversation governance while a manager role is required for a sensitive CRM mutation. A valid token with the wrong scope is still a forbidden request. The distinction lets an operator grant a narrow capability without treating the existence of an API token as permission to do everything the CRM can do.
Visibility can be narrower than the organization itself. DeskcommCRM’s current governance contract describes visibility modes for agents: all conversations, the agent’s own and unassigned work, or only the agent’s own work. The database applies those rules to conversations, messages, leads, and lead children. A tool result is therefore a ceiling, not an invitation to guess that an unseen record exists and try another route. If a conversation is not visible to the authenticated context, the agent should treat it as unavailable rather than trying to bypass the list with a direct identifier.
The same principle applies to operations. An agent’s pipeline scope determines which funnel records it may write. A blocked contact remains blocked at the server-side send path.