Why are top engineers DITCHING MCP Servers? (3 PROVEN Solutions)

What's up, engineers? Indie Dev Dan

here. Once again, my MCP server just ate

10,000 tokens before my agent even

started working. That's 5% of my agent's

context window gone, and my Kshi

prediction market MCP server isn't even

that large. Stack up two or three more

MCP servers, and I'll be bleeding 20%

plus context in no time. This isn't new

but what is new are these three proven

alternatives to MCP servers. You know

about skills. We're going to break down

two additional approaches you can use to

connect your agents to external tools

without torching your contact window

while maintaining control. These

approaches are being used by some of the

top leading companies in the agent space

like Anthropic and by some of the top

engineers who use agent coding tools

every single day. We'll break down when

to use each and their tradeoffs so your

agent can ship for hours not minutes

with focus contacts. Let's go beyond

MCP.

So the first version of this is of

course the classic MCP server. The great

part about this is that your MCP server

manages everything when it comes to the

connection to your external data source.

So here we have a Haiku model. We don't

need sonnet. That's going to be overkill

for this specific problem. What does

this MCP server do? This is a Kshi

prediction markets MCP server. This

gives us a gentic access to the Koshi

prediction markets betting platform. If

we type MCP, you can see we have that KI

server connected. Let's go ahead and

search some prediction markets. We'll

type KI search markets OpenAI achieves

AGI. So this is one market that we can

access. And you can see our agent diving

into the information with the search

markets tool. And we can of course open

up that market right here. And we can

see this when will open AAI achieve AGI.

You can see here probabilities are very

very low before 2030 mark. There's a lot

of information missing from this UI. We

can of course have our agent tap into

that for us. Right? One of the key value

propositions of agents is that they can

manipulate and crud information on your

behalf faster than ever. So here's a

great breakdown, right? Get recent

trades and get the order book for this

market. I want to understand this data

at a deeper level. Haiku is doing a

great job moving at light speed for us

breaking down the markets here. Here's

the order book, all the shares, total

volume on each side, recent trades

placed. Fantastic. These agents are

really powerful at understanding

information. So, we can say something

like this. Summarize bets and market

sentiment in a concise table. I just

want to showcase what this MCP server

can do. This is a readonly couchy

marketplace MCP server. Clean sentiment

analysis. Bearish by 2029. And then we

still only have a 43% chance. So the

market is telling us with their dollars

that by 2029 we expect only a 43% chance

that OpenAI achieves whatever AGI is.

The devil's always in the details here

right? OpenAI has to announce that

they've achieved AGI. Who knows what AGI

is? No one knows anymore. But this is

the power of this MCP server, right? So

we can understand the markets at light

speed. And here we're doing it with a

classic MCP server. you know exactly how

this works. It's a great tool. It's a

great resource for connecting your agent

to services. But the big problem here

is, of course, slashcontext right away.

10k tokens torched for my small, you

know, relatively well-built MCP server.

So, let's move beyond MCP server with

three new approaches where we can get

some of the value without torching our

agents most important resource. And

these approaches trade off complexity

for control. The theme though is the

same. Use raw code as tools.

For our next approach, we're using the

CLI. So here we prompt our agent and we

give our agent a specific prompt that

teaches them how to use a CLI, a set of

functions that they can then call to

access the thing we're trying to

interact with. So how does a CLI first

approach work? Let's open up a brand new

agent. And you can see here I've dropped

the MCP server. So now we're just

running our cheap fast IQ model. If we

drop MCP, there's nothing there. How

does this work? If we don't have an MCP

server, how can we enable and teach our

agents how to use a specific set of

tools? We can do this in many ways, but

it all boils down to just context model

prompt and tools. Prime Ky CLI tools

right? Our fast agent is just going to

read these two files, a readme and a

CLI. Now, our agent has summarized how

to use this tool exactly. It understands

the CLI. It understands its settings.

It's broken down the common workflows.

And if we scroll up, you can see it

