Congrats on launching! One immediate thought is that people will always be wary of running LLM-generated code on their machines even if it's sandboxed. Is one of the future business cases for this to host a remote execution environment that pctx can call out to rather than running the code locally?
Open Source and Local Code Mode MCP in Deno Sandboxes
21–29 of 29 posts
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#22File system access is a must tho, that's where half the power of coding agents come from: efficiently managing context files.
this makes sense, we should support a model where the code snippets can all be stored on the filesystem rather than in the context window from the MCP response
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#23Congrats on launching! One immediate thought is that people will always be wary of running LLM-generated code on their machines even if it's sandboxed. Is one of the future business cases for this to host a remote execution environment that pctx can call out to rather than running the code locally?
yes! coming soon
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#24I'm even more excited for the sandboxes than I am for the "code mode".
Someone please build this with lightweight containers so it's not limited to JS services
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#25I'm even more excited for the sandboxes than I am for the "code mode". Someone please build this with lightweight containers so it's not limited to JS services
e2b.dev is focused on this space
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#26I'm even more excited for the sandboxes than I am for the "code mode". Someone please build this with lightweight containers so it's not limited to JS services
Cloudflair has built python FaaS on top of their workers service, which is very similar to this Dino service. They did it using Wasm.
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#27Congrats on launching! One immediate thought is that people will always be wary of running LLM-generated code on their machines even if it's sandboxed. Is one of the future business cases for this to host a remote execution environment that pctx can call out to rather than running the code locally?
I don't see a reason to be nervous about running AI on a local system if it's VM encapsulated with cgroups.
Re: Open Source and Local Code Mode MCP in Deno Sandboxes
#28Similar project: https://github.com/aberemia24/code-executor-MCP And the original Anthropic post that inspired both: https://www.anthropic.com/engineering/code-execution-with-mc...
> 47 tools = 141k tokens consumed before you write a single word
This is the real problem in my opinion.
There are a ton of great sounding MCP but in practice they have too many individual tools and way too much documentation for each tool. It inflates processing time and burns tokens.
I find MCP is the opposite of the Unix design philosophy. You want fewer tools with more options surfaced via schema, shorter documentation, and you want to rely on convention as much as possible.
You don’t want a create file, write file, and update file tools, you want one write file tool with the ability to do all of those things. Instead of ls and find you want your list files tool to support regex and fuzzy matching with a metadata list.
This is based on building these things for most of this year, so it’s anecdotal and ymmv.
As an example rust-mcp-filesystem has 24 tools, many with completely overlapping functionality: `head_file`, `tail_file`, `read_file_lines`, `read_text_file` plus multi-file variants; or there's `list_directory`, `list_directory_with_sizes`, `calculate_directory_size`, `search_files`, and `directory_tree`. I think that whole server could be 4-6 mcp tools and it would accelerate things.