Scottship Solutions builds thin custom MCP servers around vendor APIs for nonprofits, including a read-only Salesforce server that exposes exactly four tools because the organization’s Base Edition license offers no hosted MCP feature. This guide covers how to build a custom MCP server when the official connector is read-only, missing the endpoint the work depends on, or rate-limited, and it is written for nonprofit operations, finance, and development leads rather than platform engineering teams. A thin wrapper around one already-authenticated vendor API costs $7 to $12 a month to host on AWS Lightsail, and sometimes the right answer is to skip MCP and call the vendor’s REST API directly.
Scottship’s MCP work is led by Parker Davis, Founder and Fractional CIO, who holds Claude Certified Architect and TOGAF Standard credentials. It sits inside our AI and automation for nonprofits practice. We built two servers from scratch, forked and modified a third, and then wrote down the cases where the plain REST API beat the protocol.
Here is the situation this guide is written for. A development director wants Claude to pull a donor pipeline snapshot out of Salesforce without asking anyone to export a report first. The hosted path does not exist on that organization’s license tier, so the question becomes whether to build something and how small that something can be.
What You’ll Learn
- What is an MCP server, and is a Claude connector the same thing?
- Why is the official MCP connector read-only?
- When should you build your own MCP server instead of using the official one?
- When should you skip MCP entirely and just call the REST API?
- How do you build a custom MCP server around a vendor API?
- What breaks when you fork someone else’s MCP server?
- What does it cost to build and run a custom MCP server?
- What has to be true before you put an MCP server on the public internet?
- Who maintains a custom MCP server after it is built?
What is an MCP server, and is a Claude connector the same thing?
Yes. An MCP server is a program that exposes one system’s capabilities to an AI assistant over the Model Context Protocol, and a custom Claude connector is a remote MCP server viewed from the product side. An MCP connector is the platform feature that reaches one of those servers, and MCP integration is the umbrella phrase most non-technical buyers reach for first. MCP apps and MCP plugins are two further naming layers for the same architecture, which is why the vocabulary feels harder than the thing it describes.
That vocabulary gap is not trivial. A finance lead searching for a custom connector and a consultant searching for a custom MCP server are asking the same question and landing on different pages. The protocol itself defines three capability types, documented by the Model Context Protocol project.
- Tools: actions the model can call, such as running a query or creating a record.
- Resources: data the model can read, such as a file, a record set, or a report.
- Prompts: reusable templates a person invokes deliberately rather than the model choosing.
The 5 Levels of AI framework is a useful way to place the decision before you place the code. A read-only vendor connector that answers questions in chat sits lower than an agent that writes back into the system of record. Asking which level an integration puts your organization at settles the build argument faster than a feature comparison does. If your team is earlier than that, start with Claude AI for nonprofits.
Why is the official MCP connector read-only?
This is the question with the thinnest supply in the whole field, and it has three real answers. Only one of them is something you can change from a settings page. Separating them tells you whether to file a support ticket, buy a different license, or start building.
- Vendor risk posture. The vendor shipped reads first and is holding writes back deliberately.
- Licensing tier. Your plan does not include the write feature, and no amount of configuration adds it.
- Configuration. The server does support writes, and whoever installed it turned them off.
The evidence is checkable, and each item below comes from the publisher’s own page as of September 2026. CData ships a read-only QuickBooks MCP server and sells full create, read, update, and delete access as a separate paid driver. Kipper is read-only by architecture and markets that constraint as a feature for finance teams. The community Google Workspace MCP server, an MIT-licensed open-source project maintained by taylorwilsdon rather than a Google product, ships a read-only mode and tool tiers, so what you get depends on how the server was configured before it reached you.
Our own Salesforce server is read-only structurally rather than by setting. There are no write commands anywhere in the codebase, so the mode is not a flag anyone can flip under pressure. With no writes there is no who-changed-what attribution gap, and an internet-facing service holding CRM access carries far less risk.
The honest version of that claim matters more than the claim. The read-only guarantee lives in our code, not in the token. A compromised host would still hold a Salesforce identity with write rights, which is why the server sits behind Google Workspace sign-in and writes an audit line for every call. No generic tutorial states its residual risk, and you should be suspicious of the ones that skip it.
When should you build your own MCP server instead of using the official one?
Run this checklist before anyone writes code. It takes about five minutes and it ends the conversation most of the time, because the official connector covers the task more often than not. Four failure modes justify a build. Everything else is a reason to keep what the vendor ships.
- Read-only when you need a write. The task is data entry, not data retrieval, and the connector will not perform it.
- A missing endpoint. The underlying REST API exposes the capability and the connector does not surface it.
- Rate limits that break a batch workflow. The connector works for one record and fails for four hundred.
- Wrong shape. The connector exposes raw resources when a staff person needs one specific task completed.
QuickBooks is the clearest example available, and nobody has written it down. As of September 2026, Intuit publishes an official QuickBooks Online MCP server carrying 145 tools across 29 entity types, with create, read, update, delete, search, and 11 reports. The underlying REST API exposes batch operations, change data capture for incremental sync, and webhook notifications, and the server’s README lists no batch, change-data-capture, or webhook tools. A finance team syncing a night’s worth of transactions hits that gap on the first run.
| Question | Official connector | Thin custom wrapper | Direct REST API |
|---|---|---|---|
| When it wins | The vendor already covers your task and the permissions match | The API does the thing, the connector does not, and staff need it in chat | Bulk, scheduled, or auditable work that no human is watching |
| What it costs | Included with the plan, or a paid driver tier | Days of engineering plus $7 to $12 a month in hosting | Developer time only, with no server to host |
| Who operates it | The vendor | You, or a fractional technology partner | Whoever owns the script |
| What breaks | Scope you cannot change and a roadmap you do not control | The vendor ships an API change and someone has to notice | Nothing is available in conversation, so staff cannot self-serve |
When should you skip MCP entirely and just call the REST API?
Almost nobody publishes this section, because most people publishing on the topic sell either the protocol work or the alternative to it. Our default for ClickUp work is the direct REST API rather than the MCP.
Observed repeatedly in our own workspace, ClickUp MCP tool invocations silently no-op on custom field writes, mis-map parameters on complex filters, degrade @mentions to plain text, and lack reliable retry semantics on bulk operations. A silent no-op is the worst class of failure available. The assistant reports success, the log looks clean, and the field stays empty until somebody opens the task by hand.
MCP is the wrong tool for:
- Custom field writes
- Bulk operations
- Complex filtering
- Any write that has to be auditable
- Webhook management
- Production scripts
MCP is the right tool for:
- Simple read-only lookups during a conversation
- Exploratory queries where a wrong answer costs nothing
- Low-stakes operations a person is watching in real time
One caveat, and it is the reason this is not a verdict on the protocol. In a simpler workspace the ClickUp MCP is perfectly adequate. Ours is not simple, and three properties explain why: lists move between folders and get renamed often enough that cached hierarchy trees go stale, one space carries more than twenty custom fields with strict value formats, and overlapping task names defeat search-based disambiguation.
The model you point at the problem is not the variable either. Our review of Claude Fable 5.1 for nonprofits covers what the current generation handles well, and no model repairs a tool that reports success without writing anything.
How do you build a custom MCP server around a vendor API?
The pattern is deliberately small, and small is the whole point. Wrap one vendor API that is already authenticated, expose only the tools one real task needs, and keep permissions tight. Nothing in that sequence requires a platform engineering team or a new system of record.
Two numbers make the scope concrete. Our Salesforce server exposes four tools: a SELECT-only SOQL query capped at 2,000 rows, describe object, list objects, and a pipeline snapshot. Our Google Admin server is a completed build exposing 34 tools across users, groups, members, org units, roles, OAuth tokens, domains, and reports. A small tool surface is the same discipline that makes an agent useful, which we covered in what a sub-agent in AI actually is.
The Salesforce server exists because of a licensing wall, not a feature preference. Our Salesforce org runs on Base Edition, which offers no hosted MCP servers feature and no custom connected apps, so per-user Salesforce OAuth was never available to us. The server therefore holds one Salesforce identity and gates access at our layer with Google Workspace sign-in.
Two stacks both work, and the choice is about reach rather than language. Python with fastmcp over stdio fits when the server runs on one machine for one person. Node with the official SDK over streamable HTTP fits when a team needs to reach it across the internet. Scottship runs one of each, which is how we know the difference is reach and not preference.
Two safety patterns are worth copying whichever stack you pick.
- Destructive operations no-op unless confirmed. A delete or suspend call does nothing at all unless it arrives with an explicit confirm flag set by the caller.
- Credential stores are isolated per privilege level, not per application. The high-privilege admin token lives in its own credential directory and is never comingled with the daily Gmail and Drive token.
What breaks when you fork someone else’s MCP server?
Forking looks cheaper than building until you count the changes. We vendored the community Google Workspace MCP server, upstream taylorwilsdon/google_workspace_mcp under the MIT license, and needed four documented changes before it was usable. It runs today on our intranet host behind path routes, and the analytics and search unit carries 14 read tools.
- GA4 report tools that did not exist. The upstream analytics module wrapped the Admin API only and could not return traffic, so we added the GA4 Data API report tools.
- A bearer-token gate. No authentication middleware existed for the HTTP transport at all.
- An analytics scope key. The service decorator had no scope entry for the GA4 Data API.
- A tool registry bugfix. The tool filter returned early whenever no per-tool tier list was set, so the read-only flag pruned nothing.
The registry bug is the one to remember. A safety flag that reports success while doing nothing is precisely the failure a small team with no engineer will never detect on its own. The server started, the flag was accepted, the logs looked clean, and every write tool stayed registered the whole time.
A second bug is worth naming because it costs an afternoon and appears in no tutorial. FastMCP 2.x ignores the streamable HTTP app override, so middleware has to be passed through the server run call instead of attached to the app object. Details at that grain are the difference between a page that helps and a page that summarizes.
One clarification about counting, because the temptation to inflate is real. Three other MCP folders in our repository are unmodified upstream code that we run as they came. Those are not Scottship builds and we do not describe them as such. The defensible count is two servers built from scratch plus one fork.
What does it cost to build and run a custom MCP server?
Custom MCP server development cost is the query with the widest spread and the least segmentation anywhere in this topic. The published range runs from $3,000 to well over $400,000 for the same question, and no page separates cost by scope. A spread that wide is a credibility vacuum, so every row below keeps the name of whoever published it.
| Scope | Range | Source |
|---|---|---|
| Hosting, one Lightsail instance carrying several servers behind path routes | $7 to $12 per month | Scottship, host decided August 17, 2026 |
| Simple single-tool server, one API, read-only | $3,000 to $8,000 | SaTekk, as of September 2026 |
| Basic MVP, 8 to 12 read-focused tools, single tenant | $8,000 to $15,000 | MakeAnAppLike, as of September 2026 |
| Build with integrations | $8,000 to $25,000 | Intuz, as of September 2026 |
| Multi-source server, then full enterprise | $15,000 to $40,000, then $40,000 to $75,000 | AppMatic, as of September 2026 |
| Agency-scale range, basic MVP through enterprise | $25,000 to $400,000+ | Bacancy, as of September 2026 |
| Ongoing cost, all in | $200 to $1,200 per month | Tripleminds, as of September 2026 |
| Ongoing maintenance | $500 to $2,500 per month | SaTekk, as of September 2026 |
| Total cost of ownership, per integration per year | $50,000 to $150,000 | Truto, a managed-integration vendor, as of September 2026 |
The loudest number in that table deserves a correction. The $50,000 to $150,000 per integration per year figure originated with Truto, a company that sells managed integrations, and it is repeated across managed-MCP vendor content. It is a build-versus-buy sales figure rather than a measured cost, and it sits roughly an order of magnitude above what a thin single-purpose wrapper costs to own. When the number deciding your build-versus-buy call comes from the vendor selling the buy option, check who wrote it.
The figure we can stand behind is the hosting line. A single AWS Lightsail instance carrying several servers behind path routes is budgeted at $7 to $12 a month, the estimate behind a host decision we made on August 17, 2026 for a dedicated MCP host that is approved and not yet provisioned. Build effort is the other half of the answer, and for a thin wrapper around one already-authenticated vendor API that is a matter of days of engineering rather than a year-long program.
What has to be true before you put an MCP server on the public internet?
Treat these as build gates rather than an enterprise checklist. Two of them will stop a project before anyone writes a line of code, and hitting them now is cheaper than hitting them after the build. None of them requires a VPC or a load-testing budget.
Reachability comes first and it surprises people. As of September 2026, a custom connector needs a stable public HTTPS URL speaking streamable HTTP, and legacy SSE is deprecated. Hosted claude.ai connects from Anthropic’s cloud egress range 160.79.104.0/21, not from the user’s own machine. A server behind a VPN or a corporate firewall will not connect even when it works perfectly on a laptop.
Authentication splits by client, which is the constraint that shapes everything else. As of September 2026, claude.ai custom connectors support a static bearer header only as a beta option that an organization administrator enters once for everyone, so per-user team access still runs on full OAuth 2.1, while Claude Code can use a static bearer token today. That is why Scottship runs two auth models side by side rather than settling on one.
Two operating limits shape how you design tools. Tool calls time out at 300 seconds on claude.ai and results cap at roughly 150,000 characters, so a tool that returns an unbounded query result will fail in production after passing every local test. Every call to our Salesforce server appends a JSONL audit line carrying timestamp, actor, tool, query, row count, and milliseconds.
One clarification about our own hosting, because accuracy matters more here than polish. The single-identity servers run today on our intranet host behind path routes. A dedicated OAuth-capable MCP host is approved and planned, and provisioning has not been executed yet.
Who maintains a custom MCP server after it is built?
Three conditions have to hold before building is the right call. The vendor interface has to be stable enough to wrap, your data has to stay your data, and somebody has to be willing to operate the service. The third condition is where most small organizations stop.
That third condition is also the strongest argument against building, and it deserves to be. A server nobody owns becomes a broken integration, and then it becomes a security question nobody wants to answer. Naming the operator before the build starts is most of the governance conversation.
For an organization with no engineers on staff, the operator is a fractional technology partner, which is what Scottship Solutions does for nonprofits. That is a direct answer to the objection, and it is one a project-based development shop is not structured to give. Somebody has to still be there in month nine.
The maintenance profile of a thin wrapper is not the enterprise figure either. Tripleminds publishes ongoing cost at $200 to $1,200 a month all in, and SaTekk publishes $500 to $2,500 a month, both as of September 2026. For a wrapper around one stable vendor API the real work is narrower and easier to name: the vendor ships an API change, and somebody has to notice and fix it.
Frequently Asked Questions
What is the cost to build and maintain an MCP server?
The honest answer separates hosting from build. Hosting a thin wrapper is budgeted at $7 to $12 a month on a single AWS Lightsail instance carrying several servers behind path routes, which is Scottship’s estimate as of September 2026 for a dedicated host that is approved and not yet provisioned. Build cost depends on scope, and the published field runs from $3,000 to $8,000 for a simple single-tool server per SaTekk, to $8,000 to $15,000 for a basic MVP of 8 to 12 tools per MakeAnAppLike, up to $25,000 to $400,000+ at agency scale per Bacancy. Ongoing cost is quoted at $200 to $1,200 a month by Tripleminds and $500 to $2,500 a month by SaTekk.
How long does it take to build a production-ready MCP server?
Published timelines vary by publisher, so read them as ranges rather than as one number. Intuz puts a build at 1 to 2 weeks plus 2 to 4 weeks of hardening. SaTekk puts a simple server at 1 to 2 weeks, a production integration at 3 to 6 weeks, and a complex build at 6 to 12 weeks, both as of September 2026. A thin wrapper around one vendor API that is already authenticated sits at the short end of those ranges, because authentication is the part that consumes the calendar.
Can MCP integrate with my existing business applications?
Yes. MCP integration works with any system that exposes a REST API, a GraphQL endpoint, or an SDK, because the server wraps the existing interface instead of replacing it. The practical limits are authentication and permissions rather than protocol support. Systems with no programmatic interface at all are the exception, and no protocol solves that problem.
Is it safe to give an AI assistant write access to QuickBooks or Salesforce?
Write access is a risk decision rather than a technical one, and it should be made deliberately. Scottship’s Salesforce server is read-only structurally, with no write commands in the codebase, because with no writes there is no who-changed-what attribution gap and an internet-facing service holding CRM access carries far less risk. If you do enable writes, require a confirm flag on destructive operations, log every call with actor and timestamp, and scope the token to the narrowest role that still does the job.
Does Google Workspace MCP work with nonprofit plans?
The widely used Google Workspace MCP server is a community open-source project, taylorwilsdon/google_workspace_mcp, published under the MIT license rather than by Google. Its README states that it works with free Google accounts and Google Workspace plans, and it covers twelve service groups. As of September 2026 it also ships a read-only mode and tool tiers, so the capability you actually get depends on how the server was configured rather than on the plan alone. Read the repository before you plan around it, because connector details in this category move quickly.
Your Next Steps
- Check whether an official connector exists: search your vendor’s documentation for MCP or connector before assuming a build is needed.
- Run the four failure modes: read-only, missing endpoint, rate limits, wrong shape. Only these justify building.
- Test the REST API against the same task: if the work is bulk, scripted, or has to be auditable, the plain API is the better tool.
- Scope the smallest useful server: name one task, list the tools that task needs, and stop there.
- Decide the operator before the build: write down who patches it when the vendor changes the API.
- Check reachability early: confirm the host can be reached over public HTTPS from Anthropic’s cloud egress range.
Sources
- Model Context Protocol documentation, the three capability types and the server build sequence
- Anthropic connector documentation, streamable HTTP requirement, SSE deprecation, 300-second tool timeout, and 150,000-character result cap, verified August 17, 2026
- Anthropic connector authentication documentation, static bearer headers supported in beta, OAuth 2.1 for team access, and the cloud egress range 160.79.104.0/21, as of September 2026
- Builder.io, a walkthrough covering tools, resources, and prompts together
- freeCodeCamp, the FastMCP build pattern in Python
- IBM, error handling inside an MCP tool implementation
- Cloudflare developer documentation, deploying a remote MCP server
- charity-mcp-server on GitHub, exposing IRS charity database lookups to an assistant
- Intuz build guide, a build timeline of 1 to 2 weeks plus 2 to 4 weeks of hardening
- SaTekk cost guide, timelines of 1 to 2 weeks, 3 to 6 weeks, and 6 to 12 weeks by scope
- Intuit, the official QuickBooks Online MCP server, 145 tools across 29 entity types with 11 reports, as of September 2026
- CData, a read-only QuickBooks MCP server with full create, read, update, and delete sold as a separate paid driver, as of September 2026
- Kipper, read-only by architecture and marketed that way for finance teams, as of September 2026
- taylorwilsdon/google_workspace_mcp, an MIT-licensed community server whose README states support for free Google accounts and Google Workspace plans, across twelve service groups, with a read-only mode and tool tiers
- Salesforce developer blog, hosted MCP Servers generally available for Enterprise Edition and above, which is why Base Edition carries no such feature
- Scottship Solutions internal build records, covering server tool counts, fork modifications, and the August 17, 2026 hosting decision
At Scottship Solutions, we help nonprofits get real work out of AI assistants without handing over more access than the work requires. From AI agents for nonprofits to the thin server builds described above, our team scopes the smallest thing that solves the problem and then stays on to operate it. Our process automation work returned 750+ staff hours a year and removed $8,800 a year in redundant software cost for Carousel Child Advocacy Center, and $6,200 a year for kNot Today.
If your vendor’s connector stops one step short of what your team actually needs, it is worth a conversation before anyone scopes a build. Tell us what you are working on.
Written by
Parker Davis
Founder & Fractional CIO at Scottship Solutions
Parker works hands-on with nonprofit and small business leaders on IT strategy, cybersecurity, AI implementation, and cloud architecture. He founded Scottship Solutions to help mission-driven organizations build reliable, secure technology infrastructure.
Certifications
IBM AI Product Manager • Lean Six Sigma Yellow Belt • TOGAF Standard • Claude Certified Architect
Industries Served
Human Services, Healthcare & Community Health, Arts & Culture, Education & Youth Development, Faith-Based, Foundations & Grantmakers, Child Advocacy