Using MCP Servers with AI Assistants

Map the protocol roles

An MCP host is the AI application that coordinates user interaction, model requests, permissions, and one or more server connections. Within the host, a client maintains a session with a particular server. The server advertises capabilities such as tools that perform operations, resources that provide context, and prompts that offer reusable interaction templates. Exact supported features depend on the current implementation.

This separation helps integrations share a common protocol, but it does not make every server trustworthy or every capability appropriate. A local file server, a company issue tracker, and a remote third-party service have different operators and authority. Draw the path from user request through host and client to the underlying system, including where credentials and returned content cross boundaries.

Evaluate a server before connecting

Confirm who publishes and maintains the server, how it is distributed, what code or endpoint will run, and how updates are controlled. Inspect the capabilities it exposes rather than approving from its name. A server described as project search might also offer file writes or command execution. Prefer an allowlisted version and a review process for capability changes.

Identify authentication, credential storage, network destinations, data retention, and logging. Give the server a dedicated identity with the narrowest useful scope. Separate environments and tenants. If a remote server receives prompts, resource identifiers, or tool arguments, document that disclosure. Do not place secrets in model-visible instructions or rely on the server description to prevent unauthorized access.

Control capability use in the host

Capability metadata helps the model choose an operation, but the host remains responsible for policy. Filter tools and resources by the signed-in user, current task, and approved server. Validate arguments before invocation. Require a concrete preview and human confirmation for external messages, record changes, command execution, purchases, deletion, or other consequential effects.

Treat server responses and resource content as untrusted data. A retrieved issue or document may contain text telling the assistant to reveal credentials or call another tool. It cannot alter system rules. Label content with its origin, limit how much enters context, and prevent one server's result from silently authorizing a capability on another server. Results should report actual success, failure, or uncertainty.

Operate the connection deliberately

Test startup, capability discovery, normal calls, invalid arguments, permission denial, timeouts, disconnects, and server upgrades. Record server identity, capability version, invocation, approval, and outcome without collecting unnecessary sensitive content. Set call, retry, and duration limits so one failing integration cannot trap an assistant in a loop or create repeated side effects.

Provide a way to disable a server, revoke its credentials, and remove cached capability information. Recheck trust after ownership or version changes. Monitor unexpected capability additions, denied operations, cross-tenant attempts, and repeated failures. The protocol and implementations evolve, so verify transport, authorization, and capability details in current official MCP documentation during each quarterly review.

Connect an assistant to an issue tracker

An engineering team wants an assistant to find assigned issues and prepare updates through an approved MCP server.

1. Review the server publisher, pinned version, network path, credential handling, and advertised search, read, comment, and edit capabilities.
2. Give it a dedicated identity limited to one project, expose search and read by default, and hide administrative operations from the assistant.
3. Treat issue descriptions as untrusted, retrieve only requested fields, and keep any proposed comment separate from source content.
4. Preview the exact issue and comment for the engineer, then invoke the comment tool only after approval and record its returned identifier.
5. Test revoked access, renamed capabilities, malicious issue text, duplicate submission, and emergency server disablement before wider rollout.

MCP connection review record

Complete this record for each server and revisit it whenever capabilities or ownership change.

• Identity: publisher, maintainer, version, distribution path, endpoint, and update process.
• Authority: credentials, tenant, systems, data fields, network destinations, and side effects.
• Capabilities: approved tools, resources, prompts, argument limits, and hidden operations.
• Controls: user checks, content boundary, previews, approvals, budgets, and audit fields.
• Lifecycle: tests, monitoring, upgrade review, credential rotation, disablement, and removal.

Common mistakes

• Assuming protocol compatibility means a server is trustworthy, maintained, or appropriate for sensitive work.
• Approving a server by its friendly label without reviewing every exposed capability and underlying permission.
• Letting retrieved resource text authorize tool calls or change controls established by the assistant host.

Try one

Sources

• Model Context Protocol documentationOfficial MCP documentation and current entry point for protocol concepts and implementations.
• MCP architecture overviewOfficial description of MCP hosts, clients, servers, and protocol layers.