Before MCP, asking an assistant for a pricing section got you a pricing section. It was usually reasonable, occasionally excellent, and never the one your team had already agreed on. It was generated, so it drifted — different spacing, different radii, a colour close to your brand but not it.
What does MCP change in practice?#
It gives the agent a retrieval path. Instead of composing a pricing section from training data, the agent queries the library, filters by industry and platform, and returns the section your team shipped, with your tokens already bound.
- The output is reviewable because it came from a reviewed source.
- Token binding happens server-side, so the agent cannot get the brand subtly wrong.
- Filters travel with the query, so "fintech pricing, three tiers, Webflow" resolves to a handful of candidates.
- The same query engine serves the website filters, so the two can never disagree.
Why not just paste the library into context?#
Because it does not fit, and because it would not help if it did. Two thousand sections is far past any useful context budget, and a model asked to pick from two thousand undifferentiated options performs worse than one handed six good ones. Retrieval is not a workaround for context limits; it is the better design regardless.
The win is not that the agent can see more. It is that it has to choose from less.
What still needs a person#
Judgement about the brief. An agent can tell you that six pricing sections match "fintech, three tiers, regulated copy". It cannot tell you that this particular client will hate the one with the comparison table because their last agency used it. Retrieval narrows the field; it does not close it.