A CRM assistant can retrieve every field in a lead record and still prepare the wrong handoff. It might miss a recent customer correction, confuse an empty field with a negative answer, or assign a case the operating team would keep in review. Connecting the CRM solves access. The team still has to describe its procedure and decide how the application enforces it.
Agent Skills and the Model Context Protocol address different parts of that work. A skill packages instructions and supporting resources for a task. MCP gives an AI application a standard interface for communicating with servers that expose tools and context. Together, they can support a business workflow, but the outcome depends on the procedure, the integration and the application's controls.
What a skill actually contains
The Agent Skills format uses a folder containing SKILL.md, with a name, description and task instructions. Optional folders can hold scripts, references or templates. Its progressive loading scheme starts with metadata, loads the instructions when relevant, then reads supporting resources as needed. That helps an agent discover a procedure without loading the entire library into every request. Agent Skills: format and progressive loading
For our hypothetical CRM assistant, I would package the operating team's qualification procedure as a skill. It would specify the fields needed for a handoff, how to represent unanswered questions and which conflicts require an operator. A dated reference could explain a particular product's requirements. The CRM record itself would stay in the CRM, where the team can update and govern it.
What MCP adds to the application
MCP's architecture separates the host application, its clients and the servers they communicate with. Servers can expose tools, resources and prompts. The protocol defines context exchange; it does not prescribe how the application manages its model or uses that context. A CRM tool therefore needs a documented contract for its inputs, returned fields and failures. MCP: architecture and scope, version 2026-07-28
| Layer | What it supplies | What the team must own |
|---|---|---|
| Skill | Qualification steps, reference files and a handoff template | A reviewed procedure, version and named maintainer |
| MCP integration | Tools to read records and request permitted updates | Field contracts, access scope and explicit errors |
| Model | A proposed classification or summary using the supplied evidence | Evaluation of mistakes and missing evidence |
| Application | Record-version checks, permitted writes and result logging | Enforced rules, operator review and recovery |
A skill can also include executable scripts. A procedure-only skill paired with MCP is one architecture, rather than a requirement of either standard. Choose where code runs based on the task and the access it needs. Installing a useful procedure should not silently expand the assistant's credentials.
Carry one lead through a conflicting record
Consider a fictional lead, L-204. The CRM says the requested service is unknown. A newer message says the customer needs a renewal review, while an older note says new coverage. The skill requires a clear service request and an assigned owner before handoff. We have enough information to prepare a review item, but the inconsistent notes need to remain visible.
The read tool would return the record ID and version, plus message identifiers and timestamps. The assistant could propose renewal review and explain which message supports it. If the timestamps or sender identity cannot be established, I would keep the service unresolved. The proposed output below is illustrative; it is an application contract, not a standard MCP response.
lead_id: L-204
read_record_version: 18
proposed_service: renewal_review
evidence: message-77
conflict: older note says new coverage
status: needs_operator_review
write_performed: falseBefore an operator releases that handoff, the application reads the current record again. Suppose another employee has assigned the lead and corrected its service at version 19. Applying the old proposal could overwrite their work. Our proposed application would reject the stale version, show the changed fields and ask for a new decision. That requirement belongs in the integration design even if the skill tells the agent to check freshness.
Evaluate selection, execution and the handoff separately
Anthropic recommends developing skills from observed capability gaps and watching how agents use them in representative tasks. It also warns that skills can contain instructions and code with security consequences, so their bundled files and external connections need review. Anthropic: evaluating skills and reviewing their contents
For the CRM example, I would evaluate three questions independently. Did the assistant select the intended procedure? Did the tools return the correct lead and evidence? Could the operator understand and resolve the proposed handoff? Recording those outcomes separately helps the team repair the failing component. Rewriting a skill will not fix a tool that returns the wrong customer.
| Test input | Expected behavior | Evidence to inspect |
|---|---|---|
| A complete lead with consistent messages | Prepare the intended handoff | Correct record, fields and source references |
| A required answer is missing | Keep it missing and request review | No invented qualification or hidden default |
| Two messages contradict each other | Expose the conflict | Both sources visible to the operator |
| A CRM field changes after the read | Reject or recompute the stale proposal | Version check and no overwritten correction |
| An integration denies the write | Show a blocked handoff | No success status without a recorded result |
Start with the existing CRM workflow
First check whether the CRM's current rules, templates or automation already handle the problem. A deterministic workflow may be sufficient when all inputs are structured and the conditions are stable. A skill becomes useful when the assistant needs a maintained procedure while interpreting varied material. MCP becomes useful when the chosen host and integration benefit from a shared tool interface. Neither requires replacing a working CRM.
Start with one qualification queue and a tool that can only read. Ask an operator to review the proposed handoffs against real examples before adding writes. Track incorrect handoffs, missing evidence and operator correction time; agree acceptable limits before enabling any change. Our article on document-agent permissions covers the separate boundary between incoming text and authority to act. Read: document agents and execution permission
