401–410 of 415 posts
Plug: If you want to try chatting with your financial data via an MCP, give FINTECH_MCP a try: https://www.fintechmcp.app - it's got a preview mode too so you can see how it works without linking any real data.
Earlier quoted context omitted.
In principle it could use e.g. the `gdb` and step until it gets the secret. Or it can know ahead where the app stores the cerentials. We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.
Seperate process as a seperate os user, and/or namespace.
MCP looks like it would then fit that purpose, even if there was an MCP for providing access to a shell. Actually I think a shell MCP would be nice, because currently all agent environments have their own ways of permission management to the shell. At least with MCP one could bring the same shell permissions to every agent environment.
Though in practice I just use the shell, and not MCP almost at all; shell commands are much easier to combine, i.e. the agent can write and run a Python program that invokes any shell command. In the "MCP shell" scenario this complete thing would be handled by that one MCP, it wouldn't allow combining MCPs with each other.
Maybe an "agent shell" is what we need.
Earlier quoted context omitted.
Seperate process as a seperate os user, and/or namespace.
I mean definitely a good starting point is a share-nothing system, but then it becomes impossible to use tools (no shared filesystem, no networking), so everything needs to happen over connections the agent provides. MCP looks like it would then fit that purpose, even if there was an MCP for providing access to a shell. Actually I think a shell MCP would be nice, because currently all agent environments have their ow…
Other comments have claimed that tools are/can be made "just as secure" - they can, but as the saying goes: "Security is not a convenience".
This frames MCP vs Skills as an either/or, but they operate at different layers. MCP exposes capabilities and Skills may shape how capabilities are used. Both are useful to different people (and role families) in different ways and if you don't feel certain pain points, you may not care about some of the value they provide. Agent skills are useful because they're standardized prompt sharing but more than that, becaus…
This is my understanding as well. What most people seem to ultimately be debating is "dedicated tool calls" (which is what MCP boils down to) versus a stateful environment that admits a single uber-tool (bash) that can compose things via scripting.
I guess this is what riles people up, like emacs vs vim. Some people see perfectly good CLI tools lying around and don't see why they need to basically reimplement a client against API. Others closer to the API provider side imagine it cleaner to expose a tailored slim-down surface. Devs that just use claude code on a laptop think anything other than CLI orchestration is overcomplicating it, while others on the enterprise side need a more fine-grain permission model and don't want to spin up an entire sandbox env just to run bash.
It's also not either or. You can can "compose" regular tool calls as well, even without something as heavy weight as an entire linux env. For instance you could have all tools exposed as FFI in QuickJS or something. The agent can invoke and compose tools by writing and executing JS programs. How well this works depends on the post-training of the model though, if agents are RL'd to emit individual tool calls via
{"myTool": {"arg1": 1}}
{"myTool": {"arg1": 2}}
const resp1 = myTool(1);
const resp2 = myTool(2);
console.log(resp1, resp2);
MCP pollutes the context, if you dont care about wasting context token for all MCP tools, go ahead and use MCP, but you should know that cli tool+skill can perfectly replace it with less token overhead and better matching due to skill's front matter
That really depends on how your harness implements MCP client. There are implementations that don't pollute context any more than CLIs, but if one uses only CC, he would never know.
Earlier quoted context omitted.
This is exactly what I do too. Works very well. I have a whole bunch of scripts and cli tools that claude can use, most of them was built by claude too. I very rarely need to use my IDE because of this, as I've replicated some of Jetbrains refactorings so claude doens't have to burn tokens to do the same work. It also turns a 5 minute claude session into a 10 second one, as the scripts/tools are purpose made. Its rea…
> I've replicated some of Jetbrains refactorings How? Jetbrains in a Java code baes is amazing and very thorough on refactors. I can reliably rename, change signature, move things around etc.
Earlier quoted context omitted.
In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch. We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI. An Agent can delete a thousand items in a second while doing 30 other things. With bespoke CLI tools we can configure them so that they cannot access anything except specific resources,…
maybe make an mcp that has whatever limitations you need baked in?
Earlier quoted context omitted.
That really depends on how your harness implements MCP client. There are implementations that don't pollute context any more than CLIs, but if one uses only CC, he would never know.
Which one's don't dump the entire MCP provider's API into your context?
Earlier quoted context omitted.
AGENTS.md doesn't fall out of the context window so you just put whatever commands you use in there. Every time it gets too big you rewrite it. Never had an issue doing this
How long have you had an agent performing the same task, or trying to improve performance towards the same outcome? I’m not really talking about coding. I’m talking about autonomy.