DEV Community: Murali Gour

Talking to Salesforce Through MCP: How We Solved the Context Bloat Problem

Murali Gour — Tue, 11 Aug 2026 12:56:20 +0000

Salesforce has a huge API surface. Objects, fields, flows, custom actions — it goes deep. When we started building our Salesforce MCP integration on top of it, we ran into a design conundrum.

Option A: Expose a handful of generic tools.

Pro: The agent avoids context bloat.
Con: You lose the granular control, predictable outputs, and security enforcement that enterprise workflows actually need.

Option B: Expose 100s of specific tools, one per object and one per action.

Pro: You get the precision and auditability you need.
Con: The agent's context window fills up with schemas before it has done any real work.

We built DataGrout’s Conduit SDK around the idea that you shouldn’t have to pick one or the other. This post walks through the design we used and what tradeoffs you still need to account for.

The trade-off: granularity vs. context efficiency

A standard MCP call to tools/list gets back every tool the server exposes, and the model reasons over all of it before deciding what to call. That’s not an issue if your server has 10 tools. But if you’re running multi-system enterprise workflows where Salesforce, QuickBooks, and other connected systems are all wired to the same agent, you’re looking at a combined tool catalog with 100s of schemas that load into context on every single turn.

Our answer in Conduit was to collapse the entire tool surface into two entry points:

from datagrout.conduit import Client

async with Client("https://gateway.datagrout.ai/servers/{uuid}/mcp") as client:

tools = await client.list_tools()

# -> [discovery.discover, discovery.perform]

Instead of the model scanning 100s of schemas, it describes what it wants in plain language and a server-side discovery step resolves that to the right tool:

results = await client.discover(query="find leads created this week with no owner", limit=5)

This moves tool selection out of the LLM's context entirely. The upside is smaller prompts and cheaper calls. The tradeoff is that you’re now trusting a semantic matching step to pick the right tool. For read operations that’s fine. For anything destructive, test your edge cases before relying on it in production.

The granular tools still exist underneath. They give you the control and governance layer. Conduit's intelligence layer just makes sure they don’t all land in context at once.

Calling Salesforce tools directly

If you already know which tool you need, skip discovery and call it directly. Tools are namespaced by integration and version:

result = await client.call_tool("salesforce@1/get_lead@1", {"id": "00Q5f000003abcXYZ"})

We expose the same call shape across all five SDKs: Python, TypeScript, Rust, Elixir, and Ruby. The choice of language comes down to whatever your agent runtime already uses.

Chaining actions across systems

Single tool calls are easy. Where Conduit makes the biggest difference is multi-step workflows that span systems. The flow.run() primitive lets you chain tool calls and pass output from one step directly into the next:

outcome = await client.flow.run(plan=[

{"tool": "salesforce@1/get_lead@1", "args": {"id": "00Q5f000003abcXYZ"}},

{"tool": "quickbooks@1/create_invoice@1", "args": {"$prev.result": True}},

])

Each step's output is in the next step's args. For example, you can look up a lead in Salesforce, which can then feed directly into an invoice creation in QuickBooks. Two completely separate systems in one agent call.

For anything with financial or irreversible side effects, insert an approval gate before the write happens:

await client.flow.request_approval(
    action="create invoice from lead 00Q5f000003abcXYZ",
    reason="First invoice for this account, needs manual sign-off"
)

We built this because giving an agent the keys to take financial actions unsupervised introduces risks that aren’t worth taking for enterprise teams. At least not yet. The approval gate keeps a human in the loop without breaking the workflow entirely.

Authentication: built for agents that run unattended

Conduit supports bearer tokens, OAuth 2.1 client credentials, and mTLS across all five SDKs. The tool calls look identical regardless of which auth method you pick.

The mTLS path is the one we recommend for production agents that run unattended for extended periods:

client = await Client.bootstrap_identity(

url="https://gateway.datagrout.ai/servers/{uuid}/mcp",

auth_token="your-access-token",

name="my-agent",

)

# subsequent runs auto-discover the cert from ~/.conduit/

# no token refresh logic needed

The private key is generated locally and never leaves your machine. Our CA signs a certificate binding the public key to a named agent identity. This matters in practice because bearer tokens in env vars are the thing that gets rotated incorrectly at 2 am and takes down your production agent. With mTLS, you don’t have to maintain refresh logic and you’re not leaving a long-lived secret sitting in an environment variable.

Try it yourself

Check out Conduit SDK on GitHub and share any feedback. There are installation instructions for all five languages, and the quick start gets you to a working Salesforce tool call in under five minutes. If it’s useful, give it a star so others can discover it.

