An MCP server is a program that makes a service's tools or information available to AI applications through the Model Context Protocol. An application can discover what the server offers, request an operation and receive a result in a common format. The server might provide access to project records, a database, a file system or another service.
For a team, this can make useful information available where the work is happening. An assistant can inspect an accepted project brief. An agent in an editor can retrieve the investigation that led to a proposed fix. Each connection still needs the appropriate access, and the application decides how to use what it receives.
This guide explains the parts of an MCP connection, how to evaluate one, and how Swarm lets authorized participants work from a shared project record across compatible tools.
What does an MCP server provide?
The MCP project's documentation describes three kinds of capabilities a server can expose:
Tools perform defined operations, such as searching records or saving an output. Each tool describes the inputs it accepts and the result it returns.
Resources provide information an application can read, such as a document or a reference record.
Prompts provide reusable instruction templates for a particular interaction.
A server can offer a subset of these capabilities. The client application must also support the features you intend to use. A connection to one service does not make every capability of that service available in every AI application.
For example, a project service might offer a tool that reads a brief and another that saves a report. A connection permitted to read the brief may have no authority to save anything. The tool catalog describes the interface; the service's access controls determine which requests a particular participant can carry out.
How do the host, client and server fit together?
There are three roles in the MCP architecture. The host is the AI application a person uses. A client inside that application handles communication with an MCP server. The server exposes capabilities on behalf of a service or data source.
An editor, for example, can host an agent with connections to more than one server. One connection might expose permitted project records. Another might provide a separate documentation search service. The host manages how these connections participate in the session.
A server is software, so it does not necessarily mean a separate physical machine. Local servers can run as processes communicating through standard input and output. Remote servers can be reached over HTTP using a supported transport such as Streamable HTTP. Follow the publisher's current connection instructions and check what your host supports.
The model helps select an appropriate action. The host, client and server carry out the surrounding software interaction. How much information reaches the model, which actions require approval and what remains available after a session depend on those implementations.
What happens when an agent calls a tool?
Consider a request to inspect a project's accepted requirements before preparing an implementation plan. A typical interaction proceeds through a few observable steps:
The application discovers the server's available tools and their input requirements.
The agent selects a relevant tool and supplies the necessary arguments.
The host applies its configured controls, including an approval step when required.
The server checks the request and applicable access before carrying out the operation.
The application receives a result that the agent can inspect and use in its response.
For a read, the result could contain a requirement and its source reference. For a write, it could identify a newly saved report. The user should be able to distinguish what was requested from what the tool actually confirmed.
This distinction matters when something fails. An access error is a reason to inspect the grant. An uncertain response to a write requires checking whether the action already happened before retrying. A plausible sentence from the agent is not evidence that the external system accepted the request.
How does MCP relate to APIs, RAG and memory?
These terms describe different parts of an AI application. Understanding the boundaries makes it easier to choose what you need.
APIs connect software operations
An API defines how software can interact with a service. An MCP server can use an existing API behind its tools, translating a request into the operations that service supports.
If you are building a conventional application with a known sequence of operations, direct API integration may be appropriate. If an AI host needs a discoverable interface to supported tools, MCP can provide that interface. A product can support both without requiring users to adopt the same client application.
RAG brings retrieved information into an answer
Retrieval augmented generation selects external information to include when a model produces an answer. An MCP tool can expose a search or retrieval service that participates in this process. The protocol carries requests and results; the retrieval system determines which evidence to return.
Our guide to RAG and AI memory explains source selection, context limits and the maintenance of useful project records in more detail.
Memory retains useful records beyond the current exchange
MCP does not define a universal store of everything an agent knows. A connected service can retain records that later authorized sessions can retrieve. The service must provide that persistence, and the application must select the information relevant to the work.
Connecting an application also does not automatically copy its private conversations into another system. For shared work, decide what should be saved, where it belongs and who should be able to read it later.
Agent execution determines whether work continues
An agent needs an active host or another configured execution route to perform actions. A working connection gives it access to supported operations while that environment is available. It does not, by itself, provide continuous execution after the host closes.
Our practical guide to agentic AI covers goals, action loops, review and the distinction between a saved task and an execution attempt.
How should I connect an AI application?
Begin with a specific need: read a project brief, inspect a source or save a reviewed output. Identify the service that owns that information and use its official connection instructions.
Check the publisher, the endpoint or launch command, the host's compatibility and any account requirements. Review the requested access before approving the connection. A local server may execute code on the machine where it runs, so its installation deserves the same care as other software.
Then perform a small check that does not change saved state. Ask the agent to retrieve a record you know it may access. Inspect the actual tool result and compare it with the answer.
Microsoft's VS Code guidance includes a useful verification principle: check that the intended server's tool was called, that the requested information was returned successfully, and that the answer reflects that output. Adding a configuration alone does not establish a working connection.
For Swarm, use the current connection guide. Reuse an approved connection already available in the host. A new chat should not require a second credential flow simply because the conversation is new, provided the host preserves and renews the existing connection appropriately.
Another host may require its own setup and approval. Do not assume that connecting an editor grants access to an unrelated application.
Example: carrying an investigation between tools
The following workflow is illustrative, not a customer case study or a record of an executed Run. It describes a software team investigating an export issue in its own reporting application, using Swarm to retain the shared work.
Save the brief and useful evidence
The team creates a Space for the reporting project. An engineer saves a synthetic example showing that an export changes accented names, the expected behavior and the relevant test results. The brief identifies what needs investigation and who will review the proposed correction.
Sensitive customer records do not need to accompany a reproducible example. The team can deliberately select the evidence appropriate for the Space and its participants.
Investigate through the first authorized client
An analyst uses a compatible AI application with access to the Space. The agent reads the saved evidence and the relevant discussion, then prepares an Artifact describing the observed behavior, competing explanations and missing checks.
The agent saves a checkpoint with the remaining questions and links to the evidence it used. A proposed cause remains a hypothesis until the appropriate checks support it.
Continue in an editor
A developer works in an editor whose agent has its own approved access to the same Space. The agent can retrieve the saved investigation and understand what has already been checked.
Access to the local codebase is a separate permission supplied by the developer's environment. Swarm's project connection does not automatically grant file system access or install a connection to the team's repository provider.
The developer can ask the agent to examine the permitted code, propose a correction and run the authorized tests. The result can be saved back to the Space with a description of the change, test evidence and remaining uncertainty.
Keep execution and review distinct
Swarm distinguishes a Task, which is a saved brief, from a Run, which records an execution attempt. When the team uses those work operations, the attempt and its outputs can be inspected alongside the project discussion.
Execution approval and result review are separate decisions. Permission to investigate an issue does not establish that a proposed correction should be merged or deployed. Those actions remain subject to the team's actual tools and controls.
Leave an inspectable record for the next participant
A reviewer can examine the original example, the investigation, the proposed correction and the test evidence. The accepted conclusion can be recorded with the reasons it was accepted.
A later authorized participant can retrieve that record through another compatible connection. The useful continuity comes from the saved evidence and decisions. Each agent still needs to read the relevant material and assess whether it applies to its current task.
What access should a company grant?
Start with the information and actions required for the responsibility. Someone preparing a review brief may need to read project evidence and save a proposal. They may have no reason to change account settings, modify production records or access unrelated Spaces.
For a protected remote server, the MCP authorization specification describes how an application can obtain access on a resource owner's behalf. Implementations and supported authentication methods vary. Check the service's actual authorization flow and the host's support for it.
The IETF's OAuth security best practice recommends restricting access token privileges to the resources and actions needed for the use case. A successful sign in does not mean an application should be allowed every operation an account could perform.
In Swarm, inspect the Spaces and capabilities granted to the connection. Permission to access one Space does not imply permission to access another. A source link also cannot grant access that the recipient does not have.
Credentials belong in the host's supported secure configuration, not in a prompt, a shared document or committed project files. When reviewing setup instructions, verify where the connection is stored and how it can be revoked.
Treat returned documents and messages as information to evaluate. Text inside a source cannot grant a new permission or authorize an unrelated action. The MCP security guidance documents risks that remain the responsibility of client and server implementations, including unsafe handling of tokens and local server execution.
For consequential writes, decide who may initiate them, which approvals are enforced and what evidence confirms completion. A clear prompt helps communicate intent. The application and service must enforce the actual boundary.
Why is an MCP connection not working?
Check the interaction in stages so you can identify the problem without widening access unnecessarily.
Configuration: Confirm that the endpoint or launch command matches the publisher's current instructions. A website address may be different from its MCP endpoint.
Availability: For a local server, check that the required process can start in the host's environment. For a remote server, check whether the service is reachable.
Authentication: Inspect whether sign in completed or the connection needs renewal. Keep credentials out of shared logs.
Capability support: Check that the host supports the feature you are trying to use and has made the relevant tool available in this session.
Authorization: Confirm that this connection can access the specific Space, record and operation. An unavailable tool and a denied operation are different problems.
Outcome: Inspect the tool's returned result. A connected status or a confident answer alone does not confirm that the requested action succeeded.
Begin with a permitted read before testing a write. If the read fails, diagnose that failure before asking the agent to create sample work or request broader permissions.
Common questions about MCP servers
Do I need to build my own MCP server to use Swarm?
No. Start with Swarm's supported connection methods and a compatible host. Developers building an application can also use the API directly. A custom server is an implementation choice for a particular integration, not a prerequisite for using a Space.
Does an MCP server need its own AI model?
The protocol does not require every server to run a model. A server can expose ordinary software operations or information. Some services may use AI internally, but that is a separate implementation decision.
Will every MCP client show the same tools?
No. The available catalog can depend on the server, account, granted scope and host support. Check the tools offered to the particular session. Shared protocol support does not establish identical permissions or user interfaces.
Will connecting Swarm keep an agent working after I close its chat?
An MCP connection alone does not keep a closed chat running. Continued work needs an active supported host or a separately configured execution route. Where native event subscriptions are supported, listening also requires successful setup in both the host and the service. A saved connection is not proof that an agent can be awakened.
Start with one useful connection
Choose a project record that an agent needs to read and an output that another participant will need later. Connect with the appropriate access, verify a small read, then review an explicitly authorized saved contribution.
Swarm provides a shared place for that evidence, discussion and continuing work. Start with a Space and follow the connection guide for your host. The first useful result is a handoff that the next person or agent can actually inspect and continue.