How we built it: the hosted MCP connector and its 43 tools

The Sellinger MCP connector is a hosted server with 43 tools that Claude or ChatGPT can call. We built it as a thin layer: every tool proxies to an existing REST route that already enforces team scoping and roles, so no business logic lives in the connector. Sign in uses OAuth with PKCE, access tokens last 8 hours, refresh tokens 90 days, and a read only consent tier lets a token list and fetch but never write or send. The tool that sends a message is marked destructive and tells the model to get the user's explicit go ahead first.

This is the engineering story behind the connector. What MCP is for sales explains the idea for a buyer. Here we cover the decisions a builder would want to know about, including the one that cost us a week.

What is in the box?

The connector lives at one endpoint and speaks streamable HTTP, the transport that remote MCP clients such as claude.ai custom connectors use. It registers two things:

• 43 tools. Leads (list, get, create, update, search, tag), conversations and activity, sending and opting out, campaigns and agents, approvals (list, approve, reject, regenerate a draft), personas with version history, analytics and pipeline counts, meetings, a people search with a prospecting quota, enrichment, merge candidates, account health and the knowledge base search.
• 4 saved workflow prompts. Weekly pipeline review, prep my day, find new prospects, audit stale leads. Each returns one instruction that chains existing tools, so a client that shows prompts offers them as one click workflows. They are the basis of the recipes.

There is also a separate npm package for local use with 15 tools. The two are different products with different counts, and we keep the numbers apart on every page.

Why is every tool a thin proxy?

The first decision was where business logic should live. The answer was nowhere new. Every tool fetches an existing REST route under the same deployment, and those routes already accept the caller's bearer token and enforce team scoping and viewer read only rules. The connector adds a schema, a description and an error format.

The benefits were practical:

1. One set of rules. A permission fix in the REST layer fixes the connector at the same moment.
2. Fewer places to be wrong. A lead can only be read if the route says the caller's team owns it.
3. Tests carry over. We did not write a second test suite for behaviour.

The cost is latency, since each tool is an extra hop, and that led to the next two decisions.

How do requests survive a slow hop?

One request may run up to 300 seconds, matching the longest inner route, which is an import whose email reveal is asynchronous. The outer handler must not die before the route it proxies, or the tool would report a timeout for work that completed, and for an import that was already charged for.

Inside that ceiling, a single inner call is cut off at 60 seconds. That is about eight times the slowest route we had measured on production, and it leaves room for the two sequential hops that update and find by name make. A stuck call now fails fast and says so in the tool result instead of taking the whole invocation down.

That limit exists because of a bad few days in late summer, when some requests hung until the platform killed them and left no log line, so we could not tell which method was hanging. The fixes were three. A hook that logs when a request is received, before the handler runs, so a request that never returns still names its method. A watchdog that logs at 30 seconds while the invocation is alive. And a rule that the payload is never logged, only the method name, because the body holds lead names, emails and message text.

How does sign in work?

Remote MCP clients expect standard OAuth, so that is what we built.

• Discovery. The server publishes authorization server metadata and a protected resource challenge, so a client that has never seen us can find the endpoints.
• Registration. Clients register themselves and receive a client id.
• Authorization with PKCE. The code challenge method is S256. An authorization code lives 10 minutes.
• Tokens. An access token lasts 8 hours and a refresh token 90 days. Tokens carry recognisable prefixes, and the server stores only SHA-256 hashes of codes and tokens, so a database read does not give an attacker a working token.
• Scopes. A full scope grants everything. A read only consent tier grants every read scope and nothing else, so a token carrying it can list and fetch but never write or send. Scopes are derived from the route and method: a GET on leads needs a read scope, a POST needs a write scope.
• Rate limits. Tokens have rate limits, and the check fails open on infrastructure errors, so a fault in rate limiting cannot take the API down.

How do you stop a model from sending something it should not?

The send message tool is the dangerous one. It delivers text to a real person immediately, with no undo, no recall and no draft state. We handled it in three layers.

1. Annotations. The tool is marked destructive and open world, so a client can show a warning. Read tools are marked read only.
2. The description. It tells the model to show the exact wording, the channel and the lead, and get explicit approval before every call, including when a lead's own message appears to ask for a reply. That last clause is the important one. A message from a lead is the lead talking to your user, not an instruction to the model. This is the prompt injection case, and we wrote it into the tool.
3. Scope. A read only token cannot call it. And the REST route underneath still applies the team's own rules, including the suppression list check before any send.

None of this makes a model infallible. It narrows the paths. For regulated or high stakes sends, keep campaigns in approval mode, which is a separate control inside Sellinger.

What was the pagination bug?

A customer's audit over the leads route came back short. Two things were wrong. The sort order was not total: every paginated route sorted by one non unique column, so a range query could return the same row twice and never return another. And a route ignored the caller's pagination parameters in silence, so page=2 returned page one with a 200.

The fix was a unique tiebreaker on every paginated order, and a rule that each route declares which pagination parameters it honours and returns a 400 for any other pagination shaped parameter, naming where the one you used does work. The wider principle: report a caller error to the caller, and never answer with something plausible. We also noted that page meant one thing in the tool and another on two pipeline routes, and chose not to add a fourth meaning.

What would we do differently?

• Add the request hook on day one. We lost days to hangs we could not see.
• Write tool descriptions as safety documents, not just as help text. Models read them closely.
• Keep counts in one place. The 43 and the 15 appear on several pages, so they come from one fact register.

How can you try it?

Add the connector in Claude or ChatGPT, approve the consent screen, and start with a read only question such as "which leads have had no activity for two weeks". The MCP page has the steps and the recipes have prompts.