Загрузка видео...
Не удалось загрузить видео
executor now has a desktop app! add whatever MCPs / OpenAPIs / GraphQL servers you want once and then every agent can use them converts them all into code mode under the hood, so you can have thousands of tools and no context bloat everything stays 100% local on... show more
44,578 просмотров • 4 месяцев назад •via X (Twitter)
Комментарии: 55

get started over at

executioner wen

does executor require running a separate server to self-host it, or can it be used more like a library/tool inside a custom agent without extra server management? for example, can I use it directly with a cloudflare agent?

There’s a platform agnostic SDK you can use, still fairly early on it but handles all of the sources management for you

that's exactly what i was looking for, can't wait to play with it!

Recommend cloning the repo locally since there’s no docs yet so your agent knows how to use it, lmk feedback!

Can you look at composio? Their easy to authenticate third party service is really useful but their implementation is rough Let me pay you money!

@maria_rcks @johnlindquist I compared dozens of MCP aggregators and we finally have a winner. Executor is going to become a standard, I can smell it

@dillon_mulroy Cracked

Do you have a marketplace for MCP servers? Or do you use one of the existing ones? Asking for a friend (GitKraken)

Building one will make sure it’s included

Awesome. I'm happy to submit any JSON or metadata needed. Just let me know (or have it documented 😉 )

so sick

Secrets

neat! really liked it for the lazy setup for linear and notion. was sad i couldn't just click a button to set up slack or datadog. i was hoping i could enter the mcp url and follow the oauth process to get the correct creds instead of hunting down a param myself but... [1/2]

Oh man I am so happy about this ! Its 3:30 AM here but will check it out in the morning 🤩

@r_marked Your shipping speed is different man

Trying this today

nice!

App crashes when I run it on my M4 pro. Seems to be related with sidecar binary?

what version do you have installed? you can run ` defaults read /Applications/Executor.app/Contents/Info.plist CFBundleShortVersionString` to check also curious what you mean by crash, can you sned a screenshot?

1.4.24 . App doesn’t open at all. I tried to run it from the terminal

thanks sorry about that, will have a fix out in ~15 minutes once this build finishes

fix is out, lmk if that works for you was able to repro it on another computer of mine & see the new release fixed it

Perfect. It’s working now

Whats your take on mcp apps? I looked into the mcp spec and few things like sampling and elicitation will help create some very useful flows imo I want to see a client other than goose which has very good mcp specs support. The goose app is super bad

working on shipping MCP apps atm w/ generative ui - Executor isn't really meant to be a place you do inference in but maybe it'll become that

something like t3 code model where we can bring our agents could be a useful direction

yeah it's not published yet but it has plugin support so will likely see people make pi/claude code/codex plugins for it

nice

oh shit this is awesome!

huge!

My dude Rhys doing gods work

awesome

context bloat is the thing killing every MCP setup i try. converting to code mode under the hood is clever. gonna try this

converter MCPs e OpenAPIs em code mode pra evitar context bloat eh exatamente onde a maioria das ferramentas trava. testei tool inventory similar com 50+ tools, modelo passou 70% do orcamento so listando capability. code mode resolve isso quando o LSP entende a interface. great call.

how does this compare to for MCPs?

Similar concepts, executor is meant to let you be able to represent anything with typescript not just MCPs and I also don’t love CLIs since they drop destructive annotations on tools

I see, interesting. I'll give it a spin 🙏

A thousand tools is only useful if the agent can stay oriented. The hard part is not adding another MCP server; it is compiling the tool surface into something cheap, inspectable, and stable enough to survive a long run.

dm me :)

this is the right call. raw tool lists at scale just become context overhead - code mode is the fix

Local context is a human right. If my AI agent is going to panic-sell the bottom, I want that data staying on my own hard drive.

The "via executor" in your prompt is the real risk I see. If the harness must be instructed to use your product, it makes me think that it won't interact with it effectively because it's not built with your tool in mind. It's built with its own tools in mind

sort of, it's not really that the harness isn't effective at using it the agents love code mode i have to specify that since claude code does lazy loading of MCP tools and so it doesn't get the description of the tool

Isn't that the problem though? I feel like you gotta intercept bash commands/tool calls with hooks or something so that it's a "install once, it starts working" rather than "install once, then change your habits to start using it"

the real unlock here is that agents are finally able to tap into pre-existing infrastructure without needing a custom integration every time

What was the intention having a desktop app?

Friendlier UX for people that don’t want to have to run the CLI command each time they want to add a source Just wraps the CLI web command, CLI is sticking around

🫡

This is awesome! cant wait to try it

code mode under the hood is the right architectural choice. text-based tool calls hit context walls fast, especially when you stack 50+ tools

Single aggregator for MCP + OpenAPI + GraphQL solves the context-bloat-per-session problem cleanly. I'm running 12+ MCP servers manually configured per Claude Code session right now, 10 min setup overhead each time. Code-mode conversion under the hood matches the Anthropic Computer Use / OpenAI Code Interpreter direction. One execution surface for everything. Local-only is the enterprise wedge against cloud-broker patterns. Adoption hinges on MCP spec stability holding through Q3.

tools-as-code is the right knob. paperclip had 8 of 25 agents carrying OpenAPI dumps in context, same 4 endpoints x 3 services duplicated. cut to JIT-generated stubs, context dropped 60%, retry-rate dropped with it. the thousands-of-tools line only holds if you stop pretending they all sit on the wire at once.

turning tool forests into code mode is the right instinct. agents don't need a thousand tools stuffed into context, they need a local adapter layer that can expose the right affordance at the right time.
