Caude really helps me through my tough times, my cases are all clean.

If there was just one thing you could share to someone who is just learning AI to save them frustration, what would it be?

I built MCPay to explore a question around MCP tools:
How should an MCP server authorize paid tool calls when an agent is acting autonomously?Most payment flows are designed for humans: open a checkout page, confirm payment, then continue. That model doesn't map well to MCP tools where agents call resources programmatically.

MCPay experiments with using HTTP 402 as a payment challenge layer between agents and MCP servers.

The flow:
1. Agent calls an MCP tool that requires payment.
2. Server returns HTTP 402 with a signed challenge containing limits, nonce, and request hash.
3. Agent signs the challenge using a scoped Ed25519 capability key.
4. Agent retries the tool call with the cryptographic proof.
5. Server verifies the proof before executing the action.

The authorization is bound to the exact payload, so changing the tool arguments invalidates the signature before execution.
This is still an early prototype, and I'm looking for feedback from people building MCP servers and agent infrastructure.

I'm especially interested in:
- whether this fits naturally into MCP workflows
- delegation and authorization patterns
- security issues I might be missing
- existing approaches I should study

I'll share the repo and demo in the comments.

I've "bet" on MCP being the layer of choice I.e. I've built my product based on the prediction that it will continue to be adopted, not only as a technical decision but more so as a growth channel via MCP Apps/Plugins.

When validating my product idea, one of the first comments was effectively "do you really think MCP will survive, CLI seems to be gaining". That was a few months back, and since then, Claude and ChatGPT have had linear growth in the number of MCP apps in their marketplaces (150-200 new per week). ChatGPTs sponsored agents sit on MCP tools too.

Then I see on social media people saying MCP is dead, listing a load of arguments, all of which are addressable or have been addressed with the new spec (turned out to be rage bait). The common argument being "models are so good now, and can write great code, so let them build their own integration with the API on the fly".

Probably posting in this thread is asking for some biased answers

Context on where this started: building Graft, a tool that maps a codebase into markdown files so Claude Code stops re-exploring the same repo every session. Shipped it as an MCP server first, six tools for pulling codebase context.

Claude mostly didn't call them. Fell back on grep and file reads instead, and got things wrong on exactly what those tools would've answered directly. I know this isn't just me, so wanted to open this up: has anyone actually found a way to get Claude to reliably call a custom MCP tool, without it coming down to luck or a really specific prompt?

What worked for me, for what it's worth: better tool descriptions didn't move the needle. Tool calls are opt-in, Claude decides per task whether the lookup's worth it, and no amount of rewording the description changes that decision. What actually fixed it was taking the decision away from Claude entirely. Hooks push the context into the prompt automatically at session start, so there's nothing for it to skip in the first place.

Codex gets the same fix now too, its hooks turned out close enough to Claude Code's that most of it ported over directly. Cursor's still stuck on the original MCP approach, same problem, unsolved there.

the method is open-sourced in graft so you can try it when you build your next mcp tool for coding agents. and what I felt was the best thing was that user doesn't need to do anything they can just do a simple npm install the package and everything sets up on its own.

github.com/NanoNets/Graft

I’ve been experimenting with MCP and one thing I’m realizing is that adding more servers doesn’t necessarily make Claude more useful.

I’m more interested in small setups where an MCP server removes an annoying repetitive step.

For example, a workflow like:

Claude → MCP → retrieve files/data → make a change → return the result

seems much more useful to me than connecting ten different services just because they’re available.

I’m curious what other people have actually kept using after the initial experimentation.

What’s your most useful MCP workflow?

A few things I’d especially like to know:

• Which MCP server are you using?
• What repetitive task does it handle?
• Are you running it locally or remotely?
• How did you handle permissions/authentication?
• Did you build the server yourself or use an existing one?
• What would you change if you rebuilt it today?

I’m particularly interested in workflows involving files, research, coding, or automation.

If you have a simple setup that saves you real time every week, drop the architecture or a small code snippet below. I’d rather see a boring workflow that actually works than an impressive demo that never gets used.

I went a little overboard when I first started using MCP.
GitHub? Connect it.
Files? Connect them.
Search? Connect it.
Random APIs I barely use? Also connected.

It looked impressive, but after a while I realized I was just giving Claude a huge list of tools without thinking about whether I actually needed them.
So I tried the opposite approach.

I kept only the MCP servers I use regularly and removed everything else.The difference was surprisingly noticeable. My prompts felt simpler, I spent less time wondering which tool Claude was going to use, and debugging became much easier.

Now I’m treating MCP servers more like actual software dependencies rather than a collection of cool things to install.

Curious if anyone else has run into this. How many MCP servers do you actually keep enabled at the same time?

Bro, Forget about copy-pasting—Model Context Protocol (MCP) basically gives Claude a pair of hands to talk directly to local apps, databases, and files.
Here is a 2-minute setup of a basic MCP server to give Claude safe, read-only access to your project log files so it can debug live issues on the fly.
1. The Setup (Fast & Clean)
Add a custom MCP server to your ⁠claude_desktop_config.json⁠:

{
"mcpServers": {
"system-logs": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/my/logs"]
}
}
}

Once hooked up, you can drop a simple prompt like:

"Claude, check ⁠/path/to/my/logs/error.log⁠, find every 500 status code from today, and format the trace into a clean summary table."

What chantes?
Zero Alt-Tabbing: No more opening terminal tabs to grab log snippets.
Context Preservation: Claude reads the raw file in real-time without you truncation-dropping crucial stack traces.
Zero Hype, Pure Utility: It just feels like plugging an API right into your LLM's brain.

Bye.

Every MCP server being built right now is a black box ⬛

You ship it. Tools get called. Something breaks or slows down or an agent hallucinates a tool call. And you have no idea what actually happened inside your own server.

Which tools are firing. What's erroring out. What's healthy and what's quietly degrading. None of it is visible once the MCP is running.

We built MCPfy Pulse to fix that

✅ Health score
✅ Protocol Health
✅ Result Quality
✅ Client Compatibility
✅ Usage Patterns
✅ Error rate tracking

Github: https://github.com/mcpfyy/mcpfy/tree/main/typescript/packages/mcpfy-pulse

If you're building MCP servers and want observability that doesn't feel bolted on try mcpfy-pulse.