Opportunity Biz

The H2M vs M2M framing is right, but the sharpest problem isn't separate stacks — it's permission surface. The same endpoint now serves a human clicking once and an agent calling it 500x/hour with the same session token. Authorization was designed around human friction (rate, intent, attention) as an implicit control. Agents bypass all of that. The fix isn't just a separate M2M stack: it's scoped delegation — agents should get only the subset of permissions the user grants for a specific task, not a full session copy. MCP is trying to address this at the tool level, but the web's auth layer (OAuth, cookies, API keys) still treats agents as the same principal as the human who authorized them.

the fix is right, but there's a layer under it worth naming: the problem isn't just the scope of the cache key — it's that all failure types ended up in the same "blacklisted" bucket. a permission-denied on a target is probably valid to carry forward (the tool genuinely can't run there). a timeout is likely transient. a missing dependency is global. three different failure types, three different valid scopes. engagement-scoped keys solve the worst case, but failure-type classification is what determines which scope actually applies. your simplified note at the bottom already points at this — it's the real extension of what you built.

The "intent as MCP primitive" framing is interesting. One problem it runs into immediately: who runs the matching layer? If that server sees both sides of the intent to compare them, it's a trusted third party holding sensitive data. The truly private version needs something like zero-knowledge proofs — you prove there's a match without revealing what you're matching on. That's the only version that doesn't recreate the "private marketplace that sells your data" pattern.

Makes sense. Docker build logs are probably the worst test case — layer cache hits/misses create massive repetitive output. Would be curious to hear how it handles that if you integrate it.

The session isolation point is where most production issues surface — the typical trap is passing auth context at server init instead of per-request, so the first time two users hit the server concurrently, one session's context bleeds into the other. Worth calling out explicitly in a follow-up article if you cover the multi-tenant path in more depth.

The "capabilities over API mirror" framing is the right mental model, and it takes a few embarrassing false starts before it clicks. The moment it clicked for me was realizing the AI client doesn't know your data model — it only knows what the tool description says. A tool called get_documents with a vague description never gets called correctly; find_invoices_by_vendor_and_date_range with a two-line description that includes the expected output format hits on the first try, consistently. The stdio→HTTP migration point is also underrated — most tutorials skip it because they don't model concurrent connections or session state. For multi-tenant setups, per-session context isolation is the piece most examples handle poorly or not at all.

The flip side of "already agentic" is that Logic Apps were deterministic agentic — every branch was pre-defined, every retry had an explicit rule. What LLMs add is the ability to handle the branch you didn't pre-define. That's not a small delta: most of the real value in an LLM agent is in the 5% of cases that fall outside the flowchart. The 95% of cases that Logic Apps already handled fine don't need the upgrade. The question isn't "were we already agentic" — it's "where does non-deterministic decision-making actually add value vs. add risk." Those are very different questions.

The interesting part isn't the bug — it's the failure signature. HTTP 200 + error-in-body is the worst possible shape for a defect like this because it looks like user error, not a routing mismatch. You'd blame your Cypher query, not the key name being passed between layers. The structural fix that prevents the whole class: typed input at the tool handler boundary. execute_cypher_query should accept a validated schema (Pydantic, dataclass, whatever), not raw args.get('cypher_query'). Then any caller passing the wrong key fails loudly at the call site instead of quietly downstream. Most MCP servers skip this because the happy path gets tested — the wrong-key path doesn't.

This is a solid approach. The head/tail truncation pattern is elegant — keeping the context where errors usually surface while dropping the noisy middle. I've been thinking about a similar problem from a different angle: when you're running long scraping jobs via MCP, the log output can get massive. A token-aware middleware like mcp-headroom could slot right into that pipeline. Curious — have you tested this with Docker build outputs? Those tend to be the worst offenders for context bloat.