MCP Is Where Agent Tooling Starts to Look Real

An agent with one hardcoded function is easy.

An agent connected to ten company systems is not.

That is where MCP becomes interesting. Not as a buzzword. As a boundary.

The agent should not directly know the messy details of every internal API, repo, file system, docs store, and admin tool. It should talk to a tool layer with explicit capabilities, permissions, and audit behavior.

That is the role MCP can play.

Do not model MCP as "tools"#

The lazy design is:

Agent has MCP.

That tells you nothing.

A useful design says:

• Which MCP servers exist?
• What transport do they use?
• What tools do they expose?
• What resources do they expose?
• What prompts do they expose?
• What auth mode do they require?
• Which calls require approval?
• What gets logged?

That is the difference between an architecture and a sticker on a diagram.

Tools vs resources#

This distinction matters.

Tools do work:

• github.search_code
• browser.click
• linear.create_issue
• tests.run
• stripe.refund.preview

Resources provide context:

• Runbooks
• Repo roots
• OpenAPI specs
• Customer support policies
• Database schemas
• Incident timelines
• Trace summaries

Most early agent workflows should use more resources than tools. Reading context is safer than taking action.

Prompts are part of the system too#

MCP prompts can hold reusable operating instructions:

• Incident summary prompt.
• PR review rubric.
• Support answer template.
• Escalation policy.
• Browser verification checklist.

This keeps the main agent prompt smaller and makes skills reusable.

The approval boundary#

MCP does not magically make the workflow safe.

You still need explicit approval rules:

• Reads are allowed by default only inside user scope.
• Writes require approval unless the action is low-risk.
• High-risk tools need a summary before execution.
• Every tool call gets an audit record.
• Sensitive outputs get redacted before the model sees them.

If you skip this, MCP just becomes a cleaner way to do dangerous things.

A practical server layout#

For a startup internal agent, I would start with:

• docs-mcp: resources for Notion, runbooks, ADRs.
• repo-mcp: GitHub search, PR reads, CI status.
• ops-mcp: observability read APIs and deploy events.
• browser-mcp: screenshot, DOM snapshot, scoped actions.
• ticket-mcp: Linear or Jira reads and approved writes.

Each server has a risk level and owner. That sounds formal, but it is how the team knows what the agent can touch.

Build it in Codelit#

Try this:

Design an MCP-backed agent workflow for internal operations. Include separate MCP servers for docs, repos, observability, browser automation, and tickets. Show tools, resources, auth, risk, approval policy, and deploy architecture.

Design this MCP agent workflow

MCP is not the product. The workflow around it is.