understands exactly what's going on. So

what exactly does this file look like?

Inside of the Beyond MCP server codebase

where we're breaking down each approach.

If we look for this prime couch CLI

tools, you can see a concise 25line

prompt that tells our agent how to use

these tools. You can see the key line

here is in our workflow step read only

these two. The readme of our second app

and the CLI we're on the report section

as you work with the user call the right

tools to get the data you need. So let's

look at another market. We'll search

trillionaire and I'll prefix this with

market search. So check this out.

Instead of running an MCP tool, our

agent is running a CLI command. Let's

scroll up so we can see that we have

taught our agent how to use the CLI

instead of an MCP server. Now, there's a

little more upfront cost here, right? We

are prompt engineering how to use this

MCP server, but as a reward, we get to

fully control everything the agent can

and cannot do. MCP just says, "Here's a

bunch of tools. Here's all the

descriptions. Here's all the context

you're going to need to consume every

time you boot the agent up." Here we're

in full control over everything. Here's

the readme. Here's the CLI. This is what

you should do. And then we said do not

read, any, other, Python, files., All right.

So this is important. We're saying don't

consume any additional context. This is

all you need. We can do the exact same

work, right? Market search trillionaire.

We're pulling up some of the

trillionaire couch marketplaces, right?

Who's going to be the first

trillionaire? And then we have the Elon

Musk trillionaire market. We're betting

on when he'll be a trillionaire. Great

summary here. Highest conviction. Musk

by 2030. We have the most liquid, most

traded. Of course, we can pull up these

markets here and see them at a glance.

Betting on on Elon is pretty high here.

We have this market and then we also

have who else, you know, will be the

first trillionaire. You can see a lot of

sentiment around Elon, but not uh so

much anyone else, right? So, very

interesting stuff there. We can push

this further. Summarize bets and market

sentiment. This is something that I keep

prompting. I need to turn this into a

reasonable prompt. sentiment for Elon

and first trillionaire markets. So our

agent is going to do the, you know

exactly what you would expect to kind of

pull this information together and then

we can set up one more prompt. Quick

simple summary. These markets are giving

us information. This is a really

interesting thing about these betting

markets, these emerging poly market cali

you can use this in two ways, right? As

Vitalic said, the creator of Ethereum

you know, there's two ways to use these

betting markets. It's a betting site for

some people and you know for those

looking to make high return on

investment decisions and figure out

where to bet their time and understand

events happening in the world. This is

also a news site, right? It's a place of

finding valuable information and it

helps us understand the future before it

occurs because people are placing their

bets, right? Vitalic calls this info

finance. You can use these betting

platforms to understand incentives

before things happen. So very

interesting way to think about betting

markets and it's a great way to get an

edge with agents. These agents can

understand this information faster and

better and you can get multiple

perspectives on this data. So just by

looking at these betting markets, we can

see here that by 2030 the market becomes

bullish that Elon is going to be a

trillionaire. Some of these other

prediction markets are actually really

interesting, right? Like when will

OpenAI achieves AGI? This actually tells

you the sentiment of the market around

OpenAI achieving and pushing forward and

becoming a great valuable company.

That's the information underneath the

data, but only a 43% chance by 2030.

Very interesting. Cool stuff here

right? And you can continue to prompt

your agent however you want. Web search

2025, the net worth, uh, Jensen, Elon

and Sam, what market cap would their

companies need to make them

trillionaire? This is all thanks to

agents helping us move super super fast

and understand data. But focusing back

in on the CLI. If we open up the code

here while our agent works. So we have

the CLI and here's the important part.

Right? In the CLI, we just showcase all

of the functions, right? And notice how

via the CLI syntax, click, typer

whatever you want to use, our agent can

easily see how this works. As long as

you're not using a super new tool that

the agent has no idea about, it's pretty

straightforward. Right? Here's an

option. It's called D-limit default.

Here's how you can use it. We

effectively have all the capabilities of

