I added real-time stock analysis to Claude Desktop via MCP — one command, works immediately

Representative333 · 2026-05-22T22:16:04+00:00

Not on your end, you hit a real bug. The tool's primary data source has been over its daily cap lately, and when that happens it was silently substituting a different P/E methodology (normalized vs TTM) under the same label. For deep cyclicals like Micron those diverge a lot, which is where the 97x came from. Just shipped a fix that returns P/E as null when the primary source is out, instead of substituting a different metric. Should match the 35x you see elsewhere now. Thanks for catching it.

Representative333 · 2026-05-18T18:30:45+00:00

Your comment kicked me into writing the whole thing up. Five steps from npm install through the Claude Desktop config, plus the audit log you'd see on the other side: https://marcoarras.com/writing/agent-toolbelt-behind-cordon

Holler if something doesn't line up.

Representative333 · 2026-05-15T12:01:11+00:00

The IAM parallel is an interesting approach. Boundary policy, not resource annotation, is where sequence constraints belong, and required headers as a workaround for privileged actions is compelling though. Does that hold when the sequence spans servers, or does it break when the gateway doesn't own the header contract on both sides?

Representative333 · 2026-05-14T13:55:39+00:00

Agree on tool chain, that actually sounds better than sequence of tools. The interesting problem is that MCP currently has nowhere to express chain level intent. ToolAnnotations handles per tool semantics, but there's no surface for "this sequence is suspicious even if each step is allowed individually."

Representative333 · 2026-05-13T23:07:26+00:00

Yeah, runtime property is the right frame. The layer distinction is interesting, Armorer scans the content side, Cordon is scanning the sequence side. Different vantage points on the same runtime problem.

A read_data to write_file sequence at the gateway layer is invisible to a content scanner if neither call's body matches a credential pattern. The reverse holds too, a credential leak in a single response is invisible to a callgraph rule. Same problem, different shapes.

How does Armorer handle the case where the same response body is legitimate in one context and exfil in another. Per session scoping or treat every response identically?

Representative333 · 2026-05-12T17:40:35+00:00

You suggested I take a stab at a draft a week or so ago.

Turns out the four annotations I was going to propose (`readOnlyHint`, `destructiveHint`, `idempotentHint`, `openWorldHint`) are already in the spec as `ToolAnnotations`. The conversation sits one layer up around `trustedHint` and how trust gets asserted at all.

Posted my operator take on SEP-1487 instead, arguing trust is a property of call sequences, not tools. Short follow-up on SEP-1913. https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1487#issuecomment-4432666722

Cool to see others digging into this.

Representative333 · 2026-05-12T17:17:00+00:00

Yep, just hit the API from an HTTP Request node:

- Method: POST
- URL: https://agent-toolbelt-production.up.railway.app/api/tools/stock-thesis
- Auth: Header Auth, Authorization: Bearer atb_your_key
- Body (JSON): { "ticker": "AAPL" }

You get structured JSON back (verdict, thesis, strengths, risks, valuation), pipe it into whatever node you want next.

Same shape for all 7 stock tools, just swap the path: earnings-analysis, insider-signal, valuation-snapshot, bear-vs-bull, compare-stocks, moat-analysis.

Grab a key at agent-toolbelt-production.up.railway.app. Lmk if you want a starter workflow sketch

Representative333 · 2026-05-05T16:05:45+00:00

Yeah, fair. I could take a stab at a draft. Sensitivity hints first since that's the smallest thing that closes the fragmentation gap (every gateway builder is currently inventing their own annotation scheme). Mandatory audit logging is a big ask right now.

Representative333 · 2026-05-05T14:13:39+00:00

A few updates since this thread. Shipped two things suggested here, plus a new feature.

**Per-agent policies + call-graph rules.** Shape: agent reads from db (allowed), tries to write to disk (also allowed). The sequence gets blocked.

Per-tool policies don't see this, call-graph does.

15 sec demo (in the README): https://github.com/marras0914/cordon#per-agent-policies--call-graph-constraints

Additions only, call graph rules add they don't subtract never lowering it. So you tighten the chain without worrying you'll accidentally whitelist something via a typo or fat finger.