Why your AI agent should never do its own math

Murali Gour — Thu, 06 Aug 2026 14:23:33 +0000

I want to talk about a problem that comes up constantly in production AI agent systems, and gets far less attention than it deserves.

LLMs are bad at math. Not always, not catastrophically, but unreliably enough that you should not be betting your agent's output on it.

This is not a hot take. It is a well-documented limitation. Models drift on floating point operations, produce plausible-but-wrong statistical summaries, and give you different answers to the same calculation across runs. For exploratory work, this is fine. For agents making decisions based on numeric data, it is a real problem.

The usual answer and why it is incomplete

Most teams reach for a code execution tool. You give the agent access to a Python sandbox, and it writes and runs the calculation itself.

This works for simple cases. It gets messy when:

You need reproducible results across agent runs (different seeds, non-deterministic execution)
The math is part of a longer pipeline where output shape matters (the regression result needs to go directly into a chart tool)
You are working with large arrays that you do not want to re-send through the model context on every step
You need the operation to be verifiable, not just correct-looking

What we built

DataGrout Math is a set of MCP tools that cover the numeric operations agents actually need. Twelve tools across three categories.

Generation

math.range — evenly-spaced sequences from start to stop with exact step computation to avoid cumulative float drift. Up to 10,000 values per call.

math.linspace — generate exactly N points between two bounds, equivalent to NumPy's linspace.

math.sequence — named mathematical sequences: arithmetic, geometric, Fibonacci, triangular, square, prime, and powers.

math.sample — draw samples from uniform, normal, or exponential distributions. Pass a seed for reproducible output across runs.

math.interpolate — apply lerp, inverse lerp, clamp, remap, smoothstep, smootherstep, and with 12 easings + 6 modes (lerp, inverse_lerp, clamp, remap, smoothstep, smootherstep) = 18 modes

Analysis

math.describe — full descriptive statistics: count, mean, median, standard deviation, variance, min, max, sum, range, skewness, percentiles (p5 through p95), and a binned histogram. Up to 100,000 values per call.

math.window — sliding window operations: moving average, moving sum, cumulative sum, first differences, percent change, lag, and EWMA with configurable alpha.

math.normalize — z-score, min-max, and percentile rank normalization. Returns both normalized values and original values in records for comparison charting.

math.outliers — IQR and z-score outlier detection. Returns outlier indices, threshold bounds, a clean array with outliers removed, and per-value boolean flags.

math.rank — ordinal, dense, average, and percentile ranking with ascending or descending order.

Modeling

math.correlate — Pearson and Spearman correlation with r-squared, interpretation labels (strong positive, weak negative, etc.), and paired records for scatter plot visualization.

math.trend — fit linear, polynomial (degree 2 through 5), exponential, and logarithmic regressions. Returns coefficients, r-squared, direction label, equation string, fitted values for overlay charting, and optional forward forecast points.

How it fits into an agent pipeline

Every tool returns two output shapes: a values array and a records array. This is intentional.

values feeds into other math tools. records feeds directly into prism.chart for visualization, no reshaping required.

Tools also accept a cache_ref parameter. If you ran a Data or Frame tool in a previous step and got a cache reference back, you pass that reference directly to a math tool. The array never goes back through the LLM context. This matters when you are working with datasets of any real size.

Every response includes a deterministic receipt under _meta.datagrout. The gateway verifies the result is reproducible. Same inputs always produce same outputs.

All tools are versioned at data-grout@1/math.*@1. You can pin your agent instructions to a specific version and they will not break when we ship updates.

A concrete example

Here is a workflow that shows how these tools chain together.

An agent pulls revenue records from a Salesforce integration. It passes the cache_ref to math.outliers to detect anomalous months using IQR. It takes the clean_values output and passes it to math.trend with a 3-step forecast. It pipes the fitted records from trend into prism.chart with the original values overlaid. The entire numeric pipeline runs without a single LLM token spent on arithmetic.

That is the point. The agent's cognition is reserved for reasoning about the results, not computing them.

Getting started

DataGrout Math is available through the DataGrout MCP gateway. Connect your agent and call any tool at DataGrout.

Full parameter reference and examples are in the documentation at library.datagrout.ai/math-tools.

We launched on Product Hunt today if you want to follow along or leave feedback.

We Built Deterministic JSON Ops for AI Agents — The Problem It Solves

Murali Gour — Thu, 18 Jun 2026 11:37:06 +0000

Every AI agent that calls an external API hits the same wall.

