MCP Server Development and Secure Claude Integrations
MCP server development means building a Model Context Protocol server: a small service that gives Claude, in chat, Claude Cowork, Claude Code or an API agent, a defined set of tools to read or act on one of your business systems. NetSys scopes each connector to named tools, puts authentication and least privilege in front of it, reviews it before an admin enables it for staff, and hosts and monitors it under a managed agreement.
The short answer
An MCP server is the piece of software that connects Claude to a system Anthropic does not already ship a connector for: a line-of-business database, a ticketing or practice system, an ERP, an internal API. Developing one means defining each tool Claude may call, with its inputs, outputs and whether it reads or writes; deciding how Claude authenticates to the server and how the server authenticates to the system; validating inputs, logging every call and testing against injected instructions; and reviewing all of it with the security owner before an admin enables it in the Claude workspace, in Claude Code or in an agent. NetSys builds and hosts the server, reviews it, and maintains it month to month. Where Anthropic already ships a connector, such as Microsoft 365, Google Drive, Slack or GitHub, we configure that instead of building.
Closest related page: AI agents for business. That page covers agents that take a job whole, with a charter and approvals; this page covers the connector itself: an MCP server that gives Claude a scoped, authenticated set of tools on one system, whether an agent or a person is on the other end.
Companies running Claude Team or Enterprise, or building on the Claude API, that want Claude to read or act on a system Anthropic does not ship a connector for: a line-of-business database, a ticketing or practice management system, an ERP, an internal API, a document store with its own permissions. Developers using Claude Code who want a shared, approved server instead of each person wiring their own also land here.
MCP is an open protocol that Claude uses for connectors across its products, so one well-built server can serve chat, Cowork, Claude Code and API agents. That reach is the reason the server needs a boundary. Anthropic reviews connectors before listing them in its directory but does not security-audit or manage any MCP server; the company that enables one owns that review. Our post on what the Model Context Protocol is covers the basics; this page covers the build.
Scope the tools, then the credentials, then the review
Discovery names the system, the questions Claude should answer from it and the actions, if any, it may take. Each becomes a tool with a defined input, output and permission: read tools first, write tools only where a person will approve the result. We then decide how the server authenticates to the system and how Claude authenticates to the server: OAuth with per-user identity where the system supports it, a vaulted credential for API agents, and never a shared fixed secret where one leak would expose everyone's access. The server is built with input validation, logging per call and rate limits, tested against bad inputs and injected instructions, and reviewed with your security owner before an admin enables it in the Claude workspace, in Claude Code's managed server list or in an agent's configuration. Hosting, monitoring and changes run under a managed agreement.
What MCP server development includes
Native connector or custom server
Build only what Anthropic does not already ship.
- Anthropic's connectors for Microsoft 365, Google Drive, Gmail, Google Calendar, GitHub and Slack configured first, with their permissions reviewed
- A custom MCP server only for systems without a connector, or where the native one cannot express the permission you need
- Microsoft Graph connectors used instead where the goal is Copilot in Microsoft 365
- A written decision for each system: native, custom, or not connected at all
Tool scopes and authentication
Named tools, least privilege, no shared secrets.
- Each tool defined with its input, output and whether it reads, writes or deletes
- Read tools by default; write tools separated, named and limited to the records the workflow needs
- OAuth 2.0 for remote servers where the system supports it, so each person acts as themselves
- Credentials for API agents held in Anthropic's vault or your secret store, never in agent definitions or repository files
Validation, approvals, logging and tests
The server defends itself; it does not trust the prompt.
- Inputs validated and bounded on the server, since a model can be steered into calling a tool with bad arguments
- Content the server returns treated as data, with test cases for injected instructions inside records and documents
- Approval required before write tools run, in the Claude app, in Claude Code or through an agent's always-ask policy
- Every call logged with who, what, when and the result; rate limits and a kill switch on the server
Review before enabling
An admin enables nothing that has not been read.
- A review with your security owner: tools, scopes, hosting, credentials, logging and the test results
- Per-tool settings decided: interactive tool calls disabled where they are not needed on Team and Enterprise, per-tool permissions set on Enterprise, and whether Research use should be limited for write-capable tools
- Claude Code delivery through the organization's managed server list, so project files cannot introduce an unreviewed server
- The review record kept with the connector's entry in your AI tool register
Hosting and network
Reachable from Anthropic's cloud, and nowhere it should not be.
- Hosted in your Azure subscription or a private cloud, with Anthropic's published addresses allowlisted rather than the server opened to the internet
- HTTP transport for remote servers, since Anthropic marks SSE as deprecated; stdio only for local developer tools
- Servers behind a VPN or firewall cannot be reached by the Claude apps, so the hosting plan is settled before the build
- Secrets rotated on a schedule, and the server's own dependencies patched like any other system we manage
Monitoring and maintenance
Connectors break when the system behind them changes.
- Error and usage monitoring, with failed calls alerting a named owner and NetSys
- Changes when the business system's API, the Claude apps or the protocol change
- A quarterly review of tool scopes against actual use, retiring tools nobody calls
- Documentation and source code handed to you; maintained under a month-to-month managed agreement
Why companies build MCP servers with NetSys
Tell us which system you want Claude to reach, what it should be able to read or do there, and where Claude runs for you today: the Team or Enterprise apps, Claude Code or an API agent. A NetSys engineer will say whether a native connector covers it, and if not, what the server would need.
Who does the work: meet the NetSys team on our About page.
- Built by a cybersecurity firm, so scopes, credentials and logging are designed before the first tool
- Delivered work on Anthropic Claude: custom apps, dashboards and reporting roundups for a lean team, with access rules agreed before any source connected
- A published case study on custom Microsoft Graph connectors: permissions mapped per workflow and consented per connector
- One team for the server, the Claude workspace it plugs into and the systems it reads
- You own the code and the documentation; hosting and monitoring run month to month
- In business since 1998, from one office in Brooklyn
Native connector or custom MCP server?
The decision is recorded per system. Not connecting is a valid answer when the data is too sensitive or the system has no safe interface:
| Situation | Use | Why |
|---|---|---|
| Staff need Claude to search mail, files, calendar and Teams in Microsoft 365 | Anthropic's Microsoft 365 connector | Delegated permissions, read-only by default, enabled by an owner after an Entra Global Administrator consents; nothing to build |
| Claude should read Google Drive, Gmail, Slack or GitHub | Anthropic's native connectors | Already shipped; the work is reviewing permissions and deciding who may enable them |
| Claude should answer from a line-of-business database, ERP, ticketing or practice system | Custom MCP server | No native connector; the server exposes only the questions and records the workflow needs |
| Claude should take an action in a system, such as creating a ticket | Custom MCP server with a write tool behind approval | The write is a named tool with validation and a person approving the result |
| Developers want a shared, approved server in Claude Code | Custom or vendor MCP server delivered through managed settings | One reviewed server for everyone instead of per-developer configurations |
| The goal is Copilot in Microsoft 365, not Claude | Microsoft Graph connector | A different mechanism for a different product; our Graph connector service covers it |
Background: What is the Model Context Protocol (MCP)? · Claude Microsoft 365 connectors: permissions before rollout · Microsoft Graph connector development for Copilot.
Where an MCP server connects, and who approves it
As documented by Anthropic on October 17, 2026; sources at the end of this page:
| Surface | Who can add a server | How it authenticates | What to know |
|---|---|---|---|
| Claude chat and Cowork (Team) | Owners and Primary Owners only; members then connect individually | OAuth using Claude's published identity, automatic registration or your own OAuth client; or fixed headers stored encrypted | A fixed credential is shared by everyone who uses the connector, so OAuth is preferred |
| Claude chat and Cowork (Enterprise) | Owners, Primary Owners and custom roles with Manage access to Libraries | The same options, with org-wide approval and per-tool permissions | Owners can disable specific interactive tool calls; editing a connector means removing and re-adding it |
| Claude Code | Developers at local, project or user scope; the organization through managedMcpServers | OAuth 2.0 for remote servers, with tokens stored and refreshed by Claude Code | Project .mcp.json servers prompt in interactive sessions but load without asking in non-interactive and cloud sessions |
| Claude Desktop (local servers) | The user on the device, unless device policy disables it | Local process, stdio | MDM keys can disable local and extension MCP servers; local servers do not run in cloud sessions |
| Claude Managed Agents (API) | The developer, in the agent definition, up to 20 servers per agent | Credentials supplied at session creation from a vault, as a static bearer token or OAuth | The default permission policy is always ask; tools can be disabled individually; hosts must be allowlisted in a limited environment |
For every remote server, Claude connects from Anthropic's cloud rather than the user's device, so the server must be reachable from Anthropic's published addresses and nowhere else.
Security boundaries written into every connector
The same boundaries our AI agent charters use; the connector is where they are enforced in code:
- Least privilege at the system: the server's own credential can reach only the tables, records or endpoints its tools need.
- Read by default: write and delete are separate tools, named in the review and gated behind approval.
- Per-user identity where the system supports OAuth, so audit trails show the person, not a service account.
- No secrets in prompts, agent definitions or repository files; Anthropic documents that credential variables in .mcp.json expand as empty for this reason.
- Input validation and bounds on the server, because a steered model can call a tool with harmful arguments.
- Returned content treated as data: injected instructions inside a record must not change what the next tool does.
- Logging per call, rate limits, and a switch that disables the server without touching the Claude workspace.
- The data path documented: which product calls the server, where results are stored, and that connector traffic sits outside Anthropic's BAA.
Acceptance checks before an admin enables the server
The checks are written into the scope at the start, so acceptance is a test rather than an opinion:
- Every tool exercised with valid, invalid and out-of-range inputs, with the server rejecting what it should.
- Write tools confirmed to require approval in each surface they will be used from.
- Injected instructions placed in test records and documents, with the model's behavior and the server's logs reviewed.
- Credential scope checked at the system: the server cannot read outside its grant.
- Logs reviewed for completeness: who, which tool, which arguments, which result.
- Hosting checked: reachable from Anthropic's addresses, unreachable from the public internet, secrets outside the code.
- A sign-off by your security owner recorded with the connector's register entry.
Reviewing a connector you did not build: Claude MCP security: how to review a connector · AI security assessment of identity, connectors, data and permissions.
Our MCP security review post walks through the same list for a connector someone else built.
What is included, and what is not
The scope is written down before work starts:
| Area | Included | Not included |
|---|---|---|
| Scope | Discovery, a tool list with scopes, and the native-or-custom decision per system | Connecting systems whose vendor forbids API access |
| Build | The MCP server, authentication, validation, logging, tests and documentation | Changes to the business system itself, quoted as separate project work |
| Review | Security review with your owner, per-tool settings and the enabling steps | A full AI security assessment of the whole environment, which has its own scope |
| Hosting | Deployment in your Azure subscription or a private cloud, monitoring and patching | Cloud hosting fees, which you pay the provider |
| Support | Monitoring, fixes and changes under a month-to-month agreement | Guarantees about how the model will use the tools |
| Legal | The data path documented for your counsel | Legal advice on vendor terms or a BAA |
How an MCP integration project runs
From the first call to a server in daily use:
- Scoping call: the system, the questions and actions, the users and the Claude surfaces involved.
- Native-or-custom decision and a one-page tool list with read and write scopes.
- Authentication and hosting design, agreed with your security owner.
- Build and test, including injected-instruction and bad-input cases.
- Review and sign-off, then enabling by an admin with per-tool settings.
- Pilot with a named group, logs reviewed, then wider rollout.
- Hosting, monitoring and changes under a managed agreement, with a quarterly scope review.
Timing depends on the system's API and on how quickly owners approve credentials and hosting; dates go in the proposal.
Someone already added a custom connector to your Claude workspace?
Tell us what it reaches. We will review its tools, credentials and hosting before more staff connect to it.
MCP Development FAQs
What is MCP server development?
It is building a server that speaks the Model Context Protocol, an open standard Claude uses for connectors, so that Claude can call a defined set of tools on one of your systems. A server exposes tools (for example, look up an order, list open tickets, create a draft invoice), each with inputs, outputs and permissions. Development covers the tool design, authentication to the system and to Claude, validation, logging, tests, hosting and the review before anyone enables it. Our post on what the Model Context Protocol is explains the protocol; this page is the service.
How does Claude use MCP?
In the Claude apps, an admin adds a remote MCP server as a custom connector and members connect to it; Anthropic's own connectors for Microsoft 365, Google Drive, Gmail, Google Calendar, GitHub and Slack appear alongside it. In Claude Code, servers are configured at local, project or user scope or delivered by the organization. In Claude Managed Agents, an agent declares servers in its definition with vaulted credentials. In every case Claude calls the server's tools during a task, and for remote servers it does so from Anthropic's cloud, not from the user's device, as of October 2026 (https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp, https://code.claude.com/docs/en/mcp and https://platform.claude.com/docs/en/managed-agents/mcp-connector).
How does a Claude Code MCP integration work, and how do we keep it controlled?
A developer adds a server at local scope, a repository can carry one in a .mcp.json file at project scope, and the organization can deliver servers to everyone through managedMcpServers, which rank above all others. Interactive sessions ask before using a project-scoped server, but non-interactive, SDK and cloud sessions load them without asking, so we block or allow project servers by name with disabledMcpjsonServers, allowedMcpServers and deniedMcpServers. Anthropic recommends HTTP transport for remote servers, marks SSE as deprecated and supports OAuth 2.0 for remote servers, as of October 2026 (https://code.claude.com/docs/en/mcp).
Do we need a custom MCP server, or will a native Claude connector do?
Start with the native connector. Anthropic ships connectors for Microsoft 365, Google Drive, Gmail, Google Calendar, GitHub and Slack on Team and Enterprise, and the Microsoft 365 one uses delegated permissions, read-only by default, after an Entra administrator consents (https://support.claude.com/en/articles/9266767-what-is-the-team-plan and https://support.claude.com/en/articles/12542951-set-up-the-microsoft-365-connector). A custom server is for systems without a connector, or where you need a narrower permission than the native one offers, such as one table of a database rather than a whole file store.
How is an MCP server authenticated?
In two directions. Claude to the server: in the Claude apps a custom connector can use OAuth with Claude's published identity, automatic registration or your own OAuth client, or fixed headers such as an API key stored encrypted; on Team and Enterprise a fixed credential is shared by everyone who uses the connector, so we prefer OAuth. In Claude Code, remote servers support OAuth 2.0 with tokens stored and refreshed by the tool. In Managed Agents, credentials come from a vault at session creation as a static bearer token or OAuth (https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp, https://code.claude.com/docs/en/mcp and https://platform.claude.com/docs/en/managed-agents/mcp-connector). Server to the business system: a least-privilege credential scoped to the tools' needs, kept in a secret store.
Are MCP connectors safe to enable for staff?
They are as safe as their review. Anthropic's own article warns that custom connectors reach services it has not verified, that a malicious server may contain prompt injections, that a server's developer can change tool behavior, and that during Research Claude can call connector tools automatically without further approval (https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp). So before enabling one: read the tools and scopes, prefer OAuth, keep write tools behind approval, disable interactive calls you do not need, test with injected content, and log every call. Anthropic reviews connectors for its directory but does not security-audit or manage any MCP server (https://code.claude.com/docs/en/security).
Who hosts and maintains the MCP server?
NetSys deploys it in your Azure subscription or a private cloud, so the code, logs and credentials stay under your control, allowlists Anthropic's published addresses rather than opening the server to the internet, and runs monitoring, patching, secret rotation and changes under a month-to-month managed agreement. Servers behind a VPN or firewall cannot be reached by the Claude apps, which is why hosting is designed before the build (https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp). You own the source code and documentation, and a failed call alerts a named owner on your side and us.
Is data that passes through an MCP connector covered by Anthropic's BAA?
No. Anthropic's BAA article states that MCPs and connectors are not covered even when available, because data sent to third parties falls outside the BAA, as of October 2026 (https://support.claude.com/en/articles/8114513-business-associate-agreements-baa-for-commercial-customers). The server's own hosting, logging and the business system's terms govern that data instead, which is why the data path is documented for your counsel before a connector touches patient or client records.
How is MCP development priced?
As a fixed-scope project quoted from the one-page tool list, with hosting and monitoring under a month-to-month managed agreement afterward. The number moves with how many tools the server exposes, whether any of them write, how the business system authenticates, and the compliance scope. Anthropic's seat and usage charges and your cloud hosting fees are paid to those providers. NetSys publishes no price list.
Sources and technical references
- Anthropic support: custom connectors using remote MCP (who can add, authentication, network, warnings)
- Claude Code documentation: MCP servers, scopes, transports, OAuth and organization controls
- Claude Platform documentation: MCP connector in Claude Managed Agents (vault credentials, permission policy)
- Claude Code documentation: security, including the statement that Anthropic does not security-audit MCP servers
- Anthropic support: Claude Cowork architecture overview (MDM keys for local MCP servers, cloud sessions)
- Anthropic: Claude Enterprise solutions page (org-wide connector approval, per-tool permissions)
- Anthropic support: set up the Microsoft 365 connector
- Anthropic support: what is the Team plan (native connectors included)
- Anthropic support: business associate agreements, including connectors outside the BAA
Guides on this topic
- What is the Model Context Protocol (MCP)?
- Claude MCP security: how to review a connector
- Claude Microsoft 365 connectors: permissions before rollout
- Claude Code for a company: setup, permissions and review
- AI agents for business, with a charter and approvals
- Custom AI application development on Claude
- Claude consulting: plan, workspace, connectors and pilot
- Claude Code consulting, team setup and developer training
- Microsoft Graph connector development for Copilot
- AI security assessment of identity, connectors, data and permissions
- Cybersecurity risk assessment services
- AI governance and the register of approved tools
- Case study: custom Microsoft Graph connectors with permissions mapped per workflow
- Case study: Claude apps and reporting roundups for a lean team
Give Claude one door into the system, and a lock on it.
Tell us the system, what Claude should read or do there and who would use it. We will say whether a native connector covers it, and if not, what the server would need.