Connecting Business Tools with MCP

Tomohiro Iida · Published June 30, 2026 · Updated June 30, 2026

This article lays out implementation patterns for connecting internal tools and running automation safely with MCP (Model Context Protocol) and careful tool design. Drawing on what Netsujo has learned running MCP in its own operations, it is organized for engineers moving from considering adoption through early implementation.

The first wall you hit, moving an AI agent from trying it out to using it daily for real work, is connecting to outside systems. Being a good conversational partner is not enough on its own: pulling a GA4 report, rewriting an article in Strapi, generating a document in Google Docs, an agent cannot do that work alone. MCP is one standardized way to close that gap (direct function calling or a custom API integration can also get you there). This article covers, from an implementation standpoint, what MCP solves, how to design tools, how to scope permissions and sandboxing, where teams tend to trip up, and how to roll it out in stages.

What MCP solves

MCP is a common protocol for connecting AI agents to outside tools and data sources. It lets an agent carry out an operation, such as fetching last week’s session count from GA4 or reading meeting notes in Notion, as a standardized tool call.

Without MCP, every new integration means writing custom glue code, embedding how to use each tool into the agent’s prompt, and re-implementing the result parsing each time. The more integrations pile up, the more this implementation scatters, until maintenance breaks down. MCP separates a tool’s definition, its name, input schema, and description, from its execution on the server side, so the agent sees a standardized catalog. In practice, swapping a connection or adding a tool becomes a matter of server configuration rather than a prompt rewrite.

Netsujo runs Claude Code as its execution layer alongside several MCP servers at once, including Google Search Console, GA4, Google Workspace, Notion, the design tool Pencil, cross-session Memory, and Chrome DevTools for measuring the live site. As one example, our weekly GA4 report chains a single sequence of tool calls, from pulling the data through generating a Google Doc to posting a notification, an internal example.

MCP is not, though, a universal adapter. Whatever an integration’s API does not support, MCP cannot make possible either. MCP is the layer that makes what an API can already do easier for an agent to use; it does not extend the API’s own limits.

Three principles of tool design

The quality of the tools an MCP server exposes directly decides how stable the agent’s behavior is. Three principles improve both how easily a failure can be traced and how repeatable execution is.

Cut each tool to a single verb

Scope each tool to a single verb. Map it to one clear operation, such as updating a blog post, rather than a multi-purpose tool that manages content in general. One tool, one responsibility keeps the input schema simple and makes it easier to isolate the cause when something fails.

Make the schema and description the agent’s primary reference

Write the input schema and description as the agent’s primary reference material. The agent decides how to use a tool by reading its description and each argument’s explanation. The more precisely the schema encodes which arguments are required versus optional, the allowed values, units, and upper bounds, the more stable execution becomes.

Structure the return value, and never swallow a failure

Structure return values, and never swallow a failure. Return a machine-readable structure on success, and return the error type and cause as text on failure.

For example, a tool such as fetch_ga4_report might declare required arguments for a property ID, a start date, and an end date in YYYY-MM-DD format capped at a 90-day range, plus an enum of allowed metrics. The more upper bounds and accepted values are spelled out in the description, the more reliably the agent calls the tool.

Permissions and sandboxing

The principle is least privilege, combined with separating reads from writes. Scope the credentials handed to an MCP server tightly: read-only for GA4, limited to the relevant site for Search Console, so the agent’s reach is physically bounded by the scope of the service account or token, not just by convention.

Separate out destructive operations. Data retrieval and drafting can be left to the agent, but irreversible actions, such as pushing to production, publishing, or transferring money, should go through human approval. Deciding upfront that reads are automatic and writes need staged approval heads off accidents later.

The following represents an internal policy in simplified form; fields such as access level and an approval requirement are not standard MCP configuration options, but illustrate how permissions might be scoped in practice: read-only access for Search Console, scoped to a single verified domain; read-only access for GA4, scoped to a single property; read-write access without approval for a Workspace documents connector; write access requiring approval for a CMS-publishing connector; and access denied outright for a payments connector.