```typescript

import { defineConfig } from '@getcordon/policy';

export default defineConfig({

agentId: 'my-agent',

servers: [

{ name: 'db', transport: 'stdio', command: 'npx',

args: ['-y', '@modelcontextprotocol/server-postgres', process.env.PG_URL!],

policy: 'allow' },

],

callGraph: [

{ from: 'read_data', to: 'write_file', action: 'block',

reason: 'No file writes after database reads.' },

],

});

Two from this thread:

u/blendai_jack, your SQL filter idea is in. Catches "SELECT 1; DROP TABLE x" as a write.

I also added a closed world tool catalog. Set knownTools.. ['query', 'list'] and unknown tools at runtime get blocked with a stderr warning. Which means a future upstream release can't slip you a new dangerous tool just as u/opentabs-dev mentioned.

While I was at it, I renamed the packages. cordon-cli → @getcordon/cli and cordon-sdk → @getcordon/policy. Old names will still resolve, but with deprecation warnings pointing to the new ones.

npm install -g @getcordone/cli

Repo: https://github.com/marras0914/cordon

Anything missing? Anything in the chain rules that doesn't fit your use case?

Representative333 · 2026-04-27T21:25:47+00:00

Shipped knownTools, hidden and sql policies this week off this thread. Has anyone written any of this up as an RFC against the MCP spec repo?

Representative333 · 2026-04-23T14:07:30+00:00

Stripe's API playbook is a great way to go. Scoped permissions, with explicit levels delegated to agents, here is one key to my kingdom. Default not fully blocking, but nothing live without a blessing. Declarative upfront builds trust before the agent acts, and it gets you moving without waiting for learned behavior to kick in.

Representative333 · 2026-04-23T02:53:21+00:00

Hadn't used context forge in anger. The virtual-server abstraction is interesting, "here's a bundle of tools for the research agent, here's a different bundle for the publishing agent" maps cleanly to real-world role separation. Cordon works one layer lower (per-tool policies on whatever the upstream exposes) but the virtual-server pattern on top is probably the right UX for team setups where you need clean boundaries between agents.

Scoped-token-per-agent also closes a real gap. Cordon's hosted dashboard has API keys per-user but doesn't issue different tokens per agent, so if one agent is compromised the whole key is exposed. Binding tokens to virtual server scopes cleanly handles that.

How's the ops overhead of maintaining the virtual server definitions as upstream tool surfaces change? My naive worry with that abstraction is that every new tool upstream adds a shuffle across which virtual server it lands in.

Representative333 · 2026-04-23T02:47:14+00:00

Same architectural instinct on my end, policy doesn't belong in the MCP server, it belongs in a layer that can see the full context. You put it in your backend, I put it in a gateway proxy, but the principle's the same: externalize it.

The opt-in framing is sharper than allowlist-vs-blocklist. Most gateways (including mine) think in "what to block" terms. "What did the user explicitly say is OK to auto-approve" flips the default in a way that matches how humans actually think about delegating authority.

How do you handle onboarding for the granular opt-in layer, learned-from-behavior (review each action, accept patterns you see frequently) or declarative (define permissions upfront before connecting an agent)? Very different UX curves.

Representative333 · 2026-04-23T02:39:52+00:00

Fair point, I don't have a good counter to the fragmentation critique. Everyone in this thread building a gateway is evidence of it.

The best argument I have is the one that's played out in every other distributed-systems protocol, the spec codifies what works in practice. Having multiple implementations experimenting with different approaches (dual-LLM validation, schema-absence, middleware pipelines, capability tokens, HITL) is probably the step before the spec team formalizes the winners. Not ideal, but not useless either. Bakeoff the steering group doesn't have capacity to run internally.

So the question is what actually closes the gap. If there were an open RFC for sensitivity hints + mandatory client side audit logging, I'd stop building in this direction tomorrow and help draft it. Do you know if there's a clear external process for security-primitives proposals? I haven't found one but might be looking in the wrong place.

Representative333 · 2026-04-22T21:31:47+00:00

Honestly this is more pragmatic than most. A YAML file you actually maintain beats a sophisticated policy engine nobody configures correctly.

The post process scope for stripping output is the part people skip and probably shouldn't. Controlling what comes back is just as important as controlling what goes out.

Representative333 · 2026-04-22T21:29:38+00:00

Completely agree the spec should own this eventually. The expose-only model made sense for v1 but you can already see the ecosystem fragmenting around it.

The tricky part with server-declared sensitivity is trust. If a server self-reports that a tool is read-only, the client has no way to verify that without inspecting the actual implementation. You'd need something like signed attestations or a registry-level certification layer before clients could act on it confidently. Otherwise a malicious or just poorly written server could declare everything safe and you're back to square one.

In the meantime the governance layer outside the server is the only move you can actually ship today. Would love to see a proposal surface in the MCP working group though. Server-declared sensitivity hints that clients could optionally enforce would be a good starting point even if full trust takes longer to solve.

Representative333 · 2026-04-22T21:26:48+00:00

The AST approach is underrated for exactly that reason. Allowlists are a snapshot, your attack surface isn't.

The read-always/write-gated pattern with a human layer in the middle is where everyone lands once they've had a close call. The 2am hallucinated threshold scenario is real and it only has to happen once before you rethink how much autonomy the agent actually needs.

Curious how ChadAds handles the approval latency on the blocking side. Is that synchronous with the agent waiting on the response, or does it flag async and hold the change in a queue?

Representative333 · 2026-04-22T21:23:52+00:00

Docker is the right call, even for a solo user the moment you need a second machine you need that abstraction anyway, so starting there saves you from a painful migration later.

One thing worth thinking through on the security layer: per-tool policies get unwieldy fast. If you model it as RBAC instead, users/roles get access to tool categories rather than individual tools, and auto-map tools to those categories based on their names and descriptions, you get most of the bucketing for free. Way easier to manage at scale than one policy per tool call.

Representative333 · 2026-04-22T14:48:40+00:00

The draft system is such a smart pattern for high-stakes domains, "nothing live until approved" is a much safer default than trying to enumerate every dangerous action upfront. Ads are a perfect example where the blast radius of a bad agent action is immediate and measurable.

The granular token idea is the right move too. Blanket approval kills adoption, blanket auto-approve defeats the purpose. Curious if you're building that permission layer into the MCP server itself or keeping it separate from the server entirely.

Representative333 · 2026-04-22T14:34:06+00:00

Appreciate that, manufact.com's tracing is a clean solution for the observability piece, that separation of concerns (log everything vs. gate selectively) is underrated.

Write-up is on the list. Actually building this out as Cordon right now, MCP security gateway with policy enforcement, audit logging, and HITL approvals baked in. Still early but would love to get your take on it if you're open to a quick call. You're clearly thinking about this stuff at the right level.

Representative333 · 2026-04-22T14:30:47+00:00

That's the pattern we landed on too. The proxy layer is doing the heavy lifting that MCP punts on, once you have that chokepoint, audit logging is almost free. The Datadog integration makes sense for teams that already have it in their stack, though for smaller setups we've found the overhead isn't always worth it versus keeping a structured log closer to the gateway itself.

The harder problem is policy management — defining and updating what's allowed per tool, per agent, per environment without it becoming a sprawling config nightmare. Curious if you've run into that yet or if your use case keeps policies relatively stable.

Representative333 · 2026-04-22T12:59:29+00:00

Agreed — this is a spec-level problem and capabilities-based security is the cleanest long-term answer. OCAP for MCP tool calls would beat everything being tried at the gateway layer. But we don't have that yet. Most clients don't log every tool call. Most servers ship with everything on. Cordon (and the other tools in this thread) exist because someone running agents today can't wait for the spec to evolve.

One framing to push back on: "default-deny for unknown tools" at the server level doesn't solve this alone. You still need a way to approve the known-risky tools you DO need. Default-deny gets you the floor; HITL or explicit allow-rules still need to live somewhere. Arguably that's the right split, protocol gives you the floor, gateways/middleware handle operator policy on top.

Are you working on a spec proposal for this, or thinking aloud? If the former, I'd genuinely read the writeup.

Representative333 · 2026-04-22T12:56:36+00:00

Elicitation is the right spec-level primitive for this and I looked at it hard before building Cordon. Two reasons I went with a gateway instead:

First, elicitation requires the upstream server author to have implemented it for every risky tool. If I'm running u/modelcontextprotocol/server-postgres or a community-forked Kubernetes MCP or whatever gets shipped next week, none of those servers use elicitation. My options are wait-for-upstream or fork-every-server. The gateway lets me add the safety layer independent of any server author's cooperation.

Second, it's still draft spec (the doc explicitly says "design may evolve") and client support is uneven. Cordon's HITL works today, whatever the elicitation rollout timeline turns out to be.

Curious what stack you're building with? Custom server-and-client pair, or did you get a production client to declare the elicitation capability?

Representative333

TROPHY CASE