The response comes back as raw JSON, deeply nested, verbose, full of fields the agent doesn't need. Before the agent can reason over it or take any action, someone has to filter it, reshape it, maybe merge it with another payload.

Most teams solve this one of three ways. They dump the raw JSON into the context window and let the LLM figure it out. They spin up a Python sidecar. Or they make an extra round-trip to a data service. None of these scale.

We built DataGrout Data to eliminate all three.

What Data does

Data is a suite of deterministic JSON manipulation tools exposed as MCP tools, callable directly by any AI agent:

→ data.filter({ payload, where: [{ field: "status", op: "eq", value: "active" }] })
→ data.sort({ payload: "$prev.records", by: "created_at", dir: "desc" })
→ data.take({ payload: "$prev.records", n: 50 })

No Python. No extra runtime. Pure deterministic output the agent can immediately act on.

The full operation set

data.filter — declarative filtering with 10+ operators (eq, neq, gte, lte, contains, starts_with, is_null...)
data.sort — multi-field sorting with per-field direction control
data.aggregate — reduce a field to a sum / mean / min / max / count.
data.merge — combine two JSON datasets on a shared field
data.flatten — simplify deeply nested payloads in one pass
data.map — split large arrays into individual items for parallel processing

Why deterministic matters

Every Data operation is pure, no AI generation touches the transformation layer. The agent decides what to do, Data executes it exactly. This eliminates token waste and hallucination risk on the data layer entirely.

How it handles large datasets

Data accepts cache_ref outputs, so agents can chain operations on large payloads without retransmitting the full dataset at each step. The output of data.filter passes as a ref into data.sort — not as raw JSON.

Where it fits in the DataGrout suite

Data handles raw JSON payloads from API responses. Frame handles columnar tabular data. Together they cover the two most common data shapes agents encounter in enterprise workflows.

Launched on Product Hunt today, would love your support and feedback!

👉 datagrout.ai/tools/data

We built columnar data ops for AI agents — here's why and how

Murali Gour — Thu, 04 Jun 2026 09:04:23 +0000

If you've built an AI agent that touches real enterprise data, you've probably hit this wall.

Your agent pulls 2,000 records from Salesforce. Now what? The model can't reliably filter, sort, or group 2,000 rows inside its context window. You don't want to dump all of it as raw JSON. And spinning up a Python runtime just to run a pandas filter feels like overkill for what should be a simple operation.

This is the problem we kept running into at DataGrout. So we built Frame.

What is Frame?

Frame is a suite of columnar data operations exposed as MCP tools — callable directly by any AI agent without a Python runtime, extra infrastructure, or round-trips to an analytics API.

Here's what it looks like in practice. An agent receiving tabular records from a CRM can do this in a single workflow step:

frame.filter({ payload, where: [{ field: "status", op: "eq", value: "active" }] })
→ frame.sort({ payload: "$filter.records", by: [{ field: "revenue", dir: "desc" }] })
→ frame.slice({ payload: "$sort.records", offset: 0, limit: 50 })

No Python. No pandas. No external call. Pure deterministic output the agent can immediately act on.

The full operation set

frame.filter — declarative row filtering with 10+ operators (eq, neq, gte, lte, contains, starts_with, is_null...)
frame.sort — multi-column sorting with per-field direction control
frame.group — aggregate by key, compute counts, sums, averages
frame.pivot — reshape rows into columns for cross-tab analysis
frame.join — merge two datasets on a shared key field
frame.slice — page or window over large records
frame.select — keep, drop, or rename columns in one pass
Frame.pluck —extract one column into a flat array, dot-notation supported

Why deterministic matters

One of the core design decisions with Frame was making every operation pure and deterministic. No AI generation touches the data transformation layer. The agent decides what to do, Frame executes it exactly. This eliminates a whole class of hallucination risk that comes with asking an LLM to reshape data directly.

Handling large datasets

Frame accepts cache_ref outputs from previous tool calls, so agents can operate on large paginated datasets without retransmitting the full payload each time. This was critical for production workflows where data sets run into tens of thousands of rows.

How it composes

Frame tools chain together natively via flow.into inside DataGrout workflows. The output of frame.filter feeds directly into frame.sort without any manual wiring. This composability is what makes it genuinely useful in multi-step agent workflows rather than just as a standalone utility.

Where we are today

Frame is live at datagrout.ai/tools/frame and We launched on Product Hunt today — would appreciate your support if this is useful to you!
We're actively building out the operation set. What data operations are you missing in your agent workflows? Drop them in the comments — we're reading everything.