MCP adoption guide
The Model Context Protocol (MCP) is a standard for connecting AI applications to external data and tools. Before using a connection button, review which host uses which server resources and tools with which permissions.
Do not install an MCP server as though it were a harmless plugin. Record the server source and pinned release, host and transport, data and tool scope, identity boundary, user approval, accountable owner, and revocation condition; then validate one narrow pilot before expanding access.
This page does not certify a particular MCP server or host as secure or compliant, and it does not replace an organization's security, legal, or procurement review. It is a public-information checklist of questions to resolve before a connection.
Understand MCP in one minute
MCP distinguishes hosts, clients, and servers, and servers may provide prompts, resources, and tools. A tool is a model-callable capability, which makes it a permission decision rather than a catalogue checkbox.
A host application starts the connection, while a client communicates with the server inside that host. The same server can have different approval UI, storage, and permission boundaries in different hosts.
Record the actual host, client, user, and server—not only the server name.
Resources are contextual data made available to the model, while prompts are user-chosen templates. Even read-only access needs a defined data classification and scope.
Do not group shared data, customer data, and secrets into one generic access label.
Tools are functions the model can invoke. A lookup, file write, ticket creation, or external send can change the real world and needs separate review.
Name each allowed action and the human approval point separately.
Start with a blank record
Use this blank worksheet before a pilot. You never need to enter a real server address, credential, or customer data into this site.
The blank CSV includes columns for the server source and release, host, transport, data and tool scope, approval gate, owner, and revocation condition. AgentHub does not store or transmit your integration details.
Six checks before installation
These turn the specification's consent, data protection, tool safety, HTTP, and authorization requirements into an adoption conversation. If one item is unknown, do not widen access yet.
Confirm who publishes and maintains the server, which repository and release it is, and which host will install it. A lookalike server or missing maintainer is a supply-chain risk.
Record the publisher, repository, pinned release, and accountable owner.
MCP defines stdio and Streamable HTTP as standard transports. HTTP connections need Origin validation, localhost binding for local servers, and appropriate authentication.
Keep the test and production environments and their network exposure separate.
Do not collapse resource reads and tool actions into one generic access decision. Distinguish read, write, external send, and irreversible actions.
State the minimum permission per tool and actions that remain prohibited.
For HTTP-based authorization, a server must validate that a token is issued for its intended audience and must not pass a received token through to another service.
Name who stores, renews, and revokes each credential.
The MCP specification requires explicit user consent and control before data exposure and tool invocation. High-impact or paid actions should not depend only on the model's judgment.
Decide which tools need approval and who can approve them before the pilot.
A connection is not a permanent trust decision. Owner changes, expanded permissions, supplier changes, inactivity, or suspicious behavior should reopen review.
Write one clear next-review and revoke-or-rollback condition.
Avoid one approval process for every tool
Risk depends on the combination of host and server. Do not expand permissions because a server has a general reputation for being safe.
The connection retrieves public documents or approved internal knowledge without changing an external system. Data classification and user consent still matter.
Start with a narrow dataset, least privilege, and named owner.
Tools can change internal files, tickets, calendars, or databases. A mistaken call can still create operational cost and cleanup work.
Use a sandbox, draft state, or approval step by default.
The tool can send to a customer or partner system, charge money, delete data, or deploy. The impact and recovery burden are larger.
Do not automate without explicit human approval, separate identity, and a narrow pilot.
A small, observable first pilot
The goal is not to connect the most tools. It is to learn what inputs, permissions, outputs, and approvals a single job actually needs.
Define one representative lookup or drafting job, its success measure, and actions it must not take.
Start with a pilot identity, narrow data boundary, and read-only or sandbox tools.
Inspect proposed and invoked tools, and record which actions a person approved or declined.
Review outcome quality, permission scope, cost, failures, and ownership before expanding access or removing the connection.
Official evidence
The MCP specifications below explain the host-client-server structure, user consent, tool safety, HTTP transport, authorization, and token validation. AgentHub editorially synthesizes those requirements into questions buyers and adopters can inspect before connecting a tool.
Source check: 2026-09-05. Reconfirm current documentation for the actual host and server implementation.
Frequently asked questions
MCP is a connection protocol. It does not automatically guarantee a server's quality, safety, or required permission scope.
The buying decision after a connection review
After reviewing an MCP connection, connect it to the actual host and tool information, agent inventory, and change history before expanding rollout scope.