MCP server with raw code. And this is

something that Mario mentions, pretty

top tier engineer covering some hot

topics. He argues, what if you don't

need MCP at all? And the way he does it

is he just sets up a prompt as we're

doing here through a readme file and he

basically just tells the agent, you

know, look at this. Here are all the

tools you can use. They're all in a

specific file. We're going to break down

this approach in just a second. And it's

very similar to the CLI, but you get

improved context management. The

benefits here are are really obvious

here, right? You can pull in the readme

whenever you need. So for this agent, we

ran our prime calcium CLI tools. We only

activate this. We only set our agent up

when we need it. Okay? When we need the

specific tool set. So this is really

powerful. It's a lot more dynamic than

MCP servers. Not a ton to go over here.

I think the most interesting thing here

though is that you know Sam Alman

currently reported worth2 billion while

Elon at 500 billion already and Jensen

he's about 175 billion and then we get a

breakdown of their their companies and

how much more revenue they would need

right to really hit these marks. So, you

know, Jensen would need 450% increase

not that much, but Elon only 100% away

between all of his assets. And Sam

actually a lot further away, not as as

wealthy as a lot of people think.

Important thing to mention here, I

missed this at the start. If we clear

this agent, restart it, and we run this

prime command, only reading these two

files. Okay. Uh, we're going to conserve

our context window. If we hit /context

you'll see here our tokens are down from

that 10% down to just, you know, 5.6%.

All right,, so, we've, saved, roughly, 4%

context window with our CLI approach.

Very powerful, but we can push this

further. Let me show you the scriptbased

approach.

So scripts look a lot like skills. In

particular here, we have that same setup

where you prompt your agent with a

specific prompt, right? A prime prompt.

You're preparing your agent for

something just like you would set

yourself up for a great day in the

morning. So, you're priming about

specific files. But the trick here is is

that you want to use progressive

disclosure. This is something that

Enthropic mentions inside of their blog

when they're talking about this using

direct tool calls. Scale better by

writing code to tool calls instead. Now

interestingly here, Enthropic actually

ends up calling the MCP server under the

hood. I think Mario and I would argue

that you don't actually need to go that

far. You can just hand them the script

or the tools and have them run that

directly. The only con there is of

course you have to build out that tool

and the interaction versus rely on the

existing MCP server that exists. So

what is this scripts approach? So, if we

boot up our agent here and we run clear

and let's just go ahead and start from

scratch so it's super clear. So we have

the ha coup model here and then we're

going to, run, slash, file, system, scripts.

So again we're priming our agent with a

specific set of information. Okay. So

same deal and we can of course look at

this prompt. There you go. Okay. So it's

already finished. This model is so fast.

This time we only read a read me. And

check this out. Our agent understands

when to use each script. Okay. So this

isn't preloaded in the context. It just

understands at a high level when to use

each script. We effectively have a

condition mapped to files. This is a

powerful agentic data structure that you

can use to activate or ignore context.

Okay, so you know, check this out. This

is crazy. /context less than 1% just

under 2K context. Here's the key part. I

will not read scripts themselves

unless-help doesn't provide information

needed. We are prompt engineering this

outcome. A lot of engineers are super

obsessed with context engineering.

Everyone's jumping on the context train.

Even before context comes prompt

engineering. This is still a critical

skill. In fact, it is the critical skill

for engineers in 2025 and beyond. The

prompt shows up before the context gets

in your context window. We have just

prompt engineered out 10,000 tokens that

don't show up via a default MCP server

or even our CLI script. Right? Our CLI

script got it down by say 50 60%. But

our scriptbased approach is taking it

all the way down to let's say 10% of the

original. All right. So, how does this

work? We have again another great prompt

with a typical structure that we use on

the channel all the time. Make sure you

subscribe so you don't miss out. We're

breaking our prompt down piece by piece.

Every section has a specific purpose.

And there are some other sections here

we just didn't need, so we didn't add

