MCP connector comparison

MCP connectors or Chat with Work?

MCP gives the model an API: search and read tools, hand back whatever the server returns. Chat with Work gives the model a designed tool layer: search comes back with a one-line preview so the model can triage cheaply, and read pulls the relevant section instead of the whole file. Same building blocks, very different result in the model's context window.

Side by side.

Both expose tools to a language model. They make very different choices about what those tools return.

Dimension Generic MCP connector Chat with Work tool layer
Tool engineering Tools are a thin API wrapper. Whoever wires them up has to design the flow. Tools are part of the product. Each one returns just enough for the model to make a smart next call.
What search returns File IDs and metadata. The model has to read to know more. Metadata plus a one-line preview of where your terms hit, for every candidate.
What read returns Usually the whole file. PDFs and long docs come back in full. Just the relevant section. Cached as text once, reused next time the same file comes up.
Context window cost Reading is expensive — the whole file lands in context whether the model needed all of it or not. Triage is cheap, reads are targeted. Tokens stay free for thinking and citing.
Source link format Varies per server. Consistent across integrations.
Error handling Generic, protocol-level. Tailored to each provider's actual failure modes.
Best fit Many different clients calling the same tool. The Drive and Slack hot paths, done well.

Two paths from question to answer.

Same question, same data, very different journey through the model's context window.

Generic MCP connector

Read big, decide later.

  1. 1. The model calls search. Back comes a list of file IDs and metadata.
  2. 2. For each candidate that looks relevant, the model fires a separate read call.
  3. 3. Each read returns the whole file — PDFs and long docs included.
  4. 4. The full file lands in the context window. If you want chunking, embedding, or relevance ranking, your client has to bolt that on itself.

Chat with Work tool layer

Triage cheap, read targeted.

  1. 1. The model calls Drive or Slack search. Back come the candidates with metadata and a one-line snippet of where your terms hit.
  2. 2. That snippet is usually enough to decide: read this one, skip that one. No tokens burned skimming files the model didn't need.
  3. 3. Read pulls the relevant section, not the whole file. Long PDFs go through a separate extraction pipeline; the text is cached once and reused.
  4. 4. Only what mattered lands in the context window. The model has room left for thinking, citing, and following up.

Background reading: MCP tools specification and OpenAI MCP connector docs.

The context window is not a junk drawer. It's a workbench. Everything on it should be there for a reason, and you should be able to say what that reason is.

Carmine Paolino

Carmine Paolino

Founder Your agent's context window is not a junk drawer

See the tool layer in practice.

Start free with Drive. Ask one question. Watch the answer come back with the source attached — and a context window that didn't have to eat the whole file.

Create your account and connect Google Drive in one step.