An AI assistant can draft a report from the text you paste into a chat. It cannot safely assume it can see your CMS, repository or documents. To work with an outside system, the application needs an integration that exposes data or actions.
The Model Context Protocol (MCP) provides a common way for an AI application to discover and use capabilities offered by a server. The protocol does not itself grant access to every system or replace the permissions checked by those systems.
The pieces of an MCP connection
A useful mental model has four parts:
| Part | Responsibility |
|---|---|
| Host application | Runs the assistant experience and manages connections |
| MCP client | Communicates with a particular MCP server for the host |
| MCP server | Exposes capabilities backed by an integration |
| Underlying system | Stores the data or performs the operation under its own rules |
The server might communicate with a website, a file service, a database or an API. It can be local or remote, depending on the implementation. The model helps determine what information or action is useful; the application and server handle the actual connection.
A connection is not the same thing as blanket access. Available operations, authentication and approval behaviour vary by application, server and deployment.
Tools, resources and prompts
An MCP server can expose tools: named operations with descriptions and input requirements. A tool might list published pages, read a document or create a draft. Read and write operations can have very different consequences, so inspect each tool's purpose and permissions.
A server may also offer resources that provide context, and prompts that help structure common workflows. Support varies: do not assume every server supplies all three, or that every host presents them in the same way.
For example, a CMS integration could expose a read-only page listing and a separate editing operation. Whether the latter is usable depends on the actual server and authorisation. An assistant that sees only a list of titles should not claim it has read every article.
A request, step by step
Suppose an editor asks: “List the published articles and suggest gaps in our coverage.”
- The host identifies the capabilities available from the connected server.
- The assistant chooses a suitable read operation and supplies its arguments.
- The host sends the request to the server.
- The server checks access, obtains the data and returns a result or error.
- The assistant uses that result as context and explains its findings.
This is a conceptual example, not a transcript of a particular API call. If the editor later wants a draft saved, that is a separate operation whose permissions and result need checking. A proposed draft in the conversation is not proof that anything was stored in the CMS.
MCP and APIs serve different layers
An API defines operations for a particular system. An MCP server can offer a consistent interface to some of those operations so compatible applications can discover and invoke them. The server may call the original API internally; it still has to implement the integration and respect the underlying service's rules.
MCP is also not a model. The model, host, client, server and data source play different roles. A common protocol can reduce integration friction, but it cannot guarantee that a server offers the exact operation your workflow needs.
Practical uses
For content teams, a read-only integration can retrieve a page inventory, inspect a selected article or help prepare a list of potential edits. With separately authorised write capabilities, a supported server might save a draft or update a specified object. Verify the actual tool result and then read back the stored record.
For reporting, an assistant can compare metadata across the pages returned by a server and distinguish missing fields from recommendations. Give it a clear source and scope; a plausible answer based on incomplete records still needs verification.
Multiple connected services can support a workflow, but you should understand what data moves between them. Availability of two connectors is not permission to share all information from one service with the other.
Security boundaries to establish first
Trust the server source. Review who operates the integration, what tools it exposes and which systems it can reach. A protocol label is not a security certification.
Grant minimum access. Start with read-only access where possible. Add write permissions only for an actual need, and periodically remove access that is no longer required. Use the integration's authentication flow rather than pasting passwords or tokens into a prompt.
Treat retrieved content as data. A web page or document may contain instructions that attempt to redirect the assistant. Those instructions are not the user's authorisation to reveal secrets, change settings or send messages. Define which sources are trusted for facts and which actions need human review.
Verify outcomes. A successful-looking conversation is not a confirmed publication. Check the target system's status and saved object. If an external send has an ambiguous outcome, reconcile it before retrying: a second request could create a duplicate.
A safe first experiment
Choose a low-impact read task, such as listing published pages. Inspect the available tools and the information the connection can access. Run the request, compare the result with the source and record any gaps. Only then consider a tightly scoped draft or edit with an explicit recovery plan.
The goal is a workflow whose data sources, permissions and results you can explain—not a connection with the broadest possible access.
Read the original Russian article on Morlix.
Top comments (0)