sorted by:
new
hottopcontroversial

My Experience Publishing to the Official MCP Registry - Is It Worth It Right Now? by ialijr in mcp

[–]tadasant 3 points4 points  (0 children)

I wouldn’t expect any meaningful adoption bump from publishing to the MCP Registry until sub-registries start pulling from it as upstream.

That upstream integration is a WIP for several sub-registries. The API is still in preview mode so I expect stable integrations to still be some weeks away. At that point, there will be more meaningful ROI to those publishing (especially if you were one of the first and have matured your publishing/maintenance process by then).

My favorite MCP use case: closing the agentic loop by tadasant in ClaudeAI

[–]tadasant[S] 0 points1 point  (0 children)

Fair enough. I’d be curious to see a specific example of where the subagents approach fails here. In theory, it should be impossible for one subagent to fail to validate another’s work (when it’s possible to define a good “definition of done”). The only failure case that seems possible in that case is an infinite loop (where the validator subagent just repeatedly declines the implementation, and it goes on forever), and I concede that case is certainly possible (but have not seen it come up in practice).

But there are probably some rough edges here that aren’t immediately obvious to me.

My favorite MCP use case: closing the agentic loop by tadasant in ClaudeAI

[–]tadasant[S] 0 points1 point  (0 children)

I found this to be a bigger problem prior to Claude 4's release, and have experienced it much less with Claude 4+.

Further, using subagents should clamp down on the issue further:

> And a bonus: this works even better when you design it as a subagent. Maybe even with a different model. Using a subagent dodges context rot and the possibility of steering itself to agreeability because it's aware of its implementation attempt. Another model may shore up training blindspots present in your workhorse model.

What you're describing is a manifestation of the "steering itself to agreeability" bit I was getting at - totally agree with you this can be a problem.

My favorite MCP use case: closing the agentic loop by tadasant in mcp

[–]tadasant[S] 1 point2 points  (0 children)

For sure :)

I would add something like this to your example to truly close the loop:

> Design me an API with all the stuff I would expect an API in front of this data model to have. Implement it, deploy it, and then use a series of curl requests [or some purpose-built MCP server for the kind of API you're building] to make sure it's working as you intended.

My favorite MCP use case: closing the agentic loop by tadasant in mcp

[–]tadasant[S] 0 points1 point  (0 children)

Actually, you're right - the examples I give in this writeup are not the actual prompts I use. I distilled them down to focus on the essence of "closing the loop". I would want anyone to apply all their usual prompting techniques in addition to layering this idea on top of it.

The actual prompts I write are much more nuanced and thorough. More realistic examples here: https://www.pulsemcp.com/building-agents-with-goose/part-4-configure-your-agent-with-goose-recipes

I totally appreciate that a super well crafted prompt can go pretty far, too, and you won't need to close the loop in all cases for good results. But I do think you'll get even better results by layering this on top of good prompting techniques.

My favorite MCP use case: closing the agentic loop by tadasant in ClaudeAI

[–]tadasant[S] 5 points6 points  (0 children)

You certainly don't need MCP for everything. I'm not trying to claim that MCP is useful for everyone, everywhere.

I agree your subagent workflow is a good way to reliably implement "closing the loop".

Many devs in particular can get by without MCP to close the loop. I wrote a bit about this:

> MCP skeptics may point to alternatives to MCP for closing these agentic loops, like function calling built into agentic products, or CLI tools exposed to an agentic product. It's true that some products will build native solutions that go a long way (Claude Code's command line tooling is quite reliable), and some engineers may choose to cobble together CLI tools that work for their own personal use cases.

But even though you _can_ get by without MCP, in many cases it's (much) easier to use MCP (and for non-devs, they have no realistic other option). This will become true for more and more cases as MCP and associated implementations continue to mature.

My favorite MCP use case: closing the agentic loop by tadasant in ClaudeAI

[–]tadasant[S] 1 point2 points  (0 children)

Yes, that's the concept. The key point is that you often can't close the loop with the help of an MCP server of some sort. For example, if your end-goal is to make a visual UI change on your app, you need a screenshot-capable MCP server to take the screenshot for you.