Failure patterns worth knowing

Connecting things through MCP tends to trip teams up in the details of day-to-day operation rather than in the design itself. Here are the patterns worth knowing about in advance.

Token expiry and forgetting to reissue it

Time-limited credentials such as OAuth access tokens go quiet on you when they expire (API keys and service-account keys behave differently depending on the implementation). Centralize credentials in environment variables, and build in a mechanism for expiry and rotation.

Expecting a capability that does not exist

An agent will decide from the description that something looks doable and call it, but it fails if the underlying API has no such operation. Spell out what a tool cannot do in its description too.

A silent return value

Returning an empty result for a failure lets the agent treat it as a success and move on. Always return an error as an error.

Over-granting permissions

It is safer to start read-only and add write access only to the operations confirmed to actually be needed.

Ambiguity in the approval flow

Standardize so that irreversible operations only ever run on explicit instruction.

MCP versus a custom script

The deciding factor is whether the agent needs to call it dynamically, in the middle of a conversation. MCP suits operations the agent chooses among depending on the task’s context. A fixed batch job that always runs at the same time every week suits a scheduled script instead. Routine work that requires no judgment runs faster, cheaper, and more reliably without going through an agent.

A staged rollout roadmap

Rather than trying to automate everything at once, expanding in stages while keeping clear what scope is still held by a human lets automation scale without losing control.

Stage 1: a single read-only integration

Connect one data source that involves no writing through MCP, and have it produce aggregates or draft generation.

Stage 2: staged approval for writes

Let the agent handle draft generation, with a human approval step before anything reaches production.

Stage 3: shared use across multiple agents, with audit

Build in a record of who ran what, and a third-party check on the output.

Keeping clear, at each stage, what scope stays in human hands lets automation expand while remaining under control.

Frequently asked questions

Do we need to adopt MCP?

If there are only one or two integrations and a fixed batch job covers them, there is no need to force it. MCP pays off where an agent needs to call among several outside tools dynamically, in the middle of a conversation.

Is it safe to let an agent touch production?

Reads can be handed over fairly safely. For irreversible actions, such as pushing to production, publishing, or transferring money, we would recommend routing them through human approval.

We are worried about sending internal, non-public information to an outside AI.

Blocking outbound transmission by default, and allowing only approved destinations and data types as exceptions, is an effective design. Implementing an allowlist of destinations and field-level masking on the MCP server side, keeping highly sensitive information entirely in-house, and passing an outside AI only summaries or non-sensitive metadata makes it easier to balance convenience with protecting information.

Can our own in-house tools be turned into MCP too?

Yes. If an internal API already exists, wrapping it in an MCP server lets an agent call the existing tool. Even without a ready API, if the code or the runtime is accessible, the needed operations can be carved out as functions with defined input and output types and permission scope. Publishing read operations first and gating updates behind approval allows expansion while keeping risk down.

How much benefit can we expect from adopting this?

A figure such as a reduction rate depends heavily on the environment and the work involved, so a generalized, firm number is best avoided. We would recommend starting with a small, read-only integration, measuring the effect, and expanding from there.

Summary

MCP (Model Context Protocol) is a common protocol connecting AI agents to outside tools and data sources. Separating a tool’s definition from its execution on the server side means adding or swapping an integration is a matter of server configuration, not a prompt rewrite.

Tool design comes down to three principles: cut each tool to a single verb, make the schema and description the agent’s primary reference, and structure return values so failures are never swallowed. Permissions follow least privilege with reads and writes kept separate, and irreversible operations go through human approval.

The trouble tends to show up in operational details rather than design. Watch for token expiry, expecting a capability that does not exist, a silent return value, over-granting permissions, and ambiguity in the approval flow. A realistic rollout starts with a single read-only integration, then moves to staged approval, then to shared use across multiple agents with audit.