How Do You Connect AskElephant to Claude.ai?

Our team lives in claude.ai. Our calls live in AskElephant. For months those two facts did not meet, and the reason turned out to be more interesting than a missing feature.

AskElephant does ship an MCP server. It runs locally, over stdio, which means a process on your own machine. That serves Claude Desktop, Cursor, VS Code and Windsurf perfectly well. It does nothing at all for claude.ai, because a browser cannot launch a process on your laptop. A web client can only make network requests, so it needs an MCP server that lives at an address.

So we built one, put it on Cloudflare, and gave it away. The build was the easy part. The interesting part was working out what it should refuse to do.

Why is a hosted MCP server different from a local one?

A local server trusts its environment. It runs as you, on your machine, with your credentials already present.

A hosted one has none of that. It is a public URL, so it needs to answer three questions the local version never faces: who is calling, are they allowed, and how much can they ask for at once. The first two are authentication. The third is the one people underestimate, and it is where most of our engineering time went.

How big is a call transcript, really?

Bigger than it feels. This is the measurement that reshaped the whole design.

We measured every one of the 3,706 engagements in our own AskElephant account. 2,230 of them carry a transcript:

	Characters	Approximate tokens
Average transcript-bearing call	32,485	8,100
Median call	28,240	7,060
Largest measured	175,643	43,900

The largest single call in our archive occupies more than a fifth of a 200,000-token context window on its own. Ask a question that touches forty calls, hand the model the transcripts, and you are asking it to read roughly 325,000 tokens. That does not fit. It is not slow or expensive; it is impossible.

That number is the whole design brief. Everything else follows from it.

What is the alternative to sending transcripts to the model?

Do the reading somewhere else.

The connector fetches the transcripts, scans them on the server, and returns only the passages that matched, each with its speaker and timestamp. The model never sees the rest. Our design note for this is one sentence:

The Worker does the reading. Claude does the thinking.

A real forty-meeting search, run through claude.ai against our live archive, returned 76,757 characters of excerpt: roughly 19,200 tokens instead of 325,000. That is a factor of seventeen, and it is the difference between a feature that works and one that cannot exist.

There is a second benefit that matters more day to day. Because the answer arrives as excerpts rather than transcripts, the model still has room to think about it. You can ask a follow-up. You can ask it to compare what you promised in a kickoff against what you said three months later. That conversation is impossible if the first answer consumed the budget.

What did we get wrong?

Four things, all worth repeating because they are the kind of mistake that ships quietly.

Our safety limits multiplied. We capped how many meetings a search could scan at forty, how many excerpts each meeting could return at ten, and how wide an excerpt could be at 2,000 characters. Each limit is sensible alone. Their product is about 229,000 tokens, which overruns the window the caps existed to protect. The fix is a single budget across the whole search, and a header that says plainly when a result was cut for size rather than for relevance.

A failed search looked exactly like an empty one. If the API key were rotated, every transcript fetch would fail, and the tool would answer "Scanned 40 meetings. No matches." A person reading that concludes the topic was never discussed. That is worse than an error, because it is a confident wrong answer. The connector now counts what it could not read and says so.

We assumed something about the vendor's search and were wrong twice. We believed AskElephant's search parameter matched transcript bodies. It matches titles only. Then we "proved" it with words like "pricing" and "onboarding", which are exactly the words that also appear in meeting titles, so the test could not tell the two behaviours apart. The proof that worked was a phrase spoken mid-call that appears nowhere in the title, tested against a call from 2023 so that indexing lag could not explain the result.

Some transcripts arrive containing the same call twice, and we only found out by using the thing. The vendor's transcript field can hold the whole call, an attachment marker, then a character-for-character second copy. On the call that exposed it: 59,088 characters, the opening line recurring at offset 29,575, the second half identical across all 29,513 of its characters. Search was finding every match twice and paying for each passage twice. Across the archive it affects 5.8% of transcripts and about a million tokens.

That one carries two lessons, and the second is the more useful. The first is that no amount of review substitutes for running the thing against real data: this survived a full build and a review pass on every task, then fell out of the first serious question a human asked it.

The second is about how we nearly got the measurement wrong. Our first count of the damage came from the transcripts the Worker had cached, and said half of them were affected. That was the same mistake in a new costume: the cache holds the meetings our searches happened to touch, which skews recent, internal and bot-recorded, which is precisely the population that duplicates. Measuring the cache measures your own query history. Re-measuring all 2,230 transcripts put the real figure at 5.8%.

The general lesson across all four: the plan said what the API did. Nobody had asked the API.

How much did Claude Code and Cloudflare actually help?

Honestly, a lot, and not in the way the pitch usually goes.

The code was never the bottleneck. Roughly 1,600 lines of TypeScript and 1,300 lines of tests came together in about a day. Cloudflare's workers-oauth-provider handles the authentication dance that claude.ai expects, which is the part everyone gets stuck on, and we had a working version of that from a previous internal tool that we copied without modification.

Where the leverage actually showed up was in the reviewing. Every task was written, then reviewed by a separate pass with no attachment to the code, then fixed and re-reviewed. That process caught the first three defects above plus several smaller ones. Notably, most of the real bugs originated in the plan rather than in the implementation: a filter shape copied from our own earlier notes that the live API rejects outright, a date format that returns a 400, a contact field that renders as [object Object] because the type we hand-wrote and the fixture we invented agreed with each other and both disagreed with the vendor.

A fast implementer with no reviewer would have shipped all of those.

And review still was not enough. The duplicate-transcript bug passed every one of those gates and was caught by the first real question a person asked the finished tool. Reviewers check code against a plan. They cannot check a plan against reality.

The limit of that claim: this is one tool, built by one team, against one vendor's API. The engineering numbers above are measured, on the live archive rather than a sample. The durability of the approach across other integrations is not something a single build can establish.

Should you build one of these?

If you use AskElephant and your team works in claude.ai, the repository is public and the setup guide covers the whole path: the Cloudflare account, two storage namespaces, the access application, five secrets, and the connector URL. You deploy it against your own key, on your own account. Nothing routes through us.

If you are building any hosted MCP server, the transferable part is not our code. It is the question we should have asked on day one: what is the largest thing a caller can ask for, and does that fit? Answer that before you write the tools, because it determines what the tools should be.

We take the same view of tooling generally, which is why the HubSpot portal audit tool we published earlier is also read-only and also open source. A tool that touches a client's data should be one a client can read.

If you would rather not build it, that is the kind of integration work we do.