Node8 built and shipped a production MCP server for a leading investment research firm — Google Cloud hosting, OAuth 2.1, and connector submissions to Claude, ChatGPT, and Microsoft Copilot (full story: engagement overview, case study). These are the questions buyers actually asked us, answered from that build.
How long does it take to get an MCP server into production?
About four weeks from kickoff to a live production server, in our engagement — with directory submissions underway by week six. The precondition is that your data is already reachable through internal APIs; the MCP server wraps and shapes those APIs rather than replacing them. The schedule risks are not the server code. They are: choosing the identity platform (nothing user-facing proceeds until auth is settled), and the strict DNS → HTTPS certificate → OAuth app registration dependency chain, which involves your IT and domain owners. Start both in week one.
What does it cost to build and run?
Three buckets. Build: a scoped engineering project — weeks, not quarters — covering tool design, the OAuth integration, hosting, and observability. Run: on serverless Google Cloud infrastructure (Cloud Run), the server scales to zero when idle, so infrastructure cost tracks actual usage and starts near zero; the identity platform is a subscription line item. Own: plan for part-time engineering ownership — tool iteration, dependency updates, and responding to directory-review feedback. Put billing alerts and quota caps on the project before launch; assistant-driven traffic patterns are burstier than human ones.
Is our proprietary data safe going through AI assistants?
The connector model is narrower than people fear. A user must explicitly connect and complete an OAuth 2.1 authorization; after that, every tool call is authenticated as that specific user. Your server decides what each tool returns — shaped responses to specific questions, not bulk data access. You keep rate limiting, entitlements, and full usage logging on your side, and you can revoke a user, an organization, or an entire assistant client at any time. Under the standard enterprise connector model, connector responses are not used to train the assistants’ models.
How does per-user governance work when the assistant makes the calls?
This was a core design decision in our build. The MCP server authenticates to the firm’s backend as a single machine identity, and passes the authenticated user’s ID on every backend call. The backend rate-limits and entitles on that user ID. Legacy systems never had to learn OAuth, and per-user governance survived intact. Note the honest cost: it required a small backend change (accepting the user parameter and updating rate-limit logic). Details in the architecture page.
Do we need separate servers for Claude, ChatGPT, and Copilot?
No — that’s the point of the standard. One server served all of them in our build, plus Perplexity. Each assistant registers as its own OAuth client (support dynamic client registration and model the assistants as distinct client types), and each directory requires its own submission — but it’s one codebase, one deployment, one set of tools.
What do the connector directories require, and how long is review?
Each ecosystem has different prerequisites: Anthropic requires submitting through a Claude for Teams account (five-seat minimum — a personal paid account doesn’t qualify); OpenAI submissions go through the platform dashboard and require owner/admin-level permissions on your corporate OpenAI account, which someone has to actually hold; Microsoft’s process is form-based and does not require Partner verification to submit. Reviews run on their own clocks — submit in parallel, and pilot through side doors while you wait (Claude workspace custom connectors; the M365 admin center’s direct MCP connection). The full playbook: getting listed in Claude, ChatGPT, and Copilot.
Can enterprise customers use the connector before it’s in a marketplace?
Yes. Microsoft 365 admins can connect a tenant directly to an MCP server from the admin center, and Claude workspaces can add custom connectors. Our client ran its internal pilot this way while marketplace review proceeded. One caveat we verified the hard way: access and sign-in flows can differ between the direct path and the marketplace path, so re-test when you switch. Admin-side detail: enterprise Copilot agents and connectors.
How do enterprise customers’ employees sign in?
Through their existing corporate identity. The pattern: the connector’s identity layer defines an organization per customer, bound to the customer’s trusted email domains, with SSO configured against the customer’s identity provider (Microsoft Entra via OIDC in our first enterprise rollout). Individuals outside an enterprise use Google or Microsoft social login. Onboarding a new enterprise customer is configuration, not code.
Should we expose our existing API endpoints as tools?
No. This is the most common design mistake. Hundreds of granular endpoints make the assistant slow, expensive, and error-prone — every tool definition consumes context tokens in every conversation. Design a small set of task-oriented tools around what users actually ask. We launched with three tool groups covering 100+ content categories and hundreds of internal endpoints, then expanded deliberately. The reasoning: why MCP instead of a traditional API.
What maintenance does an MCP server need after launch?
Four recurring streams: tool iteration (usage analytics show which tools get called, which fail, and what users ask that you don’t cover — treat it as product work); directory relations (review feedback, policy updates, and resubmissions as the ecosystems evolve); auth housekeeping (client registrations, token lifetimes, key rotation for the machine-to-machine credential); and ordinary service operations (monitoring, dependency updates, cost review). It’s a product with a small surface, not a fire-and-forget integration.
What goes wrong most often?
From our build, in order of pain: choosing the auth vendor late (it blocks everything user-facing); developing on infrastructure you’ll have to migrate off — build in the customer’s own cloud project from day one; underestimating the DNS/HTTPS/privacy-policy prerequisites for OAuth app registration; account-ownership archaeology (nobody knowing who holds admin on the corporate OpenAI account); and assuming marketplace review is fast — it isn’t, so plan pilot channels that don’t depend on it.
Does this only work for financial data?
No. Financial research is a natural fit — users ask assistants exactly the questions the data answers — but the pattern holds for legal and regulatory content, healthcare datasets, industry benchmarks, market intelligence, and product catalogs. The test: if your customers already paste your content into ChatGPT by hand, an MCP server converts that into a governed, authenticated, measurable channel.
Work with Node8
Node8 builds production MCP servers end to end — architecture, OAuth, Google Cloud infrastructure, directory submissions, and enterprise rollout. If these questions are on your whiteboard, talk to us and we’ll answer them for your data specifically.