them. Here's the important part. Do not

read the scripts themselves. Then we

have d-help where we explain that as you

work through each script you use d-help

to understand how to use it. Now here's

a cool part right if we look in this

directory. So this is our apps 3 file

system. Every single script is of course

a self-contained script. If we open up

the read me you can see exactly why we

had our agent read this file. These are

file system scripts, right? Isolated

single file scripts that you can use uh

on their own or together, right? And we

have conditions on each when to use each

file. And that's it, right? A 58 line

readme file. Um we could have put this

in the prompt, but having it here in the

readme is fine as well. And now we can

just, prompt, as, usual., All right,, so

business as usual. Let's go ahead and

have our agent actually do some work for

us. Let's look at another prediction

market on Kelsey. Let's run something

like this. Koshi market search. I want

to understand the government shutdown.

Okay. What's going on around the

government shutdown? How long will this

last? So check this out, right? UV run

app 3 file system scripts search-json.

There's the search. There's the result.

This is effectively the same thing as

the MCP server as the CLI server. And

that's the big kicker here, right? All

these approaches help you solve the same

problem. Give your agent access to

tools. The question is how you do that

and what does it cost? In the

scriptbased approach, you know, we have

dedicated single file scripts, right? If

we open up our search, you can see it's

self-contained. We're using Astral UV.

Shout out Astral. They are the best

Python dependency manager. The industry

is really picking up on this finally.

We've been using it for over a year now

because we can do cracked stuff like

this. Python single file scripts all

over the place with dependencies

declared at the top, right? But each one

of these scripts is their own world of

code. Of course, the trade-off here is

we have code duplication all over the

place. But that's fine. We're willing to

pay that price because it makes our

agents more effective. When you have

less garbage context, your agent can

perform better. So, here's this market.

Basically, we're betting on how long

will the government shutdown last.

There's no value. There's no information

in a bet that's 99% certain, really even

90% certain. But there is more

information here in this, you know, 66

63% bet. And we can pull up the full bet

here. How long will this last? You can

see the interesting places are this 45

to 52 mark. Right? This is where the

interesting bets are actually happening.

This is where we can actually get real

information. If we want to predict how

long, this, will, actually, last,, all right,

we can say something like summarize

bets. When can we expect the government

shutdown to end? So based on the bets

again, based on the information

available through people placing real

bets on these markets, we can kind of

understand the future in a more uh

deeper way. We're pretty much guaranteed

that it'll last longer than 39 days. And

this is since October 1st, by the way.

Um so longer than 39 days, longer than

40, but then the probability really

drops off. Based on this information, we

can see that, you know, roughly 40 to 50

days is the consensus. expected end date

based on the probabilities 18th to 20th

based on again these market bets. So

really interesting way to actually use

these markets is information about a

future state in the world. This is the

huge advantage of using these scripts

and this is something that Mario points

out here. I'll of course add all these

links into the description. Benchmarks

have shown that there's no degradation

in quality by going right for scripts

going right for CLI, right? basically

handing your agent code versus giving

them an MCP server. Now, Anthropic has a

slightly interesting approach to this.

They have this uh call MCP tool approach

where they basically recommend that you

wrap and expose specific functionality

in a CLI or individual scripts, right?

Get document and then you call the MCP

server underneath. I think you can just

cut the MCP server out completely if

you're going to script it out yourself.

They mention here that you know the big

benefit is progressive disclosure. Very

interestingly here you can see we're

getting that progressive disclosure by

ourselves by prompt engineering and it's

not a complex prompt, right? It really

is not a complex prompt. We're saying

when to use every single file and then

we're saying don't read and here's a

couple tools you can use, a couple ways

you can understand every single script

without blowing up your context window.

I like to call this incremental context.

We'll talk about the trails of all this

in a second. There's one more way to

manage your context. It is of course

with skills.

Skills look like this. They look very

similar to actually scripting things

out. The big key difference between

skills and scripts is how you invoke