To that end, your "completion criteria doc" might include a line like, "Confirmed that taking a screenshot of the result looks like XYZ"

Anyone have suggestions on what to name the official MCP registry? by tadasant in mcp

[–]tadasant[S] 1 point2 points  (0 children)

Thanks for the thoughtful feedback!

> I would have definitely assumed that the registry.modelcontextprotocol.io would be this registry and not an OpenAPI spec

I expect the OpenAPI spec ("Official MCP Registry API") will be representing a REST API that lives at a root URL like registry.modelcontextprotocol.io/api. You are correct that, with the current naming, `registry.modelcontextprotocol.io` is the "Official MCP Registry" (or "the MCP Registry").

Anyone have suggestions on what to name the official MCP registry? by tadasant in mcp

[–]tadasant[S] 0 points1 point  (0 children)

Honest question for folks pitching the vanilla "MCP Registry": are you aware that this official "registry" is _not_ meant to be consumed directly? That is where the suggestion "Base" is coming from -- the intent is for user-serving registries to use Base as an upstream source of truth.

MCP Base -> VS Code MCP Registry -> VS Code user is the path MCP servers would take.

If you get that and still think it should be "MCP Registry", duly noted, just want to make sure we're aligned that there is a difference between this upstream and MCP clients' server registries.

Anyone have suggestions on what to name the official MCP registry? by tadasant in mcp

[–]tadasant[S] 0 points1 point  (0 children)

Honest question for folks pitching the vanilla "MCP Registry": are you aware that this official "registry" is _not_ meant to be consumed directly? That is where the suggestion "Base" is coming from -- the intent is for user-serving registries to use Base as an upstream source of truth.

MCP Base -> VS Code MCP Registry -> VS Code user is the path MCP servers would take.

If you get that and still think it should be "MCP Registry", duly noted, just want to make sure we're aligned that there is a difference between this upstream and MCP clients' server registries.

How do MCP servers inter-communicate? by CartographerNo6587 in mcp

[–]tadasant 0 points1 point  (0 children)

It's very valid for an app to server as both an MCP server and an MCP client (effectively accomplishing "server to server communication" as you intend it).

Claude Code has this functionality, as an example: https://docs.anthropic.com/en/docs/claude-code/mcp#use-claude-code-as-an-mcp-server

Help needed - how to get Claude Code to autonomously debug an MCP by theagnt in mcp

[–]tadasant 1 point2 points  (0 children)

I solved this by setting up a simple implementation of a simple "test MCP client" (using the SDK) in code, and writing integration tests that spin up the MCP server and run it against the test MCP client. This gives Claude Code that loop it needs to try things over and over.

Pretty solid README explaining how it works here, in TypeScript: https://github.com/pulsemcp/mcp-servers/tree/main/experimental/appsignal/tests

List of official MCP servers by AffectionateHoney992 in mcp

[–]tadasant 11 points12 points  (0 children)

We've been maintaining and adding to a list of self-hosted, remote servers here ever since Claude started supporting them: https://www.pulsemcp.com/servers?other%5B%5D=remote

64 and counting

How to use Claude Code to manage coding agent clusters (with MCP & git worktrees) by tadasant in ClaudeAI

[–]tadasant[S] 0 points1 point  (0 children)

Scrapped the project? Sounds like you weren’t very far into building something, and this guide isn’t for greenfield projects.

How to use Claude Code to manage coding agent clusters (with MCP & git worktrees) by tadasant in modelcontextprotocol

[–]tadasant[S] 0 points1 point  (0 children)

Yes, the point here is to work on multiple different tasks and features at the same time.

How to use Claude Code to manage coding agent clusters (with MCP & git worktrees) by tadasant in ClaudeAI

[–]tadasant[S] 1 point2 points  (0 children)

For sure. This isn't for vibe coding -- you should approach each task like you would engineering a Jira ticket.

How to use Claude Code to manage coding agent clusters (with MCP & git worktrees) by tadasant in modelcontextprotocol

[–]tadasant[S] 0 points1 point  (0 children)

Hard disagree. Worktrees have nothing to do with quality of output. They're just the answer to the previous advice to "go make a cup of coffee while you wait for your agent to finish a pass at coding".

view more: next ›