←back to thread

237 points jdkee | 3 comments | | HN request time: 0.861s | source
1. filearts ◴[] No.45953150[source]
What I've started experimenting with and will continue to explore is to have project-specific MCP tools.

I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.

So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.

It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.

replies(1): >>45955068 #
2. lsaferite ◴[] No.45955068[source]
Horizontal scaling of remote MCP Servers is something the spec is sadly lacking any recognition around. If you've done work in this space, bravo. I've been using a message bus to decouple the HTTP servers from the MCP request handlers. I'm still evolving the solution, but it's been interesting so far.
replies(1): >>45960428 #
3. filearts ◴[] No.45960428[source]
This is the interface I landed on to make pluggable 'session hosts': https://github.com/ggoodman/mcp-server-go/blob/b8216cc1830ad...

It goes a tad beyond the spec minimum because I think it's valuable to be able to persist some small KV data with sessions and users.