them. So with scripts, we have to have a

priming prompt to kind of fire things

off. And with the skill, the prime

prompt is the skill.md file, right? So

you still have to set up the prompt that

kicks things off and that lets your

agent understand the tools available

but how you do it is just a little bit

different, right? And that's a key thing

to mention here, right? I talk about

this a lot on the channel. Don't give

away your understanding of how to write

great prompts because at the end of the

day, everything is just the core for

context, model, prompt, and tools

right? every feature just builds on top

of your agents context model prompt and

tools., All right,, so, the, interesting

thing is where and how the tools are

discovered, right? And that's what we're

really focused on here. So if we close

all of our approaches and if we open up

apps skill, you can see all we have here

is acloud file. And so of course we can

have our agent look at that file. We can

close this. So we need to cd apps for

then we boot up haiku again /mcp. You

can see nothing there. We can of course

do slashcontext and here's the best part

about skills. They have progressive

disclosure. All our agent sees here is

the definition of our skill which is

just at the top. So this is all the

context being consumed right now by our

agent. So we can prompt something like

this. Khi market search top LLM. And so

this is going to kick off the skill.

There it is. Cali markets. We're using

skills and we're using the scripts

inside of our skill. So if you look at

the structure here, you can see same

thing as our third approach, right, with

the file system scripts. The only

difference is that we've embedded, we've

bundled all the scripts into the skills

directory. Ky markets only has skill.md

and then it has all the scripts it needs

to run, right? So it's self-contained

it's isolated. This is a powerful

approach to giving your agents specific

tools without building an MCP server

right? These are MCP server

alternatives. So, you can see a very

similar structure here to our scripts.

Calcy market instructions. There's that

d--help. All of our scripts are

self-contained and they're useful and

informative for agents. If we just open

up a random one here, you can see

exactly the detail we're putting into

this. The agent doesn't even need to

look at the top of the file. But we have

all this code self-contained in a single

file script. And our skill is telling

our agent when to use each. You can see

here that it has searched, right? Ran a

couple searches here. And now it has our

top language model by the end of the

year and we have early top ranking

there. And right so we can go ahead and

open this up. You can see Gemini is

hugely biased here. There's a lot of

information missing from this. Let's go

ahead and open this bet up. Best AI end

of year. Probably you're raising

eyebrows already. We we know generally

that Gemini is not the best model. So

why is this true? Again, the devil's

always in the details. It's looking at a

single benchmark here. It's not just

looking at this benchmark which tells a

very different story. Cloud models are

also tied for first place. But they have

this remove style control on. You really

have to understand the details in these

betting markets to understand what it's

really about. But you can see here

there's a lot of specific settings that

change the actual leaderboard. So

anyway, you know, we can see the bets

here and of course we can have our agent

summarize and market sentiment, right?

Same deal. And it's kind of already done

that for us here, right? You can see

here early top rankings. Not a lot of

volume here though. Overwhelming

consensus. Everyone's saying Gemini is

going to dominate this leaderboard. We

have a skill-based approach to accessing

and running tools through scripts. Now

to be super clear here, your skill could

also be a CLI. Your skill could call

right to the API endpoints. So, instead

of these skills here, we could have

additional markdown files that just

detail how to run these commands

directly via bash and curl. If our

endpoint doesn't require a lot of, you

know, security or authentication, there

are many approaches you can take when

you're building out your custom skills

and your file system scripts, right? You

can do anything under the sun, right?

But that leads us to the tradeoffs of

each one of these approaches to giving

your agents tools.

Everything has trade-offs, right? It's

not just that we want to go beyond MCP

and that MCP is bad and you should never

use MCP. That's almost never the case

with engineering. Everything has

trade-offs. There's no one winner takes

all approach. There are options and

tradeoffs., All right., So,, for, instance,

who's invoking this? Is this agent

invoked with MCP? Yes. CLI scripts? No.

You need to run a slash command to set

your agent up and then you can prompt

