Skip to main content
All right — it’s Thursday morning. You get another email from Claire: Who should I call this week? I want to work the list on Friday. Can it give me, like, the top five customer accounts sliding the fastest? By Thursday afternoon, she’s back with a follow-up: Hey again, I have one more — sales leadership wants to know which region is churning hotter: West versus East. Then Friday morning it’s Claire again: Hi, sorry, last one. Board meeting on Monday — which accounts churned last quarter? Three emails in two days, and each one is a reasonable question from somebody doing her job well. Claire has a tool that answered the first question, so naturally she has more questions. The problem is your agent can’t answer any of them — yet. Just look at what you built.
A dark-themed slide titled "One Question, One Function" showing a "Churn Agent" bot icon with a red X beside it. To the right is an email from "Claire · Customer Success" asking "Who should I call this week?" with several churn-related questions listed.
Your current tool is a single function named GetCustomer that runs one fixed SQL query. That query has exactly one blank — the customer ID — and the model fills that blank. This design supports exactly one type of question: tell me about this customer.
Claire’s first email asked for the top five accounts sliding fastest — there is no customer ID in that question. So the tool had no answer. What do you do? You write another function. You add list_sharpest_drops with a SQL sorted by 30-day usage delta plus LIMIT 5, then test and deploy it to the agent’s tool list. Thursday morning fixed. CompareRegions is a more complex SQL — more tests, more deployment — and that takes Thursday afternoon. churn_last_quarter takes several parameters and its own deployment. By Friday, the board has their numbers and Claire’s happy. Your tool list grew to include:
But look at the pattern you just agreed to. Every new question becomes code that you write, test, and deploy. The model and BigQuery are fast; the slow part is you. So take a step back: Claire asked a question about data she already has access to, but the translation from plain English to SQL — the piece that actually runs the query — fell to you. Over those two days you became the bottleneck.
A slide titled "The Slow Part" showing a simple flow diagram with three blocks labeled Claire, You, and BigQuery, connected by icons for an email and a processing delay. It illustrates a slow step in the data/message flow from a person to BigQuery.
As the company grows, this problem compounds. Bluepine won’t stay this small. Departments will add agents — a sales-forecast agent, a support agent, etc. — and your churn agent isn’t the only one. Data will live in BigQuery, Databricks, Snowflake, and your CRM API. If every agent-source pair requires a handwritten tool, you get combinatorial growth.
An infographic titled "Three Agents, Four Sources" showing three agent rows (Churn, Forecast, Support) mapped to four data source columns (BigQuery, Databricks, Snowflake, CRM API) with robot icons for agents and green wrench icons indicating connections.
Use the following simple table to visualize the integration explosion and how an MCP approach reduces it: If you have n agents and m data sources, you end up with n × m integrations. Each integration brings its own authentication, bugs, and maintenance overhead. This multiplicative growth is the problem MCP exists to solve. Instead of writing one-off tools for every agent-source pair, attach a server that already speaks to your data sources. To an agent, a server tool looks exactly like the function it used to call: a name, a description, and parameters the model can fill in. The protocol stays the same; what changes is who wrote and maintains the implementation.
A slide titled "One Protocol" showing three colored app-style icons above two rounded panels. Each panel lists three fields: "name", "description", and "parameters."
Redo the math. Three agents and four data sources used to be 12 handwritten integrations. With MCP, it’s three clients and four servers — seven endpoints total — all speaking one protocol. Previously, your agent called getCustomer, which ran SQL you wrote against BigQuery. With MCP, it calls a function like execute_sql — a tool published by the MCP server (in this lesson/article, the example server is an MCP-compliant toolbox for databases).
A diagram titled "The Same Call, New Hands" showing a before-and-after workflow: originally a bot calls get_customer which queries BigQuery, while the updated flow shows the bot calling execute_sql that goes to an "MCP Toolbox" component.
And crucially: the SQL inside that call can be written by the model itself. So when Claire asks which five accounts drop fastest, the model can generate the ORDER BY and LIMIT and send it through the shared server — no new function to write, no deployment.
This pattern greatly reduces developer overhead and speeds up the agent lifecycle: new questions map to model-generated SQL delivered through a dependable, centralized server.
Using a general-purpose execute_sql endpoint lets models run arbitrary queries under your credentials. You must design server-side guards — least-privilege credentials, query validation and sandboxing, auditing, and rate limits — before giving agents broad SQL execution capability.
Someone is going to notice the increased risk — remember Marcus from Claire’s PS on Wednesday? Design your MCP servers with security and governance in mind, and you keep the agility without trading away safety. Additional references and next steps:

Watch Video