MCP vs SDK: when to use each for AI agents
Corbin Brown
3 min read
Use an MCP when you're chatting and exploring; use an SDK when you're repeating. An MCP (the open standard that lets an AI chat tool discover and call your apps) gives the model fresh context every time, which is perfect for a one-off question and expensive for a job you run daily. An SDK (a code library that lets a script call the same apps directly) does the job once you've figured it out, for the cost of a single call. In the video, the same workflow costs $1,132 a month through an MCP and $4.58 through an SDK. Same output.
Where the 250x comes from
Through the MCP, the model made 8 tool calls and burned 145,000 tokens (the units AI usage is billed in) to finish the workflow, because it had to read the tool descriptions, decide what to call, look at each result, and reason about the next step. Through the SDK, the same work was 1 call and 308 tokens: the reasoning had already been done, once, by a human and written down as a script. You pay for thinking every time with an MCP. You pay for it once with an SDK.
The decision in one question
Have I done this exact thing before, and will I do it again? If no, MCP: let the model explore, that's what it's for. If yes, promote the workflow to an SDK script. The pattern that works is to prototype in chat with the MCP until the steps are stable, then ask your agent to turn that exact sequence into a script that uses the SDK. The chat was the design phase; the script is the product.
Signs a workflow is ready to promote
- You've run it more than three times and the steps didn't change.
- It runs on a schedule, or someone else triggers it, rather than you typing in a chat.
- The cost line for it is the one you notice on the monthly bill.
- The output needs to be identical every time. Models vary; scripts don't.
FAQ
Isn't an SDK just an API?
Close. An API is the door a service exposes; an SDK is the pre-built code library that knocks on it for you, with sign-in and error handling included. You could call the API raw, but the SDK is the version that saves an afternoon.
So should I stop using MCPs?
No. MCPs are the right tool for the part of the work that's still a conversation. The mistake is leaving a settled, repeated workflow inside the MCP where it re-pays the thinking cost every run. Prototype with the MCP, ship with the SDK.