it. Right. With skills, this just

happens automatically. Context window

consumption. Of course, this is the big

winner here for CLI scripts and skills

and MCP is the big loser. Especially if

you're using external MCP servers. You

have no control over this.

Customizability, no for MCP server

unless you own it. And then CLI scripts

skills, of course, you have full control

over this because you own the CLI, the

scripts, and the skill. Portability

super low for MCP, higher for CLI, but

you get even more portability out of

your scripts and your skills. Why is

that? It's because your skill is just a

single directory. So, just copy this

entire directory. Your scripts have even

higher portability, right? Because it's

just a single file. I can literally just

copy all the content in this file, paste

it to you, and you could run the code.

Composability is interesting. All of

these are composable. The kind of key

thing to mention here is that you need

to build out local prompts, sub aents

system prompts for CLI scripts, and

skills that are always going to be kind

of separated from the actual core code.

And this is where MCP wins because with

your MCP servers, there are a bunch of

features that frankly engineers

completely gloss over. Everyone thinks

it's just for tools, which yes, tools

are the most powerful piece of the MCP

server. But if we hop down to the

feature set here, you can see tools

resources prompts elicitation

completion, sampling. There's tons of

features people miss in MCP server all

the time, right? Simplicity super high.

And then things get a little more

complex here for CLI, scripts, and

skills cuz you need to manage and roll

everything out yourself. Obviously, the

trade-off there is that you get more

customizability, and, control., All right,

engineering investment kind of following

that exact same vein with simplicity.

The great part about MCP servers is that

if it's an external MCP server, you're

just done. They have everything done for

you. Just use the tools and get running

right away. Right? This is why MCP is so

great. It's standard. It's open- source.

No one controls this. Right? Skills are

very different. This is clawed ecosystem

lockin., All right., Let's, be, super, clear

about that. It's great. Uh there's a lot

you can do with it, but it is clawed

ecosystem lockin. Okay. On the other

hand, CLI and scripts, you're in full

control of these. Okay? So, you can do

whatever you want with these. You can

share them however you like. And it's

relatively simple to set this up and

maintain this. So, these are the key

differences you'll want to know. So, how

am I using all of these different

approaches? There are trade-offs across

all these. Here's how I like to think

about this, right? So, we have the tool

belt, access layer, MCP, you can use

scripts, CLI, and you can use skills.

Here's my approach, and this is what I

recommend to engineers as well. If

you're using external tools, 80% of the

time, just use MCP servers. Don't think

about it. Don't waste your time trying

to reinvent the wheel. It's just simple

to get started and running with this.

All right, but 50% of the time or 15% of

the time, you should dial in to a CLI.

And you do this if you need to modify

extend, specifically control like tools

and you can control here as well. When

you're using external tools

specifically, so you don't own these.

The the problem here by jumping down to

the CLI level is that you need to either

interface into the MCP server via code

or you need to build out the MCP server

again as a CLI. So I don't do this often

but when I do I go for CLI and then 5%

remaining the time I go for scripts or

skills and I do this only if I need

context preservation because this is

really the value ad of scripts or skills

right it's the progressive disclosure

right as anthropic mentions you get this

progressive disclosure where you give

your agent just a little bit of

information because very rarely are you

actually using every single tool every

single time. Right? If we dial back up a

couple directories here and we hop into

our MCP server, right? MCP enter inter

enter interview, tools., There, are, 13

tools here. Are you really using all 13

tools every single time? The answer is

no. Very clearly the answer is no. So

you can use progressive disclosure with

scripts or skills to just see and use

the tools you need for that one

instance, right? And you can save a ton

of context with a single MCP server. No

one really cares, right? even at the

beginning, you know, chewing up

slashcontext, you know, chewing up this

5%, it's fine. The problem is when you

stack up two or three more larger ones

and 20% of my context window is gone.

That's a problem. And so when that

becomes a problem, you can push to CLI

and you can control tools and context.

