Internal agents only work if they can safely touch the systems your company already runs: chat, docs, tickets, warehouses, and private APIs. MCP is the standard way to expose those systems as tools, resources, and prompts to AI hosts (What is MCP?, server concepts).
This page is a use-case playbook: architecture choices, security grounded in the official MCP docs, and a rollout checklist. Product hosting (e.g. MCPLambda) is optional infrastructure at the end.
Why MCP fits internal tools
Official intro examples include agents accessing calendars and docs, enterprise chatbots across databases, and “build once, use in many clients” ecosystem support (intro). That maps cleanly to internal work:
| Internal system | Natural MCP surface | Risk if mishandled |
|---|---|---|
| Slack / Teams | Post, search, read channels | Spam, confidential leak |
| Notion / wiki | Search, create pages | Confidential IP |
| Databases | Read queries, limited writes | Injection, PII, outages |
| Ticketing | Create/update issues | Noisy automation |
| Internal HTTP APIs | Domain actions | Privilege escalation |
Primitives reminder (server concepts):
- Tools — model may call (actions)
- Resources — app-controlled context (schemas, runbooks, policy docs)
- Prompts — user-selected playbooks (“triage this alert”)
Reference architecture (team-scale)
[ Host: Claude / Cursor / internal agent ]
│ Streamable HTTP (remote) or stdio (laptop only)
▼
[ MCP server(s) you own or install ]
│ least-privilege credentials
▼
[ Slack / Notion / DB / internal API ]From the architecture overview:
- Local stdio servers typically serve one client process
- Remote Streamable HTTP servers typically serve many clients
Recommendation for internal teams: one shared remote deployment per domain (e.g. wiki-mcp, db-readonly-mcp) rather than every engineer’s private stdio copy. See team-shared remote MCP and official connect remote servers.
Split servers by domain
Prefer several small servers over one mega-server:
- Easier ownership and blast-radius limits
- Matches client best practices: when tools scale into the hundreds, hosts should use progressive discovery (don’t dump every tool definition into context)
- You can disable write servers without killing read tools
Security checklist (official MCP)
Map these to every internal server before production:
| Control | Source |
|---|---|
Authenticate Streamable HTTP connections; validate Origin | Transports 2025-11-25 |
| OAuth / proper HTTP auth for remote access | Authorization |
| No token passthrough to upstream APIs | Security Best Practices |
| Validate tool inputs; access control; rate limit; sanitize outputs | Tools security |
| Human can deny sensitive tool calls | Tools interaction model |
| Least-privilege scopes | Scope minimization |
| Don’t treat session IDs as authentication | Session hijacking |
Credential patterns that work in orgs
- Per-environment secrets (dev/staging/prod)
- Read-only DB credentials for analytics agents
- Separate write tools behind stricter approval or a separate server
- Never share long-lived admin PATs in Slack
Build vs catalog vs gateway
| Need | Approach | Why |
|---|---|---|
| Commodity SaaS (Gmail, Slack SaaS OAuth) | Catalog / integration gateway | Managed OAuth and connectors (catalog vs BYO, gateway vs host) |
| Proprietary DB / internal API | BYO MCP server you deploy | You own schema, policy, and SLAs |
| Discovery of public servers | Official MCP Registry (preview) + aggregators | Metadata only — not a private app store for internal code |
Official registry does not support private-only servers (registry about) — keep internal servers on your host or private registry.
Tool design for internal agents
Grounded in the tools specification:
- Clear
name+description(models select from metadata) - Tight
inputSchema(JSON Schema) - Prefer many small tools over
do_anything - Return actionable errors with
isError: trueso models can self-correct - Put large reference docs in resources, not multi‑MB tool payloads
When tool counts explode, hosts should adopt progressive discovery (client best practices).
Rollout plan (30 days)
| Week | Action |
|---|---|
| 1 | Pick one domain (e.g. wiki search only). Deploy remote. Auth on. |
| 2 | Pilot with 5 users; audit tool logs; tighten schemas |
| 3 | Add read-only DB or ticketing; document onboarding URL + how to get a token |
| 4 | Split write tools; define owner/on-call; decommission personal stdio forks |
Hosting on MCPLambda (product)
When you want Git/Docker/package → shared URL without running Kubernetes yourself:
That is platform product, not MCP protocol.
Worked scenario: Wiki first, write tools later
You enable an internal agent with Notion write + prod DB write on day one. Someone bulk-updates pages incorrectly; finance panics.
You relaunch with read-only wiki search and a staged DB replica. Write tools arrive later on a separate server with stricter auth and human approval. Secrets live in the platform; no PATs in Slack. Progressive discovery matters once tool count grows across Slack/Notion/Jira/DB.
Thirty days later, onboarding is a remote URL + token request form—not a scavenger hunt.
Checklist for this topic
- Start read-only for each domain
- Split servers by system (wiki vs db vs chat)
- Remote shared endpoint for team tools
- Gateway for commodity SaaS OAuth if needed; BYO for private DB
- Audit tool calls; least-privilege upstream creds
- Named owner per server
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Accidental mass writes | Write tools too early | Read-only first |
| God token in Slack | Secret distribution | Platform secrets + issued auth |
| One mega-server | Blast radius | Domain-split servers |
| Catalog-only, no private DB | Missing BYO | Host custom DB MCP |
Related guides
Team-shared remote · Gateway vs host · Securing remote
Sources
- What is MCP?
- Architecture overview
- Understanding MCP servers
- Tools — 2025-11-25
- Transports — 2025-11-25
- Security Best Practices
- Client best practices
- Connect to remote MCP servers
- MCP Registry
