Connect AI to website tools with MCP: understand what you are authorising

Map the participants

The MCP architecture overview distinguishes a host application, its MCP clients and servers providing context or capabilities. A server can run locally or remotely. Where it runs affects the connection, but does not alone establish who operates it or what it can access.

Write the actual names and responsibilities for your proposed connection. The host presents the conversation and tool experience. The server exposes operations. A website account or downstream service supplies the authority to read or change data.

Do not confuse this remote or local service connection with a browser page exposing structured actions through an evolving web API. The useful review here follows the service account and server boundary, not only the visible page state.

A fictional editorial assistant

Imagine a fictional publisher wanting AI to find outdated internal links and prepare draft corrections. The proposed assistant needs published article URLs and permission to create an isolated draft proposal. It does not need permission to publish, delete articles, change users or alter billing.

The owner records a narrow tool set: list approved public articles, inspect one article and prepare a draft change. The connected account is limited accordingly where the website supports it. Publication remains a separate reviewed action in the ordinary publishing process.

In a safe test, the owner would verify a normal public read, a permitted draft operation and denial of publication. A polished description saying publication is disabled is not enough; the attempted unauthorized path must actually be denied. This is a fictional review design, not a tested integration.

Review authorization at each hop

The current MCP authorization specification distinguishes transport cases and describes least-privilege scopes for supported protected connections. Authorization support is optional in the protocol. Ask how this particular integration authenticates and authorizes access rather than assuming every MCP server provides the same protection.

Confirm the account, organization, website and environment on the authorization screen. Review requested scopes against the task. If a connector asks for capabilities outside the proposed job, investigate whether a narrower account or configuration is available before continuing.

Keep credentials out of conversation text, URLs and public configuration. Use the supported credential-handling route. A connection can involve downstream services as well as the MCP server, so the owner should understand which operator receives access and which identity is used there.

Put approval beside the consequential action

The MCP tools specification recommends a human-in-the-loop experience with visible exposed tools, invocation indicators and confirmation. The protocol does not mandate one universal client interface, so inspect the actual application’s behavior.

For a draft update, show the target article and proposed fields. For a message, show recipient and content. For publication, show the exact content and destination. A general approval to connect an account should not silently become permission for every later write.

Use the human-approval workflow to define rejection, expiry and changed proposals. If the tool arguments change after approval, review the changed action again through the supported flow.

Treat returned content as untrusted input

A retrieved page, support ticket or document can contain instructions telling an assistant to ignore its rules or invoke another tool. That text is content from the source, not authorization from the owner. Keep task instructions and source material distinguishable.

Review tool descriptions and outputs for unnecessary secrets or private fields. An article inspection should not return the whole user database because the server can access it. Minimize what the model receives as well as what the account can do.

A tool’s label, annotation or schema can help the client understand its purpose. It does not replace validation of parameters, user permissions and the resulting operation by the responsible implementation.

Test denial, failures and retries

Use development or sandbox data for writes. Check an allowed task, missing input, invalid identifier, expired authorization, service failure and a denied operation. Confirm that the client reports the real outcome rather than describing a failed call as completed.

For operations that create records, test a retry after a partial failure and inspect for duplicates. Keep enough private audit evidence to identify the target and outcome without recording credentials. Our log guide explains focused incident records and redaction.

Ask what a denied call looks like to both the application and the operator. The result should state that the action was not performed, and any audit trail should identify the attempted target without revealing credentials. A tool disappearing from a menu is helpful presentation, but server-side denial still matters when a call reaches the service directly.

Plan disconnection before enabling access

Identify how to revoke the integration, remove the downstream grant and disable the connected account if necessary. Test the supported revocation path and observe when access actually stops. Do not promise instant revocation without evidence from the selected system.

Retain an owner, permitted tool list, account scope, review boundary and recovery route. Your next step is that connection map and a small denial test in the intended environment. A useful MCP integration makes a defined task easier while keeping its authority explainable.