And if that's still a problem, you can

go all the way to script or skills. Now

for new tools, uh the approach is quite

different and you can see this inside

this codebase. So let me just draw this

up first and then I'll show you exactly

what I mean. So 80% of the time I just

use CLI, right? I do CLI and then I give

a prompt and it's use a prime prompt to

set my agent up with how to use the

tools, right? And this is as simple as

this. This isn't complicated, right? I

know some engineers always think things

are overengineered and things are

complicated. This is not hard at all.

Okay, look at what we're doing here.

It's a basic prompt. We have some a few

instructions and then we have a dead

simple three-step workflow. read just

these files, run the report section, and

then as you work, call the right tools.

Step three here really isn't even

necessary., All right?, I'm, just, being

super clear with my agent. And then I'm

having it report it back to me to add

more weight to the tokens. Okay? And so

what's happening here, it's simple. I'm

telling my agent how to use these tools

by showing it the exact file. That's it.

80% of the time, I just use this. Now

the nice part is is that CLI works for

you, your team, and your agents. The

trifecta can be met here. You're not

just building for you. You're not

building for your team. You're building

for you, your team, and your agents. And

CLI gets you all three out of the box. I

will push, you know, 10% of the time I

will wrap MCP server. So why do I do

this? I do this when I need multiple

agents at scale and don't want to focus

on the context. Usually the MCP server

problem isn't a problem at all if you're

using dedicated focused onepurpose

agents., All right,, this, is, something

that we talk about in tactical agent

coding. You can sidestep every single

context engineering problem by just

focusing your agents on one problem and

then you delete them when they're done.

All right,, but, sometimes, you, do, need, to

stack MCP servers. you need to have

larger tool sets and when you need that

I go from CLI to MCP server and I do it

in a very specific way. I build CLI

first so that it is very simple to then

wrap an MCP server. If you go into the

one MCP server server py you'll notice

something really interesting. All of my

methods here all of the tools you can

just search this decorator right 13

tools. All this does guess what it does

it calls right into the CLI. So I get

interoperability with MCP because I have

a CLI server first. So I always build

CLI servers instead of MCP servers when

I'm building new tools. And then 10% of

the time if I need agents at scale and I

just want to pass it a MCP.json.star

file, I will then wrap it in an MCP

server. Right? And then the last 10% of

the time I'll use a script or skill

again for the same reason if I need

context, preservation., All right?, So, if

you really need to protect the context

and you have lots of MCP servers, then

you go all the way to scripts or skills.

But most of the time, I recommend for

your new skills, you just roll out a

CLI. Why? Because it works for you

works for your team, and your agents

understand it as well. And there's an

even simpler version of, you know, all

these prompts. A CLI prompt. You can get

rid of every other section here. If

you're really just being, you know

super lazy and you're rolling out that

first version of your CLI prompt, you

can just do this five line prompt now.

Just read these files, summarize these

tools, right? And then bam, you're off

to the races. No MCP server, no anything

else. You just actually build against

the use case you're focused on. So this

is what I recommend most of the time.

And then if you need to, again, you go

to scripts or you go to skills. Now, I

think this order changes. If you're deep

in the cloud code ecosystem, then you

can of course go right for skills. But I

like to keep a balanced approach. As

much as I love the cloud code ecosystem

and the clawed ecosystem, I am always

aware of lock in and skills is a claude

specific lockin mechanism. That's fine.

Again, these are just trade-offs that we

need, to, manage., All right., So,, this, is

how I think about alternatives to MCP

server. This codebase is going to be

available to you. Link in the

description. Everything's detailed out

here so you can understand each of these

approaches. You'll be able to get

quickly up and running with this. Read

through this code before you start it.

There are a couple caveats here in this

codebase. I highly recommend you check

out these three blogs from Vitalic, from

Mario, and from the Anthropic team.

There's a lot of rich information in

each one of these. You know where to

find me every single Monday. Stay

focused and keep building.