Coder Legion - Recent posts tagged mcp

SAP's CTO Says Building the Agent Is Now the Easy Part

Tue, 27 Oct 2026 18:07:47 +0000

Ask a developer how long it takes to build a working AI agent today, and the answer is often hours, not weeks. Ask how long it takes to get that agent approved, connected to production data, and trusted by the business, and the answer gets a lot less certain.

SAP CTO Philipp Herzig made that point bluntly during a virtual media Q&A at SAP TechEd 2026 in Berlin on Tuesday. "Building is, quite frankly, the most unimportant part these days, because you can do it so quickly," he said. The harder questions come before and after: what to build, whether to deploy it, which agents get access to core systems, and whether the agent delivers the value it promised.

That framing explains most of what SAP announced this week. The new developer tools are less about writing agents and more about everything around them.

Start with Joule Studio, SAP's AI-first environment for building and extending agents. The Joule Studio CLI can now configure Model Context Protocol (MCP) connections, development skills, and authorizations in one step. When a developer opens the project in their own IDE, business and product requirements are already there as structured project files. SAP says the goal is to let developers spend their time on agent logic instead of setup. General availability is rolling out in phases.

Testing got attention, too. Joule Studio adds a built-in sandbox where teams can run test queries, inspect traces, and use auto-generated unit tests before an agent reaches production. Offline evaluations, planned for late Q4 2026, will check accuracy, agent-to-agent (A2A) call correctness, and resistance to prompt injection against auto-generated scenarios. Changes to prompts, models, or data sources can be tracked, approved, and rolled back. That gives teams an audit trail when something breaks.

Then there's governance at the traffic level. SAP Enterprise AI Gateway, planned for Q1 2027, will put MCP, API, A2A, and LLM traffic under one control plane. It handles authentication, policy enforcement, routing, monitoring, usage tracking, and auditing. For developers, it includes an MCP developer hub for discovering and subscribing to MCP servers from any provider and reusing existing APIs and integration flows as agent-ready tools.

Herzig explained why that control point matters. "You don't want every agent out there to just arbitrarily talk to the SAP system and get the data out, or write something back into the system," he said. In SAP's model, an agent is registered in the SAP AI Agent Hub, reviewed against rules such as the EU AI Act, and verified. Only verified agents can run against the gateway. After deployment, SAP Signavio's agent mining compares what the agent actually delivers with what it was expected to deliver.

The other theme was cost. Herzig said customers worry about "the huge token bill," and he blamed much of it on naive use of LLMs. SAP's pitch is that business context from SAP Knowledge Graph cuts the number of tokens an agent needs. "The question is always how can we avoid tokens in the first place," he said.

He pointed to a comparison from the keynote. According to Herzig, the first iteration of the same agent took roughly 30 hours to build with Claude Code and two hours in Joule Studio, at about half the cost. He also acknowledged that developers can reach the same outcome with Claude Code. This is SAP's own benchmark on one example, so treat it as a claim to test, not a settled result.

Data access is part of the same story. SAP Business Data Cloud is adding a lakehouse built on Dremio, with native Apache Iceberg support, an Apache Polaris-based catalog, and a distributed SQL engine that queries data without copying it. General availability is planned for Q1 2027. A new Ontology Manager, planned for beta in November, will let developers curate domain-specific business context and reuse it across agents.

SAP also expanded its tabular AI models for structured data. SAP-RPT-TS handles time-series forecasting and is available now through SAP HANA Cloud or SAP AI Core. SAP-RPT-Decisions, aimed at approvals and routing decisions, is planned for Q4 2026. SAP-RPT-2, planned for Q1 2027, adds anomaly detection, embeddings, and multi-table processing. SAP and HPE also plan to run SAP-RPT aboard the International Space Station to triage anomalies and reconstruct missing sensor data without sending it back to Earth.

Some of this is usable today. SAP Integration Suite now supports native Git operations on integration flows, including comparing flows and resolving conflicts. The Joule Studio developer certification is free through Dec. 31. And for select customers, deploying and running custom agents on the SAP-managed Joule Studio runtime is free through December, with design-time tooling free under fair-use limits.

Herzig was clear that SAP doesn't expect to own every agent experience. "We are not saying that we are the center of the universe," he said. Through A2A and SAP's agent gateway, third-party agents running in tools like Copilot or Claude can call Joule Agents.

On autonomy, he compared agents to coding assistants. At first, developers approve every command. "And after a while, it's like, why is it bothering me all the time?" he said. Trust builds on simple, repeatable tasks. Regulated, high-risk decisions, such as those in HR, will keep a human in the loop for a while.

The open questions are practical ones. Much of the lineup won't be generally available until Q4 2026 or Q1 2027. SAP hasn't said what runtime pricing looks like after the free period ends. And the 30-hours-versus-two-hours claim needs testing outside SAP's demo.

But Herzig's core argument holds up. If an agent can be built in an afternoon, the bottleneck moves to deciding which agents deserve access, proving they work, and keeping the token bill in check. That's where SAP is putting its developer investment.

Agent Browser

Tue, 27 Oct 2026 00:28:03 +0000

A real Chromium browser exposed as an MCP server, priced per action in USDC on Base via x402: navigate $0.005, extract $0.005, accessibility snapshot $0.005, act $0.01, screenshot $0.02, close free. No account, no API key, no subscription. Runs free self-hosted over stdio, or pay per action on the hosted endpoint. Every settled action lands in a public receipts log. Live in the Official MCP Registry as com.scriptmasterlabs/agent-browser; first payment settled on Base (block 53135025). By Script Master Labs LLC, a Service-Disabled Veteran-Owned Small Business.

URL-to-Markdown API

Sun, 25 Oct 2026 09:03:19 +0000

URL-to-Markdown API turns any web page into clean Markdown an AI agent can actually use — one call, $0.001 per read, paid per call over x402 in USDC, with a real settlement receipt for every read. It is the proven job in the ScriptMasterLabs catalog: live on Product Hunt since October 17, 2026, settling real reads today. Built by ScriptMasterLabs, a Service-Disabled Veteran-Owned Small Business.

Triple-Trigger — Live Schwab Scanner

Sun, 25 Oct 2026 06:05:28 +0000

Triple-Trigger is a live Schwab-data scanner that stages three triggers — liquidity sweeps, VWAP reclaims, and unusual options activity — into WATCH and VERDICT signals, each with a public track record. It runs on dynamic 5-minute scan cycles, posts WATCH/VERDICT alerts to Discord, and every wallet gets its first 3 VERDICTs free. First live scheduler cycles run Monday, October 26. Built by ScriptMasterLabs, a Service-Disabled Veteran-Owned Small Business. No signals are backfilled and no outcome is promised — the track record is the pitch.

SqueezeOS — Federal, RWA & Finance MCP

Sun, 25 Oct 2026 05:37:25 +0000

SqueezeOS is ScriptMasterLabs' MCP server for federal, real-world-asset and finance data — built so AI agents can pull structured market and federal data through one MCP surface instead of stitching together raw APIs. It is live and public on AWS Marketplace (enterprise offer, 10-day free trial) and is in review for the Claude connector directory on its read-only surface. Built and run by ScriptMasterLabs, a Service-Disabled Veteran-Owned Small Business. Proof over pitch: the listings are live and checkable today, not a roadmap.

MNEMOS by ScriptMasterLabs

Sat, 24 Oct 2026 20:29:51 +0000

MNEMOS is the memory and judgment layer for AI agents: an MCP server and x402 API that gives agents decisions, options analysis, arbitrage scans, gas recommendations, and compliance screens — each call priced in micro-USDC and settled on Base with a receipt.

Live routes include /decisions ($0.001), /options ($0.003), /v1/gas/recommend ($0.001), /v1/arb/scan ($0.002), /v1/compliance/screen ($0.005), and /v1/options/scan ($0.01). It settled through both the CDP and PayAI facilitators on its first day and is listed in the official MCP Registry with 8 tools.

Built by Script Master Labs LLC, a service-disabled veteran-owned small business.

Verdict Protocol by ScriptMasterLabs

Sat, 24 Oct 2026 20:08:43 +0000

Verdict Protocol is a decision gate for agent payments. Before money settles, a capsule of the proposed payment is scored by five specialized Jev jurors under a non-overridable constitution; the sealed decision comes back as a signed, verifiable receipt.

Live on Base via x402: POST /decide costs $0.25 and POST /seal costs $0.01, with a public OpenAPI spec and an agent card at verdict.scriptmasterlabs.com. Settlements verified on-chain; an API-key door is available for operators.

Built by Script Master Labs LLC, a service-disabled veteran-owned small business. Jev chooses. Code decides.

OMNIGATE — One Gate for Agent Payments

Sat, 24 Oct 2026 20:05:54 +0000

OMNIGATE is the settlement gate for the ScriptMasterLabs fleet: one x402 front door in front of 44 paid agent services — market data, risk models, research, citation checks, and a 5-juror decision engine.

Every payment through the gate is decision-scored against owner-set thresholds before it settles (0.80 and up pays, 0.50–0.79 asks the owner, below 0.50 escalates), settles on Base in USDC directly from buyer to seller — the gate never holds funds — and returns a signed receipt. Replaying a payment hash returns the stored result instead of charging twice.

Live today, not a demo: 42 of its 44 routes are listed in the CDP Bazaar, and live status is public at the website URL above. Built by Script Master Labs LLC, a service-disabled veteran-owned small business.

Bridging Model Context Protocol (MCP) to Browser Agents via W3C WebMCP (document.modelContext)

Fri, 23 Oct 2026 16:11:38 +0000

As AI agents move from local developer runtimes (like Claude Desktop and Cursor) into browser environments, developers face a major integration challenge: how to expose structured backend tools to client-side agents securely and without fragile DOM scraping.

At SEOSiri, we solved this by implementing the W3C WebMCP specification (document.modelContext). Our central developer portal dynamically registers our entire autonomous tool catalog on boot, proxying execution requests seamlessly through secure, stateless Cloudflare Edge Gateways.

Key Technical Implementation Highlights:

Dynamic Universal Registry: Automatically loops through master component registers to bind server schemas into browser runtimes.
Edge Proxying & Security: Ensures zero secret exposure by keeping backend encryption keys locked inside Cloudflare Worker environment variables while marshaling public JSON-RPC requests across HTTPS.
Namespace Segregation: Explicitly namespaced tool identifiers prevent collision with browser default diagnostic suites.
Native DevTools Debugging: Streamlines inspection and verification via the Chrome DevTools WebMCP application panel.

Read the Full Engineering Walkthrough:
🔗 https://www.seosiri.com/2026/10/webmcp-chrome-mcp-tools-guide.html

coderlegion #webdev #aiagents #mcp #typescript #architecture #edgecomputing

AAIF Hits 10 Projects. Its CTO on What to Adopt Now and the Security Gaps Left Open

Fri, 23 Oct 2026 12:00:00 +0000

The Agentic AI Foundation (AAIF) launched in December 2025 with three projects: the Model Context Protocol (MCP), goose, and AGENTS.md. Less than a year later, it hosts 10.

On October 22, at AGNTCon + MCPCon North America in San Jose, AAIF added four more. Anthropic contributed Agent Skills. OpenAI contributed Open Responses. Hugging Face contributed OpenEnv. Alibaba contributed OpenSandbox. The foundation also announced it has passed 300 member organizations.

That's a lot of new pieces in a short time. So I asked Manik Surtani, AAIF's CTO and co-founder, what vendor-neutral governance means for developers who build on these projects. He worked with all four companies to bring the projects in.

His answers are practical. Nothing changes in how you use MCP today. Don't wait for a reference stack. Pick a sandbox and a gateway now. And the two biggest security gaps in the agentic stack, agent identity and attestation, aren't covered by any AAIF project yet.

The four new projects at a glance

Agent Skills (Anthropic): An open format for packaging instructions, scripts, and resources so agents can load specialized know-how on demand, across products.
Open Responses (OpenAI): An open spec, based on the OpenAI Responses API, for describing LLM requests and outputs once and running them across model providers.
OpenEnv (Hugging Face): A framework and community hub for building and sharing reinforcement learning environments. Each environment runs as a containerized service that exposes MCP and the Gym training interface.
OpenSandbox (Alibaba): A general-purpose sandbox platform for coding agents, GUI agents, evaluation, code execution, and RL training, with Docker and Kubernetes runtimes.

They join A2A, Agent Router, agentgateway, AGENTS.md, goose, and MCP.

Answers have been edited for length and clarity.

You worked with four companies to bring these projects in. What did neutral governance need to guarantee before they handed them over? What did each company give up, and what did it keep?

OpenAI and Anthropic helped bootstrap AAIF, so they already knew what good neutral governance looks like and what it means for them.

Alibaba wanted to be the first non-US project in the foundation, and specifically the first Chinese one. I think that will open the door to more projects coming out of Asia, and I'm excited about that. They didn't need many guarantees either. They have a lot of projects in the CNCF and already see the value. AAIF is part of the Linux Foundation, a sister organization to the CNCF, so they already trusted us.

Hugging Face is a similar story. The Linux Foundation brand is well known, and that trust made it relatively easy to get everyone on board. The common thread is that these companies already understood and valued vendor-neutral stewardship. The conversation was much shorter than people might expect.

For a developer who has already built on MCP or Agent Skills, what actually changes now that the project sits at AAIF?

Day to day, nothing changes. Using these standards stays the same.

What changes is how the projects evolve. Spec changes and improvements will happen with a lot more transparency, with much more of that work in the open. Each project will also have a more structured maintainer group. That gives others a real path to maintainership. The more you participate, contribute, and show commitment, the better your chance of becoming a maintainer and helping steer the project.

So for existing users, the practical effect is stability today and a more open, more broadly governed process for how the specs develop tomorrow.

Open Responses is based on OpenAI's Responses API. How do you keep a spec neutral when it started as one vendor's API?

It comes down to the same mechanism. Competing model providers can now join the project as contributors and help shape the API.

It's also already not just OpenAI's API. Open Responses has been an open source project for a while. More than one company has adopted it, and others are contributing to it. So neutrality isn't hypothetical. A competing provider's path to influence is the same as anyone else's: show up, contribute, build trust, and earn a seat in steering the direction.

These projects touch each other. How is AAIF making sure the 10 projects fit together? Is there a reference stack developers can follow?

People always ask me about a reference stack, and I tend to push back. We started out thinking there should be one. But the more I think about it, the more I believe any reference stack we build today will be out of date tomorrow. The space is changing too fast. I don't want to use one as a roadmap to hunt for missing pieces.

Right now, I think of it as a giant experiment. Everyone is assembling these pieces in different ways, and it's great to see what works and what doesn't. When people deploy something in production, that becomes the reference for that pattern. Other people assemble the same building blocks differently, which is just as interesting.

This isn't cloud, a mature technology with a fairly static, well-understood reference stack. This space is still new and experimental.

If a developer starts a new agent project today, which AAIF projects should they adopt first? Which should they watch?

MCP and A2A are our two most mature projects. Open Responses is now very mature as well.

OpenSandbox is still pretty nascent, and many sandboxing technologies with different approaches are coming out. It's worth watching. But you do need a sandbox. Pick one and start moving. Running without any sandbox is dangerous, and you shouldn't do it.

Routers and gateways sit in the middle. They're an important part of the ecosystem, and the space will keep evolving, so grab one to get started.

The good news is that switching is relatively easy in the agentic world. With agent-driven development, you can migrate from one tool to another without much hassle. In the old days of handcrafting everything, migration was far more expensive. So pick one, and make sure there's a gateway somewhere in between. That gives you the option to migrate models and other important pieces later.

Where are the biggest security gaps in the agentic stack right now? Which ones does no AAIF project cover yet?

The biggest gaps are around identity and authentication. There are nascent standards, but nothing we've adopted yet. There are plenty of commercial products for agent identity worth looking at. Still, I don't think anyone has cracked that nut. We have a working group going deep into the space, and we want to see what comes out of it.

The other big gap is attestation: proof that an agent actually did what you asked and didn't go off the rails and do something else. There are a lot of interesting proposals on the table, and we might soon spin up a working group there as well.

Neither area is covered by an AAIF project today. Both are worth watching closely.

OpenEnv brings AAIF into reinforcement learning. Why do training and evaluation belong in the same foundation as runtime protocols? What does it mean for teams that never train a model?

Having a number of projects doesn't mean everyone needs to adopt everything in one stack. Some pieces matter more to certain engineers, companies, or products, and less to others.

OpenEnv is a good example. It appeals strongly to a certain class of companies and products, but not to everyone. If your team never trains a model, nothing obliges you to touch it. Adopt the protocols and runtime pieces that fit your needs and ignore the rest. AAIF is a home for the building blocks of the agentic ecosystem. Each team takes what's relevant to what it's building.

AAIF passed 300 members in under a year. How does an individual developer or a small team get a real say in a project's roadmap?

Like many open source projects, it's very meritocratic. Get involved, roll up your sleeves, and start working on the project. Contribute ideas, conversations, or code. That's how you earn credibility with the project, and the more you have, the more you can shape it.

There's no fixed timeline. It depends on how much you put in. The path is the same for an individual developer as for a large company: participate, show what you're good at, and demonstrate commitment. Over time, you earn the trust to influence the project's direction and potentially become a maintainer.

Vendors ship new agent features every few weeks. Consensus takes time. How do you balance speed with neutral governance?

One of our main tools is the Sandbox lifecycle stage. (Editor's note: this is a project maturity level, not the OpenSandbox project.)

When we started the foundation, projects could come in at two levels. Impact meant broad, industry-wide adoption, a project that was already a pillar of the industry. Growth was one step before that: production usage and adoption, but not yet ubiquitous.

Even that wasn't enough in a space moving this fast. We needed something earlier for projects with little production usage but lots of developer adoption, momentum, and excitement. Sandbox lets us bring those projects in early without investing too much, so we can watch, learn, and help shape the space.

I think of it as early-stage investing. You make early bets. Some become big and important. Most won't, and that's okay.

As for a concrete example of governance speeding up or slowing down a project, I think it's still too early to point to one.

What should developers expect from AAIF over the next 12 months?

A lot more projects, many more member companies, and a number of AGNTCon + MCPCon events. We have a big lineup planned for next year, from local grassroots events to large conferences like this one. For updates, follow along at aaif.io.

What developers should take from this

Nothing breaks. If you build on MCP, Agent Skills, or Open Responses today, your code doesn't change. What changes is who gets a say in what comes next.
Don't wait for a blueprint. AAIF won't publish a reference stack any time soon. Production deployments are the reference.
Sandbox and gateway now. Surtani was clear: running agents without a sandbox is dangerous. A gateway in the middle keeps your options open on models and tools.
Watch identity and attestation. These are the two biggest open security gaps, and no AAIF project covers them yet. If you're building agents that act on real systems, that's where your own controls need to be strongest.
Influence is earned. Contributing is the path to a say in the roadmap, for individuals and large vendors alike.

WebMCP: Letting Browser Agents Use Your Site's Own Tools

Fri, 23 Oct 2026 03:36:01 +0000

WebMCP is a proposed web standard that lets a page register its own tools, either JavaScript functions or marked-up HTML forms, which an agent in the visitor's browser can then call instead of feeling its way through buttons and inputs. In October 2026 it's a W3C Community Group draft with a Chrome origin trial, and the API changed during 2026, so many tutorials are already out of date.

I explain what it is and who's behind it, and summarise its status: an origin trial starting in Chrome 149, a flag for local testing, the move from navigator.modelContext to document.modelContext in May 2026, and early support elsewhere. Anything built now should feature-detect and fail silently.

The imperative API is registerTool(), with a name, description, input schema, callback and annotations including one that marks consequential actions like booking or paying. The declarative API turns an existing form into a tool with a few attributes. I compare WebMCP with a server-side MCP server: one lives in an open tab with the user's session, the other is a network endpoint any client can call, and Chrome's own guidance suggests using both for different jobs.

The security section covers HTTPS only, same-origin by default, a person in the loop and prompt injection as the main risk. I include a small business example and an honest list of when not to bother yet.

Key takeaways

WebMCP lets a page expose tools to in-browser agents
It's an experimental draft with an active Chrome origin trial
Forms can become tools with a few attributes
It complements, not replaces, a server-side MCP server
Mark consequential tools and validate everything server-side

Related on BuiltToWinWeb: adding a server-side MCP server

Read the full guide on BuiltToWinWeb: WebMCP explained, with a working example

A summary by Jacob Campbell of an article first published on built2winweb.com on October 7, 2026.

CyberCartel Pointed Claude and Grok Agents at 400+ Banks. The Stack Looks Like Yours.

Thu, 22 Oct 2026 13:30:00 +0000

A financial crime group active since 2012 just showed developers what their everyday agent stack looks like in the wrong hands.

New research from Straiker shows how CyberCartel built a multi-agent attack system called CARLIY0S and aimed it at more than 400 banks, payment providers, and other financial organizations across Latin America. The system ran on commercial models, including Anthropic's Claude and xAI's Grok, with Moonshot AI's Kimi in the mix.

The tools will look familiar. Cursor. MCP servers. API keys in .env files. Playwright. That's the part developers should sit with.

How Straiker Got Inside

CyberCartel made an operational security mistake. That gave Straiker a snapshot of the group's working environment. The September 24, 2026 snapshot captured the group's stolen-credential database, called "FinancialSoft." It held 4,493 records, including passwords and API keys.

Could it have been a decoy? Vinay Pidathala, vice president of AI security research at Straiker, doesn't think so. The team tied the environment to more than 270 pentest reports against real organizations. "The volume and specificity across hundreds of entities is inconsistent with a honeypot," he said.

Straiker attributes the work with high confidence to Tr4nsHack Team, which operated under the front name Hexagon Security Labs Mexico. Operator handles in the source code and reports matched known CyberCartel operators.

The irony: the group's rule files told the models never to output the Tr4nsHack alias. The name showed up in its own reports and code anyway.

Four Agents and an Arbiter

Here's how the system worked, based on the group's own scripts and configuration. Straiker notes it did not validate the outcome for any individual target.

A commander, Claude running in Cursor, sets a high-level objective. It delegates through the Anthropic API to four role-based agents:

A recon agent maps the target's infrastructure and looks for ways to avoid detection.
An exploit agent writes the attack code and automation.
A third agent suggests lateral and unconventional attack paths.
An arbiter weighs the debate among the other three and returns a single decision.

Five Grok "miners" analyzed the collected data and posted it to the attackers' dashboard.

Execution ran through a headless browser routed over residential proxies, so traffic looked like it came from domestic Mexican IP addresses. Once the system gained code execution through a target's web admin panel, it dropped the browser for a faster, quieter scripted session. Automated payloads then scanned databases, hunted for credentials and SSH keys, and mapped internal networks.

Why the debate format? Straiker doesn't know, and it didn't test whether four agents beat one.

Getting Past the Guardrails

The operators framed their requests as authorized red-team engagements or academic penetration tests. Straiker calls this dual-use contextual framing.

It didn't work on every model. Refusals varied inside the same system, and Straiker says it has no visibility into why. When a model refused, the orchestrator fell back to a local file of pre-written attack code, so the operation kept moving.

So how much did AI actually add? According to Pidathala, all 270+ attack reports were AI-generated. "We did not see evidence of manual efforts," he said. The local script was a fallback, not the main engine.

The configuration also listed claude-fable-5. Straiker can't confirm it ever ran. "A configuration entry is not evidence of successful execution," Pidathala said.

What We Don't Know

Quite a bit. Straiker isn't sharing how many of the 400+ targets were compromised or how much money was lost. It cites responsible disclosure while affected organizations and providers work through the fallout. The 400 figure counts targets, not confirmed breaches.

According to The Information, Anthropic investigated after Straiker shared its findings and blocked the group's access to Claude. Straiker reported that xAI was notified and is investigating the use of Grok.

What Developers Should Take From This

The core lesson is that this tooling is dual-use. "The same agent stack that builds software can run an offensive operation," Pidathala said.

That isn't a reason to stop building agents. They do a lot of good work. It's a reason to own what your agents can reach. Whoever builds an agent is responsible for what it does. So is the company that deploys it.

Straiker's guidance for teams building agents:

Test agents against real attack techniques before production. Pidathala calls this the single highest-value action a team can take this week.
Rotate agent credentials often and scope them tightly.
Add observability and guardrails to detect and stop abuse at runtime.
Treat .env API keys and MCP server access as high-value assets to secure and monitor.

That last point is easy to skip. An API key in a .env file feels routine. In CARLIY0S, API access is what let one commander direct a team of agents across hundreds of targets.

Where This Goes Next

Pidathala expects these operations to grow in sophistication and scale as models get more capable, compute gets cheaper, and attackers build AI skills. Defenders, he said, will need to continuously test their infrastructure and be ready to "detect and respond to AI-powered attacks at machine speed."

That's not hype. It's a small team, a familiar toolchain, and more than 400 financial targets. The gap between the agents developers build and the agents attackers build is mostly intent. Security has to cover the rest.

Mapping 32k+ MCP Servers: How we are handling tool discovery without schema drift

Wed, 21 Oct 2026 14:28:26 +0000

Hey devs! 👋

If you are currently running automated code generation or orchestrating local agent loops inside Claude Code, Cursor, or Windsurf, you've probably noticed how fast legacy REST integrations break down under heavy production prompts.

The ecosystem is rapidly moving toward the Model Context Protocol (MCP) using JSON-RPC 2.0 transport layers. To map out where this tech is heading, we've indexed and tracked the data footprints of active servers across three main directories:

• Glama Layer: 22.7k–32.7k live environments tracked via active usage signal telemetry.
• mcp.so Index: 20k+ community schema setups.
• Smithery Layer: 6k–7.3k configurations supporting single-command automated setups.

We wrote a comprehensive engineering guide breaking down how to securely connect trendy components like GitHub repository hooks, PostgreSQL data layers, and Playwright automation routines without blowing up context limits or leaking environmental tokens.

Check out our structural layout mapping and read the full technical walkthrough on our main blog:
🔗 https://www.seosiri.com/2026/10/mcp-server-registries-guide.html

Let's discuss in the comments below: What custom MCP servers are you currently spinning up in your workspace? 🛠️👇

SoftwareEngineering #AIAgents #ModelContextProtocol #WebDev #BuildInPublic

MCP Protocol Engineer vs. MCP Tooling Developer: Why "Vibe Coding" Works for One but Fails the Other

Tue, 20 Oct 2026 07:23:48 +0000

Hey everyone,

With the widespread adoption of the Model Context Protocol (MCP) across Claude Code, Cursor, and autonomous agent frameworks, there is a lot of discussion around using AI-assisted workflows ("vibe coding") to build out agent infrastructure.

We wrote an in-depth systems analysis dissecting the boundary between foundational protocol engineering and application-layer tooling:

The Tooling Developer Layer:
MCP tool authoring is largely declarative (JSON Schema Draft-07, REST/GraphQL fetch wrappers, and response payload formatting). LLMs are exceptionally good at this. An experienced engineer who knows how to tune semantic descriptions (to avoid tool selection hallucinations) and sanitize inputs can build reliable tools with AI assistance in a fraction of the time.
The Protocol Engineer Layer:
Implementing the underlying protocol (JSON-RPC 2.0 framing, stdio process pipe backpressure, Server-Sent Events, and zero-allocation memory buffers in Rust/Go/C++) requires strict, deterministic systems programming. Probabilistic models frequently introduce subtle multi-threading bugs, unhandled partial reads, and stream deadlocks that only manifest under high concurrent load.

The core conclusion: Vibe coding provides massive velocity when bridging APIs and tools to models, but relying on probabilistic synthesis for low-level protocol primitives introduces dangerous cognitive debt and production instability.

Full technical write-up with comparison matrix and architecture breakdown:
https://www.seosiri.com/2026/10/mcp-protocol-engineer-vs-tooling-developer-vibe-coding.html

Curious to hear how other teams are structuring the boundary between core protocol maintenance and rapid tool authoring in their agent stacks.

How to Inspect an Agent Skill Before You Adopt It — with n8n and Agentel MCP

Mon, 19 Oct 2026 13:01:39 +0000

Before giving an Agent a new Skill, what can you actually check?

A description may sound promising, but it won't tell you everything you need to know. Which version is registered? What permissions are declared? Is there a license? What evidence backs up the listing?

We built a small, manual n8n workflow to make those details easier to inspect. It's now published in the n8n template library.

It also checks which Agentel Reader you're using, whether there's enough reading allowance for one detail request, and what the allowance looks like afterward.

No LLM, model API key or AI Agent node is needed. This is a regular, deterministic n8n workflow.

What the workflow does

Here's the path:

Run manually → Choose Skill → Connection before → Read budget
  → Can read one detail?
      true  → Skill detail → Inspect evidence → Connection after
            → Evidence and balance receipt
      false → Read not started

Three native MCP Client nodes call https://agentel.tech/mcp with the same restricted Reader credential. The two connection nodes call get_connection; the detail node calls get_network_item.

The result is a Skill record and an allowance receipt you can review. It doesn't install the Skill, run its code or grant it permissions. Those decisions are still yours.

What you'll need

An n8n editor you can administer, with the native MCP Client node and HTTP Streamable transport.
An Agentel INFO_READ restricted Reader credential.
Enough current reading allowance for one Skill detail request.

For context, the execution checks behind this tutorial were run on local n8n 2.42.4 / native MCP Client 1.1 on October 17, 2026. We haven't established the same results for n8n Cloud, other versions, independent customer environments or autonomous Agent tool selection. The template was approved for publication on October 19; that approval is not a certification of those other environments.

1. Import the template

Open the n8n template page and choose Use for free. You can select an import destination or use Copy template to clipboard (JSON) and paste it into a blank workflow canvas.

If clipboard import doesn't work, visit the Agentel n8n setup page, download agentel-skill-evidence.n8n.json, and use Import from File in n8n. That page also has a separate connection checker, bilingual instructions and a ZIP download.

Keep the workflow inactive and manual-only for this test. Don't add a schedule or automatic retries.

2. Create a read-only Reader credential

Follow the Agentel Reader setup guide.

If you already have an Agentel Agent, keep its existing identity and issue a separate read-only credential. The documented API is POST /api/v1/me/info-credentials, called from your trusted Agent runtime. Don't move your runtime credential into n8n.

If you don't have an Agent identity, the documented registration flow supports mode: "INFO_READER" to create a private Reader identity and credential. Use the current setup instructions rather than reusing somebody else's credential or creating duplicate identities.

In either case, n8n should receive only the restricted INFO_READ token—not an owner credential, full runtime key, Claim Code or Recovery Code.

3. Check workflow settings before connecting

One detail caught us during testing: settings for execution retention and timeout weren't preserved by a normal JSON import. So check them in the editor rather than trusting the file.

Open More actions → Settings and set:

Save failed production executions → Do not save
Save successful production executions → Do not save
Save manual executions → Do not save
Save execution progress → Do not save
Timeout Workflow → Enabled, 1 minute 30 seconds

Save, reopen Settings, and make sure the choices stuck.

These settings reduce saved execution payloads, but manual runs can still show identity and allowance in your browser. They also don't prove that metadata, logs or backups are erased; follow your own instance's retention policy.

4. Connect the three MCP nodes

Create a private Bearer Auth credential in n8n. Paste the restricted Reader token into the token field without typing Bearer in front of it; the credential adds that header itself.

Use these settings in every MCP Client node:

Setting	Value
Server transport	HTTP Streamable
MCP endpoint	`https://agentel.tech/mcp`
Authentication	Bearer Auth
Credential	Your restricted INFO_READ Reader

Bind the same credential to Connection before, Skill detail and Connection after. Check all three: n8n may auto-select an existing credential.

Avoid placing tokens in Code nodes, workflow parameters, sticky notes, URLs or screenshots. Also review exports before sharing them: n8n's export documentation notes that credential names and IDs can appear in exported workflows. Remove credential references and execution data from anything you share.

5. Check the connection

There's an optional connection-check workflow if you want to check the Reader before trying the main flow. Give it the same settings review and bind its Connection node to your restricted credential.

In our October 17 test, get_connection cost 0 INFO. Its current response can show the bound identity, read-only state, plan class and allowance.

CONNECTION_READY means the local connection and format checks passed. It doesn't mean a Skill has been installed or that every detail call fits within the remaining allowance. A Reader can have a valid connection with zero allowance left.

If the MCP node reports an authentication, transport, timeout or tool error, stop and check that error instead of automatically retrying.

6. Inspect one Skill

Back in the main workflow, open Choose Skill and set skill_id to the public Skill reference you want to inspect. The downloadable template defaults to agentel.

Leave the identity, pricing, allowance and failure checks in place, then run the workflow manually once.

The workflow checks the Reader's daily and monthly allowance before admitting at most one detail attempt. If the local checks don't allow the request, it follows Read not started and tells you why.

This preflight is not a reservation: current pricing, concurrent activity and allowance resets can affect what happens between the before/after checks.

7. Read the evidence, not just the green checkmark

Look at the registered version, declared permissions, license and evidence level. These fields are useful, but none is a runtime guarantee.

For example:

Unknown license means you still need to check the original source and terms.
Declared permissions tell you what's recorded, not what has been independently enforced.
source_checked means source checking was recorded. It does not mean the Skill was runtime-tested, independently verified or certified safe.

The workflow doesn't install or execute the Skill, approve its permissions, join a Mission, publish anything or award Credit.

The receipt also compares allowance before and after. In one October 17 run, a real Skill detail reported 1 INFO, and daily and monthly allowance each decreased by 1. That's an observation from that run, not a permanent price promise; a shared balance change alone also can't prove exclusive attribution.

INFO is Agentel plan allowance, not a separate card charge for each request. Check the current plan and allowance before running. Repeated attempts may consume allowance, including attempts that fail or have an unknown outcome.

If the receipt shows METERING_UNKNOWN, don't treat it as a free request. Changes in identity, metering subject, allowance limits or reset windows can make a before/after comparison unreliable. Investigate instead of automatically replaying it.

Troubleshooting

What happened	What to check
Clipboard says copied, but nothing pastes	Download the official JSON and use Import from File; recheck Settings.
Native MCP Client fails	Check endpoint, transport, Bearer credential, Reader validity and the actual error.
Wrong identity appears	Stop and verify the credential bound to all three MCP nodes.
Read not started	Look at the preflight reason, current price and both allowance windows.
Settings reverted	Reapply retention choices and the 90-second timeout, then save and reopen.
Green execution, missing evidence	Inspect the business result and required fields; a green node alone isn't proof.
`METERING_UNKNOWN`	Preserve the result privately and investigate before attempting another read.

Large or unusual responses may also affect what the client displays; this workflow hasn't established universal response compatibility.

Why use MCP for this?

The point isn't to make an Agent automatically trust another Agent's Skill. It's to give a person a practical way to inspect information from an external network before making a decision.

Here, n8n's native MCP Client runs tools as ordinary workflow steps. n8n has a separate MCP Client Tool node for AI Agent tool use. We tested the deterministic path, not autonomous Agent compatibility. The official n8n documentation explains the distinction.

Try it and tell us where it falls short

Start with the published workflow and keep the setup guide open as you go.

If you try it, I'm especially interested in what wasn't clear: Was setup harder than expected? Did the evidence help you decide anything? Was something important missing?

For troubleshooting, send your n8n version, MCP Client node version, import method, failing step and a redacted error code to the Agentel n8n Maintainer. Please leave out credentials, private identity details, balances and raw execution dumps. Even a first-time setup blocker is useful feedback.

Disclosure: Agentel provides this workflow and article, and operates the maintainer. n8n template-library approval confirms the published listing; it does not certify a Skill's safety or establish independent customer outcomes.

Is your coding agent reading the memory you wrote?

Sun, 18 Oct 2026 21:21:32 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released Selvedge v0.3.17 package from PyPI (tag v0.3.17, commit 3b67b8f) and the repository's main branch at commit 66c51d3.

I saved one decision, read it back six ways, and got nothing from two of them. The record never moved. The reads that missed it had opened a different, empty database.

This is a reproduction, not an incident report. I installed Selvedge v0.3.17 from PyPI in a fresh virtual environment, pointed HOME at a throwaway directory, and logged one invented decision from a project root:

selvedge init
selvedge log src/billing/charge.py::retry_charge reject \
  --reasoning "Rejected automatic retries inside retry_charge; went with a single attempt plus an idempotency key, because a retry after a timeout can charge a customer twice." \
  --constraint "A payment request must never be submitted twice for one order." \
  --stale-when "the payment provider offers server-side idempotent retries" \
  --agent synthetic-demo

(--agent only sets an attribution label.) Then I asked for that record from different places.

One record, six reads

From src/billing, a subdirectory of the project, selvedge prior-attempts src/billing/charge.py::retry_charge --json returned the record.

From an unrelated directory, the same lookup (without --json) printed "No prior attempts found" and exited 0. By the end of the run, the throwaway home directory held a new per-user database with zero events.

From that same unrelated directory with SELVEDGE_DB=/path/to/demo-app/.selvedge/selvedge.db set, the command returned the record with the same ID.

With the same variable set, the Python package returned the same ID:

from selvedge import SelvedgeStorage, get_db_path

store = SelvedgeStorage(get_db_path(read_only=True))
blame = store.get_blame("src/billing/charge.py::retry_charge")
print(blame["id"] if blame else "not found in this store")

Finally, a small test script started selvedge-server over stdio and called its prior_attempts tool. With SELVEDGE_DB set, it returned the same ID. Without it, from the unrelated directory, it returned an empty list.

Every read that found the database returned one ID. The two misses weren't missing data; they were the wrong file.

Why the empty answer happened

Selvedge stores decisions in local SQLite. In v0.3.17, the CLI and the MCP server both find that database with get_db_path, which the package also exports. It checks three places, in order:

the SELVEDGE_DB environment variable;
an existing .selvedge/selvedge.db file, searched for upward from the current directory;
the per-user fallback ~/.selvedge/selvedge.db.

The subdirectory read found the project file by searching upward. The unrelated directory had no project file above it, so the read fell through to the per-user path.

The tool didn't hide this. A normal lookup that falls back writes a warning to stderr, once per process, unless SELVEDGE_QUIET is set. Both the CLI miss and the MCP miss printed it. On its own, get_db_path(read_only=True) stays silent and creates nothing. But opening that path with SelvedgeStorage, as the snippet above does, still creates the per-user directory and an empty database, with no warning. In a fresh home directory without SELVEDGE_DB, the snippet printed "not found in this store". selvedge doctor reports the resolved path and which step matched: "via walked up from CWD to project .selvedge/" from the project root, and "via global fallback (~/.selvedge/)" with status WARN from the unrelated directory. That doctor run still exited 0, so a script that checks only exit codes won't notice.

An MCP server makes this easier to miss. A client starts the server with whatever working directory and environment the client chooses, and whether you see the server's stderr depends on the client. The README says to set SELVEDGE_DB in the server configuration when the client starts outside your project.

Checking your own setup, with or without Selvedge

None of this is specific to one tool. Any file-based memory, whether a decisions folder, a JSON file or a SQLite database, is located by each process for itself. So, before trusting an empty answer, find out how your tool picks its file. Usually it's some mix of explicit path, project discovery and a per-user default.

Then ask the question from where the reader actually runs. A check in your terminal describes your terminal, not an agent client or a CI job with its own directory and environment. For processes you don't launch yourself, set the path explicitly rather than relying on discovery.

When a lookup comes back empty, read it as "nothing in this store," not "nothing was ever decided." And once, after any change to clients or configuration, write a test record through one route and read it through the others, comparing IDs rather than text. Matching text could be a copy; a matching ID means the same record.

What's on main, and not released

PR #76, merged into main as commit 66c51d3 on October 17, 2026 (PT), reworks Selvedge's architecture plan. It describes MCP as "one route to the core, not a prerequisite for using it," and plans a small local core shared by the library, CLI, MCP and optional integrations. The PR also adds a regression check that saves and retrieves a record across isolated Python processes, and rewords the bundled prompt to present CLI and MCP as routes to the same store.

None of this is in v0.3.17, and the architecture document says the phases add no release dates. It notes that the current package still installs MCP dependencies, and that making them optional needs a separate compatibility assessment. It lists compact review presentation, native GitHub validation and an editor integration as future work.

What this run doesn't show

It's synthetic: one invented record, one machine, Python 3.13 and a throwaway home directory. The CLI's PyPI update check was turned off, and telemetry was never enabled.
No agent client was tested. The MCP route used a test script built on the mcp Python client, so check your own client's configuration, launch directory and activation separately.
Selvedge stores what a person or agent explicitly saves. It doesn't verify that the reasoning is true, and it doesn't guarantee that an agent will consult it.
Pinning the path makes routes agree on a file. It doesn't create records nobody saved.

Selvedge 0.3.17: test your agent memory before you rely on it

Sat, 17 Oct 2026 16:10:57 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released v0.3.17 documentation.

A coding agent can tell you it saved a decision. The useful test comes later: close the session, start again, and retrieve the same record. Can you recover the reason you rejected an approach, or just a convincing explanation of the code that remains?

Selvedge gives compatible AI agents persistent decision memory through a local MCP server or the CLI. You save a choice, its reason, and the alternatives you ruled out against a named part of your project: a function, database column, API route, or dependency. Those records live in SQLite under .selvedge/, so another session can query the same history.

Version 0.3.17 makes two parts of that workflow easier to check: whether the local MCP server can retrieve a decision after restarting, and whether the Markdown digest you bring to review still matches the stored history.

Test the local MCP server

With uv installed, you can try the first check without connecting an agent or touching a project's decisions:

uv tool install --upgrade selvedge==0.3.17
selvedge demo --mcp

The command starts a real local stdio MCP server, saves a synthetic rejected approach through it, shuts that server down, and starts another. It then checks that retrieval returns the same record ID and content. Add --json to get the checked IDs and version information in machine-readable form.

The data is disposable. The demo uses a temporary database, skips background update and telemetry checks, and has a deadline followed by subprocess cleanup. That makes it a useful first step when evaluating the package: a small, concrete persistence check with no invented project history left behind.

It also has a precise boundary. A passing result checks the Python installation running Selvedge and that local MCP exchange. Your editor may launch a different executable, point at a different database, or require you to enable tools. The demo cannot establish that your agent's configuration or lifecycle hooks are active.

Try one real decision across two sessions

The next test belongs in your own workflow. Follow the quickstart, connect your agent, and ask it to save one real decision with the reason and any rejected alternative. Keep the entity path and record ID. Then open a fresh session in the same project and ask it to retrieve that decision. Compare the result with what you saved.

That is also where to test usefulness. Suppose you kept a dependency because its replacement lacked a feature you needed. Retrieving that constraint gives the next session something specific to check before attempting the replacement again. Only explicitly saved decisions can be recovered, and recorded reasoning still needs judgment: Selvedge stores the account supplied by you or your agent; it cannot establish that the account is correct or complete.

Check the digest before review

The second addition addresses what happens when those records reach a review. Selvedge already exports a deterministic Markdown digest. Once you have project history, generate it with:

selvedge export --format markdown -o DECISIONS.md

Version 0.3.17 adds a check you can run before review or in CI wherever that same history is available:

selvedge export --format markdown -o DECISIONS.md --check

If the file matches, the command exits successfully without output. If it is stale or missing, it exits with status 1 and a unified diff. The check preserves both the digest and the stored records; it does not initialize or migrate the database. Read failures produce guidance, and invalid arguments return status 2.

This gives a reviewer a straightforward consistency check. A digest can look reasonable while omitting a recently recorded decision. The check makes that drift visible. It does not validate the decisions themselves or fill gaps in capture. Review the exported reasoning before sharing or committing it.

There are smaller fixes with the same aim of making the record easier to interpret. Human-readable output now distinguishes an approach considered and rejected from a change tried and reverted. Literal bracket characters in logged text no longer cause the affected CLI rendering failures. The release adds no runtime dependencies, migrations, or MCP tools.

If you use a coding agent on a project you regularly return to, try one decision across two sessions. A local stdio MCP connection works; an agent with shell access can use the CLI. No hosted account is required, and core storage and retrieval make no LLM calls. The repository has the source and release notes. Feedback about where saving or retrieving that first real decision breaks is especially useful—share it in the existing trial discussion.

Twenty Security Checks Before Your MCP Server Goes Public

Fri, 16 Oct 2026 16:17:59 +0000

An MCP server is effectively an API that agents call for people, and that gives it an unusual set of risks. The caller is a model that text from elsewhere can steer, the human may never see individual calls, and whatever you return might be read by yet another model. Most problems are familiar API errors amplified by that chain, so this checklist groups twenty checks by layer, with the reasoning for each.

Transport: HTTPS only, validate the Origin header on every request (the spec requires it, to stop DNS rebinding), bind local servers to localhost and treat session IDs as untrusted. Authorisation: decide per tool what's public, publish protected-resource metadata, validate token audience and never pass a client's token through to another API.

Input: validate every argument server-side, bound lengths and counts, never accept raw SQL, shell or file paths, and parameterise database calls. Output and prompt injection: treat submitted text as hostile, keep tool descriptions honest and static (changing them after approval or hiding instructions in them are known attacks), and return only what the output schema promises.

Abuse and operations: rate-limit by IP and tool, annotate tools truthfully but enforce rules server-side too, cap anything that pings a human, return safe errors and log calls. I end with simple ways to test your own server.

Key takeaways

Validate the Origin header on Streamable HTTP endpoints
Never forward tokens issued for someone else
Reject raw query, shell or path arguments
Keep tool descriptions static and honest
Rate-limit write tools and log every call

Related on BuiltToWinWeb: how to add an MCP server to a website

Read the full guide on BuiltToWinWeb: The MCP server security checklist

A summary by Jacob Campbell of an article first published on built2winweb.com on October 5, 2026.

Putting a Public MCP Server on Your Website, Safely

Fri, 16 Oct 2026 16:16:36 +0000

The Model Context Protocol is the open standard assistants use when they call tools. Most people use it to connect an assistant to their own apps, but it works in the other direction too: a business site can run its own MCP server, letting any assistant check services, prices, hours and availability, or send a request, directly. A crawler sees whatever you published weeks ago; a tool call returns what's true now.

In this guide I suggest which tools a business site should expose (read-only lookups like services, hours and service area, plus perhaps one write tool for quote requests) and explain the transport. Since the March 2025 revision of the spec, remote servers use Streamable HTTP: a single endpoint that accepts JSON-RPC by POST and runs on ordinary hosting.

Two later additions matter for public servers. Tool annotations tell clients whether a tool is read-only, destructive, idempotent or reaches outside your system, so they know when to ask the user first. Output schemas let tools return typed, checkable data. For anything needing authorisation, the spec builds on OAuth and expects protected-resource metadata at a well-known path.

The security list is the part to follow closely: expose facts rather than systems, validate every argument, rate-limit write tools, never leak secrets in errors, treat submitted text as untrusted, validate the Origin header and log calls.

Key takeaways

A site's MCP server answers with current facts, not crawled ones
Remote servers use the Streamable HTTP transport
Annotate tools so clients know which are read-only
Validate input and rate-limit any write tool
Advertise the server through discovery files and registries

Related on BuiltToWinWeb: the 20-point MCP server security checklist

Read the full guide on BuiltToWinWeb: How to add an MCP server to your website

A summary by Jacob Campbell of an article first published on built2winweb.com on October 5, 2026.

My AI assistant kept choking on huge PDFs. Here's what actually helped.

Thu, 15 Oct 2026 05:11:25 +0000

Maybe this is obvious to some of you but it drove me up the wall for weeks, so posting in case it helps someone else.

I do a lot of contract and document work. My setup is basically an AI assistant that I talk to about files all day. The model is plenty smart. The problem was never the brain — it was the mouth being too full.

I'd drop a 200-400 page PDF into the chat and ask it to pull out the key clauses. Half the time it would clearly miss the back third of the document. Sometimes it just timed out. Other times I'd look at the token usage and decide I'd rather do it by hand than pay to ship a whole scanned book into the context window. So I'd bail, open a separate compressor, run it, check it didn't nuke the pages, paste it back, and try again. Every single time I did that, I lost the thread of what I was actually trying to do.

That exit-and-return loop is the real killer. It's not that compression is hard. It's that having to DO the compression manually, outside the conversation, kills the whole "just talk to it" advantage.

What finally worked for me was stopping thinking of compression as my job and making it the assistant's job. There's a local service I found (it's an MCP thing — if you search "compress-mcp" you'll find it) where the agent just shrinks the file on a single instruction, on my own machine, and the data never leaves my network. I don't open another app. I just say "compress this before you read it" and it happens.

A few things that surprised me:

The tokens thing is real and bigger than I expected. Images especially. A raw high-res scan is largely garbage pixels the model pays to ingest but doesn't need. Shrink ahead, then send, and the bill drops a lot. One measurement I saw put image token cost down around 85.9% on a GPT-4o basis after compressing. Not a magic number, but multiply that across a day of docs and it adds up fast.
Local matters more than speed for me. I deal with contracts. I am not uploading those to some random SaaS to get them compressed. The fact that it runs here, on my box, with sensitive-stuff detection also local, is the reason I could use it at all. If it required a cloud upload, I'd have said no immediately.
It removed a daily micro-annoyance, not a dramatic one. I had a 443-page tendering doc that always timed out raw. With local compress-ahead it processed end to end in about two minutes and then the assistant actually read the whole thing. Small win, but it's every day.

A broader thing I've been thinking about: IDC estimated document-related issues are like 21.3% of enterprise productivity loss, which they translated to ~$19,732 per info worker per year. That sounds made up until you live the "it cut off again, re-send, re-read" loop fifty times a week. The fix isn't a smarter model. It's removing the boring step that breaks your flow.

One detail I didn't expect: once the assistant could prep its own input, I started trusting it with messier material. Before, I treated it like a finicky machine that might choke, so I'd pre-clean everything by hand. After, I just handed it the folder. That trust is the actual upgrade — more than any speed number. A tool you can throw a giant pile of files at without a second thought is doing its job.

I also stopped building a "don't put this in the chat" list in my head. Because everything goes through the same local path and the sensitive check runs on-device, the privacy boundary holds by construction rather than by me remembering a rule. For a solo worker that's a relief; for a team it's the thing that lets people actually adopt the tool instead of quietly routing around it.

If you're evaluating options, don't overthink it. Ask yourself: does the file ever contain something you wouldn't upload to a stranger's server? Do you process big docs often enough that manual compression became a chore? Are you building on an assistant rather than just chatting? If yes, a local, callable compression layer is worth a look. If you occasionally shrink the odd image for a group chat, your phone already does that and you don't need anything heavier.

One framework I use to decide, in case it's useful:

Data residency: does the file stay local, and is sensitive detection on-device?
Invocation: can the agent call it in plain language, or do you run it by hand?
Integration cost: do you write glue per platform, or is there a standard protocol?
Fit: high-frequency large/confidential files, or occasional light tasks?

Before this I tried the obvious stuff. I set up a hotfolder and a script that watched it and compressed anything dropped in. It worked, kind of, but it was yet another thing to maintain, and the assistant still couldn't trigger it mid-conversation. The local agent-callable version won out because it met the work where it already was. If you go the script route, fair enough, just know the friction is in the handoff, not the compression.

Anyway, the point isn't the tool, it's the pattern: stop being the one who preps the file. Let the thing that's going to read it also shrink it. Do that locally and you stop worrying about where the bytes go. Simple change, outsized calm.

I'm not affiliated with anything here, just a guy who got tired of fighting his own files. The shift from "I compress, then the AI reads" to "the AI compresses, then reads" sounds tiny and it's the single noticeable quality-of-life change in my workflow this year. If your assistant keeps choking on big PDFs, that's probably the seam to fix early.

Anyway, hope this helps someone. Happy to answer questions about the fully local setup if people are curious, and if you've solved this a different way I'd genuinely like to hear it.

CloudPloy: Deploy anywhere from your AI

Wed, 14 Oct 2026 23:17:09 +0000

CloudPloy: Deploy anywhere from your AI tool.

Add an API key. Your agent deploys from Claude Code, Cursor, or any MCP client. Bring your own Ubuntu/AWS server or provision Hetzner/DigitalOcean/AWS at cost. Flat plan for the control plane; compute at the provider's rate.

Pricing: Free forever (1 small server, 1 app). Starter $9.99 / Pro $19 / Scale $39.

How to evaluate agents with one trace across MCP, A2A and Realtime

Wed, 14 Oct 2026 16:22:41 +0000

A support agent passes every eval in staging. In production the same agent is reached three ways: from an IDE over MCP, from the web app over the OpenAI Responses API, and from a triage agent over A2A. The dashboard stays green for weeks. Then a customer escalation shows the triage agent handed over a ticket without the customer's region, and the support agent quoted the refund policy for the wrong country. No evaluator flagged it, because no evaluator ever looked at the hop.

The reason is structural. Eval is a property of the path a request took, and the protocol defines the path. Most eval stacks were written against one surface, usually chat completions, so they score whatever still looks like a chat completion and quietly skip the rest. A protocol-neutral eval stack scores the path instead, whichever protocol carried the request.

Every protocol adds seams to the path

A plain chat completion has one path: prompt in, response out. One rubric can grade it. Each protocol you add forks that path into more decision points, and each decision point needs its own check.

MCP adds a tool catalog. The path becomes prompt, tool descriptor list, tool selection, call arguments, tool result, final answer. Score each tool call against policy, and score the catalog as a whole, because a poisoned descriptor looks fine at call time and only shows up against the full catalog.
A2A turns the path into a tree. Every hop needs three answers: did the calling agent pass enough context, did the called agent stay in scope, and did the returned artifact match the task that was asked for.
The Responses API puts three outputs in one envelope. Structured JSON gets graded against a schema, streamed text gets graded as it arrives, and a tool call gets graded against a per-tool policy. One end-to-end pass mixes three things that share nothing except the wrapper.
Realtime has no final message. Audio streams in both directions, so checks have to run mid-stream, every N tokens or N audio chunks, with a stop or disclaimer action when a rule fires. The end-to-end budget sits below 500ms, which caps how heavy each check can be.
Inline vision needs a second judge. When images ride in the same message as tool blocks, the text portion and the image portion need different rubrics, and the image rubric needs a judge that can open the image.
Session state spans turns. On a framework with explicit session state, the evaluator has to read state across turns instead of grading each turn alone.

Trace fidelity caps eval fidelity

An evaluator can only score what the trace can represent. If your trace has no way to express an agent-to-agent hop or a streaming chunk, no rubric downstream will catch a failure inside one.

So the first fix is in instrumentation, before any rubric work:

Model both sides of a hop. Emit one span kind on the calling agent and another on the called agent, and carry the trace ID across the wire so the whole multi-agent path lands in one trace.
Give each modality its own span kind. Voice, image and computer-use spans should be distinguishable from text spans, so each one reaches an evaluator built for that modality.
Record guardrail and evaluator results as spans. When a guardrail decision and an evaluator score sit in the same trace as the model call, you can see which check ran on which step.

The MCP spec helps here. The 2026-07-28 revision documents trace context propagation through _meta (traceparent, tracestate, baggage), so MCP tool calls can join the same trace as the rest of the agent loop.

Normalize the spans, then write each rubric once

The same agent identity shows up differently on every protocol. If you write a groundedness check against raw MCP payloads and another against raw Responses payloads, you now maintain two checks that drift apart.

Normalize first. Map every span to one semantic convention, such as the OpenTelemetry GenAI conventions, before any evaluator reads it. Then write rubrics against the normalized trace. One groundedness rubric can then grade a RAG answer that arrived over the Responses API and a RAG answer that arrived over MCP, and one task-completion rubric can grade the support agent no matter which client reached it.

This is the same move observability teams made with OpenTelemetry. Teams that locked to one vendor's tracing format rebuilt their instrumentation every time they switched vendors. Agent protocols are repeating that pattern one layer up.

Gate releases per protocol

A single overall score hides which surface regressed. A drop in the MCP tool-audit rubric and a drop in the Realtime guardrail are different failures with different fixes.

Keep a regression dataset per protocol surface. Run the matching rubric set against it on every change.
Set a threshold per protocol. Fail the release when any one surface drops below its own threshold, even if the blended number looks fine.
Key each suite on protocol and version. MCP's 2026-07-28 revision removed the initialize handshake, so every request now carries its protocol version in _meta, and the new deprecation policy gives every deprecated feature a minimum twelve-month window. Tag each regression case with the revision it ran on, and keep the tests for deprecated features until their window closes.
Keep the rubric sets in the repo as code. Reviewers should be able to read exactly what gets scored on each surface.

A five-step readiness audit

Inventory every surface in production. MCP servers, A2A endpoints, streaming, voice, vision and computer-use, with the protocol version and client library for each. Most teams find one they did not plan for, usually an MCP server a developer installed last sprint.
Instrument and pull one real trace per surface. Confirm the hop spans appear on both sides with the propagated trace ID, and that voice and image calls emit their own span kinds. Fix gaps before writing rubrics.
Write the rubric set for each protocol. Per-tool audit on MCP, per-hop audit on A2A, split rubrics on the Responses API, mid-stream checks on Realtime, an image-capable judge for vision.
Run a per-protocol regression suite and gate on per-protocol thresholds.
Cluster production failures by protocol. Failures that look like noise one at a time often form a pattern once you group them by surface.

If you only have half a day, do step 1. The list is usually longer than the team expects, and it tells you which evaluators are scoring the wrong path today.

Pitfalls that keep showing up

Evaluators hard-coded to the chat completions shape. Every new protocol triggers a rewrite.
Scoring each agent in isolation. The end-to-end view looks green while a handoff in the middle dropped context.
Post-call checks only on streaming surfaces. By the time the evaluator sees the output, the risky tokens are already on the wire.
Accepting tool descriptors from any MCP server without a scan. An untrusted server can change what your agent does, and the eval layer never sees it.
Scoring voice and computer-use on text alone. Errors at the ASR layer and the vision layer stay invisible.

The span kinds, the rubric set for each of the six protocols and the full audit are in the longer protocol-neutral eval playbook.

New protocols and revisions will keep arriving. Score the path the request took, and each new surface plugs into a trace model and a rubric library you already maintain.

Discussion: What does it take to make an MCP server production-ready?

Wed, 14 Oct 2026 14:33:00 +0000

A local MCP server can be straightforward to run. Production deployments introduce different requirements when agents interact with remote APIs, databases, and execution environments.

Our new SEOSiri guide examines several important areas:

Scoped authentication and authorization

Secure SSE-based remote communication

Stateless service design

Response pruning and pagination for token efficiency

Sandboxed execution for dynamic code

The central engineering question: how do you give an AI agent useful capabilities without granting unnecessary access or creating avoidable operational risk?

Read the technical breakdown:
https://www.seosiri.com/2026/10/building-mcp-servers-production-security.html

For developers working with MCP, AI infrastructure, and DevSecOps.

Why AI Coding Agents Need a Feature Flag Firewall: Inside Spotify Confidence MCP + ThumbGate

Wed, 14 Oct 2026 14:18:03 +0000

Why AI Coding Agents Need a Feature Flag Firewall: Inside Spotify Confidence MCP + ThumbGate

Spotify's experimentation team just announced "A New Chapter for Confidence" (October 14, 2026), launching Confidence Agent, Session Recordings, and official MCP servers for Claude Code, Cursor, and Codex (https://mcp.confidence.dev/mcp/flags).

This is a massive leap forward for agentic software development: instead of a human engineer manually creating flags, setting rollout percentages, and monitoring A/B test sample sizes in a web dashboard, an AI coding agent can do it directly through natural language in their editor.

But giving autonomous AI agents direct write access to production feature flags introduces an entirely new catastrophic blast radius.

The Three Failure Modes of Autonomous Flag Mutation

Premature 100% Rollouts:
An autonomous agent refactors a checkout component or backend service. To "verify" its work, it calls set_rollout to 100% in production before automated integration tests pass or without running a canary slice.
A/B Experiment Pollution:
An agent modifies user variant allocations, sample sizes, or targeting criteria mid-experiment, destroying statistical validity and costing the business tens of thousands in unrecoverable experimentation bias.
Destructive Flag Purges:
During automated dead-code cleanup, an agent purges a legacy feature flag because it cannot find references in one repository, unaware that a mobile client or upstream microservice still relies on the flag schema.

The Architecture: Pre-Action Feature Flag Diodes

At ThumbGate, we built the Pre-Action Infrastructure Firewall for Spotify Confidence MCP.

Before an agent executes any mutation via https://mcp.confidence.dev/mcp/flags, ThumbGate intercepts the tool call in sub-0.5ms and enforces deterministic governance diodes:

[ AI Coding Agent: Claude / Cursor / Codex ]
                  â
                  â¼
       [ Proposed MCP Tool Call ]
       (e.g., set_rollout: 100%, flag: "new-checkout")
                  â
                  â¼
   [ ThumbGate Infrastructure Firewall (<0.5ms) ]
   âââ gate:confidence:rollout_ceiling
   â   ââ Is rollout > 10%? âââº [BLOCK: Require Human Sign-Off]
   âââ gate:confidence:test_proof_required
   â   ââ Tests failing? ââââââº [BLOCK: Require Same-Turn Test Proof]
   âââ gate:confidence:protect_active_experiment
       ââ Active A/B test? ââââº [BLOCK: Experiment Allocation Locked]
                  â
                  â¼ (If Verified & Bounded)
    [ Allowed -> Passthrough to Spotify Confidence API ]
                  â
                  â¼
         [ mcp.confidence.dev ]

Key Pre-Action Diodes Implemented

gate:confidence:rollout_ceiling (Max 10% Autonomous Canary):
Autonomous agents are hard-capped at 10% canary traffic. Expanding beyond 10% requires an explicit operator confirmation token.
gate:confidence:test_proof_required:
Blocks creating or updating feature flags while the repository's CI or local test suite is failing.
gate:confidence:protect_active_experiment:
Protects live A/B tests against autonomous parameter mutation.
gate:confidence:prevent_flag_deletion:
Prevents deleting flags in production environments. Flags must follow an explicit deprecation and archive lifecycle.

How to Protect Your Agentic Tooling

If your engineering organization is adopting agentic workflows, MCP servers, and autonomous coding tools like Cursor, Claude Code, or Codex, never grant unconstrained write access to production infrastructure without a pre-action firewall.

ð Install the ThumbGate Pre-Action Firewall for your team: https://thumbgate.ai/go/pro ($19/mo)
ð Deploy a verified feature-flag safety diode on your production stack this week: Book a Workflow Hardening Diagnostic ($499).

MCP connected, hooks inactive: lessons from five coding-agent adapters

Wed, 14 Oct 2026 00:48:27 +0000

Originally published on DEV on September 24, 2026. This cross-post preserves that article’s version-specific implementation and test results.

An agent can successfully call an MCP server while its lifecycle hooks never run. The server connection and the hook process have separate configuration, execution environments, and trust checks.

That distinction mattered while extending Selvedge's native hooks beyond Claude Code in version 0.3.15. The release adds adapters for Codex, Cursor, Gemini CLI, VS Code Copilot's Local harness, and Windsurf/Cascade. The useful engineering lesson is how to separate shared behavior from each client's protocol—and how to prove the integration actually ran.

Disclosure: I maintain Selvedge. This article was drafted with AI assistance and checked against the released implementation and recorded test evidence.

Keep the decision logic separate from the protocol

The feature in this example checks whether an agent has consulted recorded decisions before a supported edit to a watched schema or migration path. A saved rejection might explain that a column cannot be removed because an importer still needs it.

The adapter has three jobs:

native client payload
  -> normalize project, session, tool and affected paths
  -> evaluate the shared decision check
  -> encode the result in the client's response format

The shared check shouldn't need to know whether a client calls its shell tool Bash, Shell, or run_shell_command. Conversely, the response encoder must know which fields—or exit status—the client recognizes.

The released adapters make these mappings explicit. For example, the Codex apply_patch payload supplies patch text in tool_input.command; the VS Code Local apply_patch payload uses tool_input.input. Treating those tools as interchangeable would lose the files the check needs to inspect.

Similar event names don't imply identical configuration

These are the project files and pre-edit events used by the five new adapters:

Client target	Project hook configuration	Event used for the edit check
Codex	.codex/hooks.json	PreToolUse
Cursor	.cursor/hooks.json	preToolUse
VS Code Copilot, Local	.github/hooks/selvedge.json	PreToolUse
Gemini CLI	.gemini/settings.json	BeforeTool
Windsurf/Cascade	.windsurf/hooks.json, or existing .devin/hooks.json	pre_write_code, pre_run_command

The table describes this implementation's supported targets, not every harness sold under those product names. In particular, VS Code Local support doesn't establish support for Copilot CLI, cloud sessions, or Agent Host.

Configuration shape also differs: copying the same event name into each JSON file is insufficient. Installers need to validate existing structures, preserve unrelated hooks, back up modified files, and surface conflicts rather than silently replacing customized commands.

Project identity deserves the same care. If a multi-root workspace payload doesn't identify an unambiguous current directory, checking another repository's decisions would be worse than reporting that the check couldn't be applied.

A notification isn't saved context

All five new adapters implement the watched-edit check. Four also provide a startup digest and a user notification before compaction. The Windsurf adapter provides neither startup context nor a compaction notification.

Those are different capabilities:

A startup digest supplies selected saved context at a supported startup event.
A pre-edit check can delay a supported tool call until the lookup requirement is satisfied.
A compaction notification tells the user something. It doesn't make the model save a decision, and it isn't model-context injection.

Calling all three “memory preservation” hides the distinction users need when debugging. Explicitly recorded rationale is also different from a model's hidden reasoning; these adapters don't inspect hidden reasoning or read chat transcripts.

Test installation, invocation, and behavior separately

A generated hook file proves configuration was written. A successful direct invocation proves a script accepts a particular payload. Neither proves the client will launch it.

For a real-client test, use a disposable project and inspect this sequence:

Seed one synthetic rejection against a watched file.
Review and enable the hooks through the client's normal trust controls.
Attempt the relevant edit before retrieving history; inspect the actual denial.
Retrieve the saved decision, retry, and inspect the final file.
Test an ordinary source edit and a read operation independently.

The recorded native test used Codex CLI 0.154.0-alpha.6.2. It observed an apply_patch denial, a real prior-attempts CLI lookup, then an allowed retry with the resulting file checked. It used normal hook trust and an absolute executable path with a local payload recorder. Earlier isolated runs that ignored user configuration never invoked the project hooks; they were excluded from the successful result.

The other four new clients have automated payload, configuration, SQLite, and subprocess coverage, but haven't been verified end to end in those clients. Startup and compaction behavior also remains contract-tested. That's the difference between implementing an adapter and observing it work in a particular client version.

State the limits of the check

This check covers known mutating tool schemas and configured watched paths. Shell write detection is heuristic. Unknown payloads, missing project databases, and internal evaluation errors fail open, so it is workflow assistance rather than a security boundary.

The existing lookup window can also be satisfied by a recent query from another session. An allowed edit therefore doesn't prove this particular agent understood the decision—or that the old constraint still applies. Retrieval, correct application, and a successful code change need separate evidence.

The next diagnostic improvement is to report configuration and observed hook execution separately. A single “connected” status cannot establish both.

Protocol references: Codex, Cursor, VS Code Local, Gemini CLI, and Cascade. The contracts cited by this implementation were checked September 24, 2026; client versions can change them.

Crossmint's Agent Commerce Toolkit is live

Tue, 13 Oct 2026 01:42:57 +0000

Crossmint's Agent Commerce Toolkit is live — one integration lets an AI agent pay with any card at any online store.
What it does well: card entry goes straight to a PCI-compliant vault; eligible cards get scoped Visa Intelligent Commerce / Mastercard Agent Pay credentials (spend limits, expiry); and each checkout path is chosen by availability, reliability and cost — embedded checkout, Universal Commerce Protocol, or browser automation.
What it does not do: score whether the purchase itself should fire. A spend limit is a ceiling, not a judgment.
We tested the gap live on October 12, 2026 against a public decision gate: a $240 unverified-merchant buy scored 0.4121 (escalate/block+log) and a scoped, user-approved $42 reorder scored 0.4654 (also escalate) — a blunt gate blocks both, which is why the decider has to be calibrated, not just present.
Full analysis: https://scriptmasterlabs.com/crossmint-agent-commerce-toolkit
Decision Capsule + 5 specialized Jev jurors + non-overridable constitution. Jev chooses. Code decides. Built for agents that manage real capital.

Quant #AlgorithmicTrading #MarketStructure #AgenticAI #AIFinance #FinTech #InstitutionalTrading #RiskManagement #MCP #x402 #AgentEconomy #DecisionLayer $USDC

The Reliability Boundary: What AI Agents Need Before They Touch Production APIs

Sun, 11 Oct 2026 08:43:40 +0000

AI agents are moving from chat interfaces into real business workflows. They can search customer records, update accounts, trigger deployments, and initiate financial operations. That creates a practical engineering question: what should happen between an agent's decision and a production API call?

In a conventional backend, a request passes through authentication, authorization, validation, rate limits, transaction boundaries, observability, and error handling. Agents need those controls too. They can also misunderstand intent, follow malicious instructions embedded in retrieved content, retry an operation after a timeout, or select the wrong tool.

The answer is a reliability boundary: a layer that treats the agent's output as a proposal and makes the final decision through deterministic policy and backend services.

Separate reasoning from execution

An early architecture often looks like this:

User → AI agent → MCP tool → Production API

That path assumes the agent can decide when and how a business action should happen. For sensitive operations, use a more explicit path:

User request
    ↓
AI agent proposes an action
    ↓
MCP tool or tool gateway
    ↓
Policy, risk, and reliability boundary
    ↓
Validated command → Production API
    ↓
Audit events and reconciliation

The boundary checks identity, permissions, business rules, duplicate requests, state transitions, and the eventual outcome. This is familiar territory for payment and distributed systems: a syntactically valid request is only the start of the decision.

Why an API gateway is not enough

An API gateway can authenticate a caller, route traffic, enforce rate limits, and record access. It usually cannot determine whether an agent misunderstood the user's instruction, whether a retrieved document contained prompt injection, whether a selected tool fits the task, or whether the requested change is consistent with the current business state.

Those checks require application policy. The backend that owns the data or action must remain the final authority.

A production lesson from banking modernization

At UST, I worked on a Capital One modernization effort as SAS-based operational and business reporting was being moved toward Salesforce. The people using those reports were service agents, not AI agents. My part of the work included designing Spring Boot GET APIs for fraud/security, Section 78, and exception reporting, integrating the services with Snowflake, and exposing the endpoints to the Salesforce team.

The production question was broader than whether an endpoint returned the right JSON. A service agent had to see only the reports allowed by their role; the API had to apply that rule even when Salesforce was the caller. We worked with architects and product owners on the service design, used role-based access and business rules, and tested the contracts and behavior. JMeter and Gatling performance tests helped us check whether the services could meet SLA expectations under load. Docker, Kubernetes, and the DevOps workflow made deployment and operation part of the engineering responsibility, not an afterthought.

This was a read-oriented integration, not an AI agent making autonomous changes. Still, it taught a useful boundary lesson: moving a capability from one platform to another does not transfer the authority to decide who may use it. If an AI assistant were later allowed to retrieve one of these reports, its tool call would need to carry the human user's identity and scope. The backend would still enforce role access, validate the request, and record the outcome. An AI tool is another caller of a business capability; it is not a substitute for the controls around that capability.

A refund example

Imagine a customer tells an assistant, “Please refund my last order.” A basic agent may find the latest order and call a refund endpoint. A production workflow needs more answers:

Which customer is authenticated, and which order do they mean?
Is the order eligible under the current policy?
Has a refund already been requested or completed?
Is the amount within the caller's authority?
Does this amount or account require human approval?
If a tool call times out, how will the system discover its actual state?

A language model can interpret the request and prepare a proposed command. It should not make these policy decisions on its own.

Six controls for sensitive agent actions

1. Identity and narrow authorization

Do not give an agent a broad administrative token. Resolve the authenticated user's identity and grant the tool only the capability required for this workflow. Reading an order and issuing a refund are different permissions:

orders.read
refunds.preview
refunds.request
refunds.approve

Enforce authorization again in the backend. An MCP server is an integration layer; its presence does not remove the need for service-level authorization.

2. Structured commands and validation

Do not pass unrestricted prose to a state-changing API. Define a typed command with required fields and constraints:

public record RefundCommand(
    String customerId,
    String orderId,
    BigDecimal amount,
    String currency,
    String reason,
    String idempotencyKey
) {}

The agent may suggest initial arguments. The backend must check the authenticated identity, ownership, amount, currency, eligibility, and current state before accepting the command. Schema validation catches malformed inputs; business validation catches unsafe actions.

3. Idempotency and duplicate protection

Agents retry after timeouts, uncertain tool results, and orchestration failures. A retry must not create a second refund. Assign a stable idempotency key to the business operation, and persist the result associated with it. If the same operation is requested again, return the existing result.

First request: refund-order-7842 → REFUND_ACCEPTED
Retry:         refund-order-7842 → same recorded result

The key must remain stable across retries. Generating a fresh key on every attempt defeats duplicate protection.

4. Risk-based human approval

Approval should follow a policy, rather than being added after an incident. For example, reading an order may proceed automatically; a refund preview may be automatic after validation; a high-value refund or a change to bank details may require a person to review the exact payload.

The agent can prepare the action and explain it. Policy decides what is allowed. The human approves actions above the risk threshold. The backend validates and executes the final command.

5. Auditability

A production workflow should leave more than a chat transcript. Record the authenticated actor, workflow and tool identifiers, input arguments, policy decision, approval, correlation ID, idempotency key, backend response, and final business outcome. Exclude secrets and unnecessary personal data from logs.

{
  "eventType": "REFUND_REQUESTED",
  "workflowId": "wf-8271",
  "actor": "user-442",
  "resource": "order-7842",
  "policyDecision": "APPROVED",
  "idempotencyKey": "refund-order-7842",
  "correlationId": "corr-91a7"
}

These records support incident investigation, customer disputes, and reconciliation.

6. Reconciliation

A timeout does not prove failure. The backend may have accepted the action while the agent missed the response. Before retrying, look up the operation by its stable identifier and ask the system of record for its actual state.

What is the current state of refund-order-7842?

The final business outcome should come from the system of record, not the model's interpretation of a partial tool response.

Where MCP fits

Model Context Protocol (MCP) offers a standard interface for exposing tools and resources to AI applications. That can simplify integration, but it does not replace identity management, authorization, input validation, transaction handling, audit logging, approval, or reconciliation.

Expose controlled business capabilities, such as preview_refund(order_id, reason). Avoid tools that give an agent unrestricted database queries or administrative operations. Tool descriptions help an agent choose an action; backend policy determines whether the action may run.

Reference architecture

User request
   │
   ▼
AI agent ── proposes tool call ──► MCP tool server
                                      │
                                      ▼
                               Policy and risk engine
                                      │
                       ┌──────────────┴──────────────┐
                       ▼                             ▼
                Human approval                 Automatic path
                       └──────────────┬──────────────┘
                                      ▼
                          Validation + idempotency
                                      │
                                      ▼
                              Backend API
                                      │
                                      ▼
                          Audit + reconciliation

The key component is the policy and reliability layer between the model and the business operation. It keeps the model from becoming the final authority over sensitive actions.

What teams should measure

Response accuracy is only one measure of agent quality. Also track invalid tool calls, policy rejections, duplicate prevention, retry frequency, approval rates, time to reconcile uncertain operations, audit completeness, and recovery time after failures.

An agent that answers fluently but cannot explain or reconcile its actions is not ready for production.

Conclusion

The most useful enterprise agents will have bounded, observable, and recoverable autonomy. They can move quickly while the system verifies identity, permissions, business state, and outcomes. MCP helps connect agents to tools; a reliability boundary makes those connections safe enough for real work.

References

Most Developers Are Building AI Agents Wrong: MCP Is the Missing Contract

Sun, 11 Oct 2026 07:48:38 +0000

AI agents are easy to demo and difficult to trust.

A developer can connect a language model to a few tools in an afternoon. The first demo looks impressive: the agent reads a request, calls an API, checks a database, and returns an answer.

Then production arrives.

The agent calls the wrong tool. It sends an incomplete payload. It retries a payment operation. It exposes information from another tenant. Nobody can explain why it made a decision.

The problem is not always the language model. The deeper problem is that many teams are building agents without a clear contract between the model, the tools, the data, and the people responsible for the outcome.

That is where the Model Context Protocol, or MCP, becomes important.

An AI agent is more than a chatbot

A useful enterprise agent usually has five parts:

A model that reasons about the request
Instructions that define its role and limits
Tools that allow it to read or change systems
Memory or context that helps it understand the task
Guardrails that control what it is allowed to do

A chatbot mainly generates text. An agent can take actions.

That difference changes the engineering problem completely. If an agent only produces an explanation, an inaccurate response may be corrected by a human. If an agent can approve a refund, change a production configuration, or submit a healthcare request, an inaccurate response becomes an operational incident.

The agent must therefore be treated like a distributed system with an unreliable reasoning component.

The tool boundary is the real architecture

Many early agent implementations expose tools with a name, description, and input schema. That is not enough for production.

A safe tool contract must answer several questions:

Which user or tenant is the agent allowed to access?
Which values are valid?
Does the operation require approval?
Is the operation idempotent?
What happens if the network times out after success?
How is the action audited?

A tool description is not a security policy. It is only the beginning of a contract.

Why MCP matters

MCP provides a standard way for AI applications to discover and use external tools and resources. Instead of building a different integration for every model and every application, teams can expose capabilities through a consistent protocol.

That standardization is valuable, but it does not automatically make an integration safe.

MCP should be treated as an interoperability layer, not as permission to give an agent unrestricted access to a system.

A production MCP tool should define:

A clear business purpose
Read or write classification
Authentication and authorization requirements
Tenant and data-scope restrictions
Input validation
Idempotency behavior
Timeout and retry rules
Rate limits
Audit events
Human approval requirements
A safe failure response

The most important design principle is simple:

The model may request an action, but the platform must decide whether that action is allowed.

A safer agent flow

A reliable enterprise agent should follow a controlled sequence:

User request -> identity verification -> permitted context -> model plan -> policy evaluation -> human approval when required -> MCP tool execution -> result validation -> audit event -> user response

The model should not directly own the complete workflow. It should operate inside one.

For example, an agent may propose: Cancel this payment.

The policy layer should check whether the user is authenticated, whether the payment belongs to the user organization, whether it is still cancellable, whether the amount exceeds an approval threshold, whether the request was already processed, and whether the downstream tool is healthy.

Only after these checks should the action reach the payment service.

MCP and Spring Boot

A practical Java implementation can place an agent gateway in front of domain services.

The gateway can provide:

Spring Security authentication
OAuth2 or JWT validation
Tool-level authorization
Request and response schemas
Correlation IDs
Rate limiting
OpenTelemetry traces
Approval workflow integration
Central audit logging

The domain service should still enforce its own business rules. Never assume that because a request came from an AI gateway, it is trustworthy.

A safe execution model is: validate the user, evaluate policy, validate the tool input, enforce idempotency, call the domain service, validate the result, and record an audit event.

The model can select a tool. It should not bypass the same controls that apply to a human-operated API.

Read tools and write tools are not equal

Read-only tools may retrieve an invoice, search a knowledge base, or check an order status. Write tools may create a payment, update a customer, delete a document, or deploy software.

These categories should have different controls. A read tool may require normal user authorization. A high-impact write tool may require explicit confirmation, a second approver, a transaction limit, a dry-run mode, or a compensating action.

Do not hide a write operation behind a friendly name such as manage account. Use names that reveal the action and its risk: create refund, disable user, or deploy release.

Clear names help models, developers, reviewers, and security teams understand what is happening.

The biggest MCP security risks

MCP-based systems introduce familiar security risks in a new form.

Excessive permissions

An agent receives access to more data and tools than it needs. If the model or server is compromised, the blast radius becomes large.

Prompt injection

Untrusted content inside a document, webpage, or ticket attempts to influence the agent instructions. Retrieved content must be treated as data, not as a higher-priority instruction.

Confused deputy problems

The agent uses its own powerful credentials to perform an action on behalf of a user who does not have that permission.

Tool poisoning

A malicious or poorly maintained tool provides misleading descriptions, hidden side effects, or unsafe defaults.

Data leakage

The agent combines information from different users, tenants, or conversations and includes it in a response.

The solution is not one magic prompt. It is layered security: least privilege, isolation, validation, monitoring, and clear ownership.

Observability is not optional

Traditional application monitoring asks what request failed, which service was slow, and what status code was returned.

Agent observability needs additional questions:

What was the original user intent?
What context was retrieved?
Which tools were considered?
Which tool was selected?
What policy decision was made?
How many retries occurred?
Was human approval requested?
What data was returned to the user?

Every agent action should have a correlation ID that follows the request across the model gateway, MCP server, domain service, database, and audit system.

Without this trail, debugging becomes guesswork.

Start with narrow agents

The best first production agent is rarely a general-purpose assistant with access to the entire company.

Start with one bounded workflow:

Search internal documentation
Summarize support tickets
Validate an invoice
Classify incoming documents
Explain a failed transaction
Draft, but do not send, a customer response

Measure accuracy, latency, cost, refusal quality, tool-selection errors, and security violations. Then expand carefully.

A narrow agent with clear boundaries can create more business value than a general agent that appears intelligent but cannot be trusted.

The future of agents is controlled autonomy

AI agents will become more capable, but capability alone is not the goal.

The goal is controlled autonomy: systems that can complete useful work while remaining observable, explainable, reversible, and accountable.

MCP can help create a common interface between agents and the software world. But the protocol is only one layer. The real production architecture still needs identity, policy, security, resilience, testing, and human judgment.

The strongest agent teams will not ask only, What can the model do? They will also ask, What should the model be allowed to do, under which conditions, and how can we prove what happened?

That is the difference between an impressive demo and an enterprise system.

Final checklist

Before exposing an MCP tool to an AI agent, verify:

Is the tool purpose narrow and explicit?
Is access scoped to the authenticated user and tenant?
Are inputs validated independently of the model?
Are write actions idempotent?
Are high-risk actions reversible or approval-gated?
Are prompts and retrieved documents treated as untrusted data?
Are tool calls, policy decisions, and outputs audited?
Can the team trace a failed decision?
Is there a rate limit and emergency disable mechanism?
Does the system fail safely when the model is wrong?

If the answer to several of these questions is no, the agent is not ready for production.

It is ready for a better architecture.

A production agent architecture

flowchart LR
    U[User request] --> G[Agent gateway]
    G --> P[Policy and identity checks]
    P --> M[Model plan]
    M --> C[MCP server]
    C --> D[Domain service]
    D --> A[Audit and observability]
    A --> R[Validated response]

The model proposes the next action, but the gateway, policy layer, MCP server, and domain service each enforce their own boundary. This layered design prevents one incorrect model decision from becoming an uncontrolled production change.

Reference

Model Context Protocol official documentation

My coding agent kept "fixing" proxy errors wrong, so I built an MCP server

Sat, 10 Oct 2026 12:32:30 +0000

I work on proxy infrastructure, which means I read a lot of proxy errors. And I kept noticing the same thing: the coding agents I used were great at almost everything except this.

Give one a 407 and it would happily "fix" it by putting the proxy credentials into the target site's Authorization header. Show it a timeout on a POST and it would just retry, without asking whether the first request had already reached the server.

That's not the model being dumb. Proxy errors are a narrow area with a lot of confidently wrong answers floating around the internet, and the model has read plenty of them.

So I built a small MCP server that gives the agent grounded answers for this one area. It's free, open source and works with any proxy provider. Here's what I learned designing it.

1. Don't let the agent paste raw logs

The diagnose tool doesn't accept logs, URLs or credentials. It takes structured observations instead. This is a real input for the 407 case:

{
  "client": "requests",
  "version": "2.34.2",
  "phase": "connect_tunnel",
  "status": 407,
  "responseSource": "proxy"
}

Two reasons. Logs are full of things that shouldn't end up in a model's context, like credentials and session cookies. And the phase matters more than people expect. A 407 during the CONNECT tunnel is your proxy talking, not the website, so the fix is in your proxy config and never in the target's headers.

The schema is strict on purpose. Unknown fields are rejected, and responseSource should only say proxy or target when you actually know which layer answered, not because of the status code alone.

Every diagnosis comes back with likely causes, the next thing to check, and what it can't know. For the 407 above, the summary starts with this:

407 reports an intermediary authentication requirement. It does not identify a wrong password as the sole cause.

Retries got the strictest treatment. In the output schema, automaticRetryRecommended isn't a boolean. It's the literal false. The tool can only tell the agent what kind of retry thinking applies. Here's what comes back for a POST that timed out waiting for response headers:

"retry": {
  "automaticRetryRecommended": false,
  "category": "reconcile_before_repeating",
  "advice": "Do not automatically repeat POST/PATCH or an operation of unknown semantics. ..."
}

If a write timed out after it left your machine, the order might already exist. A missing response isn't proof that nothing happened, and the tool says so instead of letting the agent assume.

3. Credentials never go through the agent

Config templates use environment variable placeholders. No tool asks for a password as an argument, and no response ever contains one. If the agent never sees the secret, it can't paste it into a transcript, a log or a commit.

4. The one tool that touches the network is boring on purpose

Run locally, the server sends no telemetry and makes no network requests. There's one optional route check, and it stays off until you set IPVOLT_ENABLE_ROUTE_CHECK=1. Then it sends a single request through your proxy to one fixed endpoint, with a 10-second deadline, and that's all it can do. It can't be pointed at an arbitrary URL, so it can't be turned into a port scanner.

The hosted version keeps basic metrics: tool name, success or error, duration and toolkit version. Nothing about your requests.

5. Return structured data and text

Every tool has an output schema, and responses include both the structured result and the same result as text. Clients that read structured content get clean JSON they can pipe into the next step. Clients that don't still get a usable answer.

The trade-offs

Client versions are pinned. The diagnose tool only accepts the exact versions the rules were tested against: curl 8.22.0, Requests 2.34.2, HTTPX 0.28.1 and Playwright 1.63.0. That keeps the answers honest, but anyone on another version gets an error instead of a diagnosis.
The local package requires Node 24+. That rules out everyone still on Node 22.
The first npm release went out without build provenance. The next one should come from CI with provenance attached.

Try it

Use the hosted endpoint (https://mcp.ipvolt.com/mcp, Streamable HTTP, no signup or API key), or run it locally:

npx --yes @ipvolt/proxy-toolkit-mcp@0.1.0

Setup for different MCP clients is at ipvolt.com/mcp, and the code is on GitHub.

Full disclosure: I'm building ipvolt, a proxy service. The toolkit is provider-neutral and works fine without it.

If you've built MCP tools yourself: do you return structured data, text, or both? Curious what's worked for you.

11 Claude Code Gotchas That Quietly Skip Your Guardrails

Fri, 09 Oct 2026 05:28:57 +0000

Claude Code is now the harness a lot of AI engineers run agentic dev workflows through — interactive, headless with -p, through the Agent SDK, in CI, with subagents and a stack of MCP servers. The failure modes that matter are almost never in the setup guide. They're the quiet ones: an ask rule that never prompts, a checked-in .mcp.json that loads with no approval, a hook that fails open, an MCP call that can hang for a day.

Eleven gotchas a 3-year practitioner wouldn't already know (86 raw fragments → 22 candidates → 15 validated → 11 published). Numbers are the severity × rarity rank; sections group by theme (so the numbering is intentionally non-sequential). Each has a detection and a fix. Every threshold, TTL, timeout, block count, and cost figure is as of Claude Code v2.1.283 / September 2026 — re-verify before hard-coding. The GH#46829 20–32% and GH#97622 ~50,000-char figures are community-reported, not confirmed by Anthropic.

TL;DR — the 11, in rank order

#	Gotcha	One-line takeaway
1	`permissions.ask` can run without asking	Use `deny` for anything safety-critical; canary-test `ask`.
2	`-p` / SDK / cloud / `--bare` skip safety layers	Unapproved `.mcp.json` loads headless — use `--strict-mcp-config`.
3	CLAUDE.md enforces nothing; hooks fail open	Hard rules go in `permissions`; hooks must `exit 2` and anchor matchers.
4	`MCP_TOOL_TIMEOUT` defaults to ~28h	Set it explicitly, especially for stdio/WebSocket servers.
5	Auto mode is now the default	Pin `permissions.defaultMode`; the 3/20 block breaker isn't tunable.
6	Subagents get a session-start CLAUDE.md snapshot	Restate must-follow rules in the delegation prompt.
7	`--max-budget-usd` forgets resumed spend	Track cumulative spend externally.
8	The `rm -rf` countdown resolves to deny	Unattended auto/bypass pipelines should expect the deny.
9	Cache TTL drops from 1h to 5m	Pin `CLAUDE_CODE_PROMPT_CACHE_TTL` / `CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL`.
10	Four config knobs don't do what their names say	Raise the compact window with `/autocompact`, not the env var.
11	MCP output over the cap goes to a file	A tool's own `maxResultSizeChars` beats `MAX_MCP_OUTPUT_TOKENS`.

All values as of v2.1.283 / Sep 2026.

The trust-boundary three

1. `permissions.ask` has three different ways to not actually ask

At least three independently reported paths let an ask-listed command run with no prompt: in default/no-sandbox mode a visible Bash(conda run:*) ask rule ran unprompted (GH#79771, open) while /sandbox with autoAllowBashIfSandboxed:false did enforce it; auto mode ignores permissions.ask while honoring allow/deny (GH#42797, closed, no stated fix); and a transiently invalid settings.json silently drops deny and ask enforcement in -p/stream-json (GH#78764, closed "not planned," labeled reproduced). No stated fix as of v2.1.283.

Detection: put a harmless canary on permissions.ask and confirm a prompt actually appears — don't trust /permissions listing it. In a test project only, break settings.json mid-run under -p and confirm denied commands stay denied. Fix: use permissions.deny for anything safety-critical; where ask is required, also enable /sandbox with autoAllowBashIfSandboxed:false; never hand-edit a live settings.json mid-session.

2. `-p`, the Agent SDK, cloud sessions, and `--bare` all quietly skip a safety layer

Trust verification is disabled under -p. Project .mcp.json servers load with no approval prompt in -p, the Agent SDK, and cloud sessions — and in any bypassPermissions session with skipDangerousModePermissionPrompt set. --bare skips hooks, skills, commands, subagents, plugins, MCP, auto memory, and CLAUDE.md, and sets CLAUDE_CODE_SIMPLE (skills in an --add-dir directory still load). Plain --continue skips -p/SDK//loop-first sessions unless you run claude -p --continue.

Detection: audit CI target repos for a checked-in .mcp.json; after a -p session, claude mcp list. Fix: --strict-mcp-config, disabledMcpjsonServers, or --setting-sources for -p/SDK/CI runs; treat every headless target repo as pre-vetted; don't use --bare where hooks are your guardrail. (Official docs — single publisher.) (MCP, CLI reference, security)

3. CLAUDE.md doesn't enforce anything — and PreToolUse hooks fail open

The docs: "CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." Enforcement is permissions allow/ask/deny plus PreToolUse hooks, and deny/ask beat a hook's decision. The hook traps: a typo'd or non-executable path exits 127 and is non-blocking; a command/http/mcp_tool hook that times out doesn't block (an Agent SDK callback hook does); only exit 2 blocks — exit 1 doesn't, and exit 2 blocks even if the JSON says allow; Edit.* also matches NotebookEdit; mcp__memory matches nothing (use mcp__memory__.*); the if field holds one rule, no &&/||; disableAllHooks can't disable managed hooks unless set at the managed level. Default hook timeouts (v2.1.283): 600s command/http/mcp_tool, 30s prompt, 60s agent. Mid-session CLAUDE.md edits don't apply until /clear, /compact, or restart; keep it under 200 lines.

Detection: claude --debug and watch for Failed with non-blocking status code; fire Edit and NotebookEdit at an Edit.* hook. Fix: hard rules go in permissions.deny/ask; hooks exit 2 explicitly, anchor matchers (^Edit$), use mcp__server__.*, and verify the script path is executable. (Official docs — single publisher.) (hooks, permissions, memory)

The silent-default four

4. The MCP timeout nobody sets defaults to ~28 hours

Leave MCP_TOOL_TIMEOUT unset and you inherit a ~28-hour default (as of v2.1.283). A per-server timeout below 1000 is ignored and falls through to MCP_TOOL_TIMEOUT. HTTP/SSE get a per-request timer of max(60s, server tool timeout, MCP_TIMEOUT); stdio and WebSocket have no per-request timer, so a hung call can run the full ~28 hours (GH#69487). Detection: echo $MCP_TOOL_TIMEOUT — empty means exposed. Fix: set MCP_TOOL_TIMEOUT explicitly in milliseconds (>= 1000), especially for stdio/WebSocket servers.

5. Auto mode is now the default everywhere — with trip wires you can't tune

As of v2.1.283, auto mode is the default starting permission mode for interactive terminal and VS Code sessions on every plan and provider unless permissions.defaultMode says otherwise. Its breaker is fixed: after 3 consecutive or 20 total blocks per session, auto mode pauses and goes back to prompting you (as of v2.1.283). The classifier runs server-side by default, staged from v2.1.271 to v2.1.280. Detection: /status. Fix: { "permissions": { "defaultMode": "default" } }; separately, export CLAUDE_CODE_AUTO_MODE_SERVER=0 controls where the classifier runs (off the server-side path), not whether auto mode is on. (permission modes)

8. The `rm -rf` countdown resolves to DENY — and there are two different rm guards

"If the countdown runs out before you answer, Claude Code denies the command." The 2-minute countdown (as of v2.1.283) appears only in auto and bypassPermissions modes; after 3 unanswered countdowns, further critical-path removals are denied immediately. rm -rf "$(pwd)" trips a separate substitution check whose opt-out, CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1, is not CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 (which only removes the countdown — deny-on-timeout becomes wait-forever). Fix: leave both guards on and design unattended pipelines to expect a deny after 2 minutes. Verify only in a disposable container/VM.

6. Subagents run on a session-start CLAUDE.md snapshot — and `disallowedTools` amputates whole tools

Non-fork subagents get no conversation history and no auto memory, and their CLAUDE.md/memory is the copy the parent loaded at session start (GH#88886) — mid-session edits are invisible to them. disallowedTools: [Bash(git push *)] removes the whole Bash tool. When the parent is in bypassPermissions/acceptEdits/auto, the subagent's own permissionMode is ignored. Fix: restate must-follow rules in the delegation prompt; isolation: worktree; block specific commands with a permissions.deny Bash rule, not disallowedTools(specifier).

The cost-and-context four

9. Your prompt cache TTL quietly drops from 1 hour to 5 minutes

As of v2.1.283 / Sep 2026, the main conversation gets a 1-hour TTL only on a subscription within plan usage; it drops to 5 minutes on usage credits and is 5 minutes by default on an API key or cloud provider. Subagents, workflows, compaction, and teammates get 5 minutes unless pinned. A /model or effort switch forces a full recompute on most models. GH#46829 reports a 20–32% cost rise — community-reported, directional only, not confirmed by Anthropic. Detection: cache_creation_input_tokens vs cache_read_input_tokens per turn; /usage "Prompt cache (main)" line (v2.1.260+). Fix: CLAUDE_CODE_PROMPT_CACHE_TTL=1h and CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL=1h (v2.1.242+; 5m or 1h). (prompt caching)

7. `--max-budget-usd` doesn't count what you think across resumes

Print-mode only; subagent spend counts (v2.1.217+), but totals restored via --continue/--resume do NOT count toward the cap on the resumed run. --max-turns is print-mode only, has no default, and a queued stream-json message at turn-end starts a fresh turn with its own limit. Fix: track cumulative spend externally; read the stop message — a model switch doesn't help a session limit, and only an admin can raise a spend limit. (Official docs — single publisher.) (CLI reference, costs)

10. Four config knobs that don't do what their name implies

As of v2.1.283: CLAUDE_AUTOCOMPACT_PCT_OVERRIDE can only lower the trigger; CLAUDE_CODE_AUTO_COMPACT_WINDOW takes only a plain token count (no k/M) and, if set, overrides /autocompact 500k and --autocompact 1M; max effort persists only via CLAUDE_CODE_EFFORT_LEVEL=max (rejected in modelSettings/effortLevel); bashOutputMaxChars overrides BASH_MAX_OUTPUT_LENGTH (default 30000, max 150000). Detection: /autocompact with no args. (Official docs — single publisher.) (env vars, model config)

11. Your MCP output got truncated and saved to disk — and the chat barely tells you

MCP output warns at 10,000 tokens and caps at 25,000 by default (as of v2.1.283). MAX_MCP_OUTPUT_TOKENS only affects tools without their own maxResultSizeChars (capped at 500,000 chars). Oversized non-image results go to ~/.claude/projects/.../tool-results/ with a message naming the path. GH#97622 reports an extra ~50,000-char persist threshold the env var doesn't lift — community-reported, unverified by Anthropic. Fix: check whether a tool declares maxResultSizeChars before relying on the env var; run /context after adding any MCP server. (MCP)

Where to set these (as of v2.1.283 / Sep 2026)

From the official docs: settings, settings reference, env vars, MCP, permissions, headless.

Settings files (highest precedence first):

Level	File	Applies to
Managed	`managed-settings.json`, MDM, or the claude.ai console	Everyone your org deploys it to; you can't override it
Command line	`claude --settings`	You, this session
Project local	`.claude/settings.local.json`	You, this project only
Shared project	`.claude/settings.json`	Everyone in the project (checked into source control)
User	`~/.claude/settings.json`	You, every project

All of these keys can be set in any of those files: permissions.allow / ask / deny / defaultMode, hooks, disableAllHooks, promptCacheTtl, subagentPromptCacheTtl, bashOutputMaxChars, autoCompactWindow, effortLevel, disabledMcpjsonServers, sandbox.autoAllowBashIfSandboxed, showThinkingSummaries, env. Exception: permissions.defaultMode values auto and bypassPermissions don't take effect from project or local settings — set them in user or managed settings.

Team-wide guardrails (deny rules, hooks, disabledMcpjsonServers) belong in the checked-in .claude/settings.json; personal preferences belong in ~/.claude/settings.json.

// ~/.claude/settings.json  (or .claude/settings.json for the whole team)
{
  "permissions": { "deny": ["Bash(git push *)"], "defaultMode": "default" },
  "sandbox": { "autoAllowBashIfSandboxed": false },
  "promptCacheTtl": "1h",
  "subagentPromptCacheTtl": "1h",
  "env": { "MCP_TOOL_TIMEOUT": "<milliseconds>" }
}

Environment variables (MCP_TOOL_TIMEOUT, MAX_MCP_OUTPUT_TOKENS, CLAUDE_CODE_PROMPT_CACHE_TTL, CLAUDE_CODE_EFFORT_LEVEL, CLAUDE_CODE_AUTO_MODE_SERVER, …) can be set two ways:

in your shell before launching claude (export VAR=value; add it to ~/.zshrc / ~/.bashrc to persist), or
under the "env" key of any settings file above. If both are set, the settings-file value wins.
Exception: CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT is read only from the environment you launch claude from — it is ignored in a settings env block.

MCP servers: project-scoped servers live in .mcp.json at the project root; user- and local-scoped servers live in ~/.claude.json. A per-server "timeout" field (milliseconds, ≥1000) in a .mcp.json entry overrides MCP_TOOL_TIMEOUT for that server only.

How to write permissions.allow / ask / deny rules (code.claude.com/docs/en/permissions, fetched 2026-09-29):

allow — Claude Code runs the tool without asking. ask — it prompts you for confirmation every time. deny — it's blocked. Rules are evaluated deny → ask → allow; the first match wins, and specificity doesn't change the order.
Syntax is Tool(specifier): Bash(npm run build) (exact command), Bash(npm run *) (prefix — the space before * matters; Bash(ls:*) = Bash(ls *)), Read(./.env), Read(./secrets/**), WebFetch(domain:example.com), and in deny/ask only, tool-name globs like mcp__* (every MCP tool).
Compound commands are split on &&, ||, ;, | and newlines; a deny or ask rule applies if any subcommand matches.
Limit: a Bash rule matches the command text Claude writes, not the program — Bash(rm *) stops rm -rf build/ but not /bin/rm -rf build/ or bash -c 'rm -rf build/'. The docs say it "isn't a security boundary around the program"; pair it with the sandbox.
View and edit the active rules with /permissions.

// .claude/settings.json (team) or ~/.claude/settings.json (you)
{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask":   ["Bash(git clean *)"],
    "deny":  ["Bash(git push *)", "Read(./.env)", "Read(./secrets/**)"]
  }
}

What "headless" means: running Claude Code with no person at the terminal — claude -p "<prompt>" (the -p / --print flag runs it non-interactively) from a script, cron job or CI pipeline such as GitHub Actions, or the Agent SDK from Python/TypeScript. The docs: a -p session "shows no workspace trust dialog and no per-server approval prompt", and it still runs the hooks in the project's .claude/settings.json and connects the servers in its .mcp.json, even in a folder you've never trusted. -p starts in Manual permission mode on every plan.

Subagent definitions live in .claude/agents/ (fields such as isolation: worktree, memory, permissionMode, disallowedTools go in the agent file's frontmatter).

The pattern underneath all eleven

Nothing errors. The ask rule resolves to allow. The headless run loads .mcp.json unprompted. The typo'd hook exits 127 and the action proceeds. The stdio MCP call keeps waiting. The resumed budget covers only new spend. The cache TTL drops to 5 minutes and the bill doesn't say why. The thing you configured isn't the thing the client enforces — so the discipline that pays off is verifying the layer that actually enforces: canary your ask/deny rules, pin permissions.defaultMode, set MCP_TOOL_TIMEOUT and cache TTLs explicitly, and watch /usage, /context, and claude mcp list.

Pick the three that map to your setup and add a check this week. The one that catches a real incident pays for the afternoon.

What's bitten you that isn't here? I'm collecting Claude Code gotchas for agentic workflows — reply and I'll add the good ones with credit.

How to Prevent Algorithmic Bias When Using AI Tools as MCP Connectors

Wed, 07 Oct 2026 03:44:35 +0000

As developers shift toward agentic AI architectures, the Model Context Protocol (MCP) has emerged as a groundbreaking standard for connecting LLMs to local data sources, APIs, and development environments. However, hooking a powerful LLM directly into your workflows via an MCP connector introduces a major risk: amplifying algorithmic bias.

If your underlying model suffers from data skew, or if your context-retrieval pipeline lacks guardrails, your AI assistant will generate biased code, flawed evaluations, or skewed data summaries.

Here is a practical guide on how to design and configure your MCP connectors to actively mitigate algorithmic bias.

Enforce Structured Input & Output Schemas
Bias thrives in ambiguity. When building an MCP connector tool, do not rely on open-ended text blobs. Instead, establish strict JSON schemas for both incoming requests and outgoing tool results.
• The Fix: Filter out demographic markers or unneeded metadata at the connector layer before transmitting payload data to the model.
Implement Counter-Stereotypical Context Prompting
When your MCP server injects localized data into the LLM's context window, it can trigger hidden biases within the foundation model.
• The Fix: Hardcode robust system instructions directly into the prompt templates wrapped by your MCP server. Instruct the model to evaluate the context purely on functional logic, ignoring patterns that mimic historical biases.
Establish Multi-Source Data Diversity (Diversified RAG)

If your MCP server queries an internal database or local codebase to feed context to the LLM, a homogenous data source will lead to narrow, biased code recommendations.
• The Fix: Program your MCP connector to pull context from multiple, distinct nodes or repositories. Introduce diverse code repositories or documentation libraries into your retrieval pipeline to ensure varied training references.

Implement Human-in-the-Loop Validation Layers
Never allow an MCP tool to execute high-impact mutations (like direct git commits to production or automated user permission alterations) without manual validation.
• The Fix: Design your MCP connector tools with a strict approval phase. Use intermediate state flags (status: pending_review) so a human operator can review the generated code or decision for bias before deployment.
Audit MCP Interaction Logs Regularly
Bias mitigation is an ongoing process. You must log inputs, prompt context windows, and output generation samples traversing your MCP server.
• The Fix: Regularly analyze logs using semantic search scripts to flag repeating anomalies, unfair decision patterns, or toxic code constructs generated during model interactions.
Get Started with MCP

Building unbiased, highly deterministic AI workflows starts with choosing the right protocol framework. Explore open-source implementations, tools, and integration guides on the official SEOSiri Model Context Protocol Suite to secure your developer ecosystem today.

Mi setup de agente barato: OpenCode + DeepSeek por céntimos (feat. IgnicionDev)

Mon, 05 Oct 2026 15:40:22 +0000

Mi setup de agente barato: OpenCode + DeepSeek por céntimos (feat. IgnicionDev)

Serie: My cheap Setup feat IgnicionDev — Post 00
Read time: ~8 min · Etiquetas: ai aiagents devtools mcp

Abrí un agente que cuesta céntimos y me devolvió control, no ruido

La mayoría de la conversación sobre agentes de código empieza por la potencia: el modelo más grande, el benchmark más alto, la demo más vistosa. Mi problema era el contrario. Yo no necesitaba más inteligencia: necesitaba algo que costara céntimos, que no inundara la terminal y cuyo resultado pudiera auditar línea a línea. Si no puedo leer y ejecutar lo que el agente produce, no me sirve: trabajo con dinero, facturas y datos que deben cuadrar.

Así que me monté un agente barato —OpenCode + DeepSeek Flash— y lo rodeé de disciplina: memoria persistente, reglas de gasto de tokens, permisos estrictos y verificaciones reales. Este post es el "cómo", con números, y termina con diez cosas concretas que puedes hacer hoy con un setup así. No es magia; es ingeniería honesta.

Quién escribe esto

Soy Ignacio Badenes (IgnicionDev), técnico de sistemas e informática aplicada desde Castellón, España. Vengo del soporte y del control de accesos: protocolos, registros, sangre fría cuando algo falla. Ese hábito lo aplico ahora al software que construyo y publico —Aethernet (auditoría WiFi local, 146 tests), LocalGrant-Finder (subvenciones del BOE con búsqueda híbrida), SystemBridge-AI (facturas a libro contable, dinero en Decimal) y AssetShrink (C++17, imágenes en local)—. Todos con tests, CI y licencia. Si una herramienta no es auditable, no la publico. Con mi agente, igual.

La tesis: la disciplina sustituye a la potencia

Un modelo barato no te obliga a obtener resultados baratos. Te obliga a dejar de improvisar. El truco no está en el modelo: está en gastar pocos tokens sin perder precisión. En DeepSeek Flash el precio se reparte así:

coste = input_fresco × $0,14/M  +  input_cacheado × $0,0028/M  +  output × $0,28/M

El input cacheado cuesta 50 veces menos que el fresco, y el output es la partida más cara. Por eso ataqué los tres frentes:

System prompt y herramientas mínimas (menos tokens fijos por petición).
Máximo reúso de caché (mismo prefijo, sin UUIDs aleatorios que la rompen).
Output controlado (respuestas cortas o JSON, nada de párrafos de relleno).

En mi escenario de trabajo, esto reduce el gasto ~82 %; una vez la caché está caliente, el coste marginal por petición cae a una fracción de céntimo. No es "gratis", pero se acerca. Y lo importante: sigue siendo correcto porque yo pongo la disciplina donde el modelo no llega.

El setup: OpenCode + DeepSeek

Mi modelo es deepseek/deepseek-v4-flash, servido por un proveedor compatible con OpenAI y con la caché activada:

{
  "model": "deepseek/deepseek-v4-flash",
  "provider": {
    "deepseek": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "setCacheKey": true },
      "models": {
        "deepseek-v4-flash": {
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" }
        }
      }
    }
  }
}

Tres decisiones que marcan la diferencia a lo largo del día:

Compactación automática (auto, prune, reserved: 5000): la conversación se poda sola y no arrastro historial gigante.
Límite de salida de herramientas (max_lines: 200, max_bytes: 8192): un npm install no me escupe 200 líneas a la cara; si trunca, reejecuto acotado.
Permisos estrictos (webfetch: deny, plan en solo lectura): el agente no navega ni escribe donde no debe sin que yo lo apruebe.

Sobre todo esto manda un archivo: mi AGENTS.md. No es una lista de deseos, es un router de trabajo con protocolo (entender → planear → cambio pequeño → verificar → revisar), una Definition of Done honesta (typecheck, tests, lint, diff revisado) y reglas de gasto. El modelo es barato; el criterio no.

Memoria y contexto: que no repita lo que ya sabe

Un agente sin memoria es un becario con amnesia: cada sesión empieza de cero y vuelve a pagar por lo mismo. Yo uso el plugin engram + zerotoken: memoria tipada en SQLite con FTS5, auto-guardado de errores→solución, decisiones de arquitectura y compactaciones, e inyección de solo 2 memorias / 600 tokens en cada arranque. Traducido: en vez de arrastrar 50 000 tokens de historial, inyecto lo justo.

A eso le sumo Context7: cuando pregunto por una API o versión concreta, trae la documentación real y la cacheo como memoria. La próxima vez no vuelvo a consultarla ni el modelo la alucina. Documentación viva, cero repetición.

My.OpenCode.Conf: el proyecto privado que da forma a todo

Aquí está la pieza que mucha gente no ve. Mi configuración no es un opencode.json suelto: es un proyecto de GitHub privado llamado My.OpenCode.Conf, parte de mi aprendizaje y mi forma de trabajar. Es un bundle de tres subproyectos independientes que se hablan por un protocolo abierto (MCP):

Subproyecto	Qué aporta	Hecho con
`skill-matrix`	+240 skills en formato `SKILL.md` (técnicas y de diseño) que el agente carga bajo demanda por triggers	Markdown
`second-termux-v2`	Servidor MCP que lanza jobs en background y devuelve una sola línea de estado en vez de inundar la TUI	TypeScript (ESM)
`engram+zerotoken`	El plugin de memoria persistente (FTS5) y la política de ahorro de tokens	TypeScript (Bun)

Los une un prompt maestro: en vez de mantener un install.sh frágil, el propio agente se autoconfigura (detecta el sistema operativo y adapta los comandos). Y, para mí, lo mejor de su diseño: es reversible. Se desinstala limpio, sin lock-in, sin telemetría y sin tocar lo que ya tenías. El repo es privado por ahora —lo enseño, lo explico y respondo dudas—, pero la lección es pública: una buena config es código que se puede leer, verificar y deshacer.

Las herramientas que lo conectan (MCP y plugins)

chrome-devtools (headless) — un navegador real que el agente maneja: navegar, extraer, y hacer auditorías Lighthouse sin abrir una ventana.
github — issues, PRs y acciones desde la propia conversación.
sqlite — consultas sobre mi base de datos local de trabajo.
context7 — documentación de librerías en vivo.
human-followup.ts — plugin propio que usa notify-send: cuando el agente pide datos, necesita un permiso o termina una navegación, me salta una notificación de escritorio. Puedo dejar de mirar la terminal.
Subagentes (explore, general) — para repartir exploración y trabajo pesado sin contaminar mi contexto.

Crear tu propio MCP para publicar sin salir del agente

El ejemplo más honesto de "herramienta propia" es este mismo post. En vez de copiar y pegar texto en el navegador, escribí un MCP local para Coder Legion en Node ESM sin dependencias (~300 líneas): una conversación JSON-RPC por stdio contra la API REST de la plataforma. El agente lista, busca, comenta y redacta en borrador desde la misma sesión en la que programa.

Lo interesante no es el camino feliz, son los bordes:

La API no tiene campo draft. El borrador se implementa con POST /posts seguido de POST /posts/{id}/hide: el post nace invisible salvo para el autor y los mods. Publicar es POST /posts/{id}/reshow.
El MCP nunca publica solo. cl_create_post valida y crea siempre oculto; si el hide falla, devuelve el id y avisa de que el post quedó público para corregirlo de inmediato. La publicación real solo ocurre con cl_publish_post, y esa llamada la decido yo.
Edición incremental. cl_edit_post hace read-modify-write en servidor: append, prepend, insert_before, insert_after o replace sobre un ancla literal. Añado una sección sin reenviar 19 KB de markdown, con dry_run para previsualizar antes de guardar.

Es el patrón que repito en todo: la API hace lo mínimo, el MCP añade la disciplina (draft-first, revisión humana) y el agente se queda con lo mecánico. Si algo no lo puedo auditar o deshacer, no lo automatizo.

De la TUI al Desktop en Linux (ya migrado)

Hasta hace poco corría todo en la TUI (v1.18.34). Acabo de dar el salto a la versión Desktop en Linux Mint 22.3, instalando el .deb de la release oficial. En Linux no hay cask de Homebrew —eso es solo macOS—; lo correcto aquí son los paquetes de la release (.deb, .rpm o .AppImage). El binario de escritorio registra su lanzador en el menú de aplicaciones, así que paso de "abrir una terminal y teclear" a "abrir una app". Misma configuración, misma memoria, mismo agente; solo cambia el envoltorio. Si tienes dudas con la instalación en Linux, te lo cuento con detalle en los comentarios.

Diez cosas que mi agente barato hace hoy

Ejemplos reales, no humo:

Diagnosticar un repo: señalarlo, que reproduzca, minimice y proponga un plan de fallos con la skill diagnose.
Escribir tests primero: ciclo red-green-refactor con tdd, no tests de relleno.
Revisar un diff: auditoría en paralelo de estándares y de especificación con review.
Auditoría web real: levantar el navegador headless y ejecutar un Lighthouse sobre mi página.
Consultar docs actualizadas con Context7 y guardarlas en Engram para no repetir la consulta.
Recordar un fix entre sesiones: "esto ya me falló", y el error→solución está ahí.
Lanzar un build largo en background y recibir una sola línea de estado (done) en vez de 200 líneas.
Refactorizar con plan: request-refactor-plan descompone en commits pequeños y seguros.
Crear una skill propia con write-a-skill cuando repito un patrón.
Delegar exploración de un codebase desconocido a un subagente mientras sigo trabajando.

Lo honesto: qué gano y qué pierdo

Gano: coste de céntimos, memoria que persiste, permisos que respeto, cero telemetría y la tranquilidad de un sistema que puedo auditar y deshacer. Pierdo: techo de razonamiento —un modelo Flash no es un modelo de frontera— y comodidad. Un agente barato no piensa por ti; te obliga a decirle exactamente qué quieres y a verificar el resultado. Para mí, ese intercambio es una ventaja: es la diferencia entre "confío porque lo leí" y "confío porque me lo dijo un modelo caro".

Takeaway

No necesitas el modelo más potente para producir software serio: necesitas economía de tokens, memoria y disciplina. Con un modelo barato bien dirigido, el límite deja de ser el precio y pasa a ser tu criterio.

¿Y tú? ¿Qué modelo barato usas —o usarías— y cómo compensas sus límites? Cuéntamelo en los comentarios; leo y respondo a todo.

_{English version below · The original is in Spanish. If you're an English speaker, jump to the translation and let me know your setup in the discussion. I reply to everyone.}

My cheap Setup: running OpenCode + DeepSeek for cents (feat. IgnicionDev)

Series: My cheap Setup feat IgnicionDev — Post 00
Read time: ~8 min · Tags: ai aiagents devtools mcp

I built an agent that costs cents and gave me control back, not noise

Most talk about coding agents starts with raw power: the biggest model, the highest benchmark, the flashiest demo. My problem was the opposite. I didn't need more intelligence — I needed something that costs cents, doesn't flood my terminal, and produces output I can audit line by line. If I can't read and run what the agent produces, it's useless to me: I work with money, invoices and data that has to add up.

So I built a cheap agent —OpenCode + DeepSeek Flash— and wrapped it in discipline: persistent memory, token-spend rules, strict permissions and real verification. This post is the "how", with numbers, and it ends with ten concrete things you can do today with a setup like this. No magic; just honest engineering.

Who's writing this

I'm Ignacio Badenes (IgnicionDev), an IT technician from Castellón, Spain. I come from support and access control: protocols, logs, staying calm when things break. I now apply that habit to the software I build and publish —Aethernet (local WiFi auditing, 146 tests), LocalGrant-Finder (Spanish official-gazette grants with hybrid search), SystemBridge-AI (invoices into a balanced ledger, money as Decimal) and AssetShrink (C++17, local image processing)—. All with tests, CI and a licence. If a tool isn't auditable, I don't ship it. Same goes for my agent.

The thesis: discipline replaces raw power

A cheap model doesn't force cheap results. It forces you to stop improvising. The trick isn't the model: it's spending few tokens without losing accuracy. With DeepSeek Flash the cost splits like this:

cost = fresh_input × $0.14/M  +  cached_input × $0.0028/M  +  output × $0.28/M

Cached input is 50× cheaper than fresh input, and output is the priciest line. So I attacked all three:

Minimal system prompt and tools (fewer fixed tokens per request).
Maximum cache reuse (same prefix, no random UUIDs to break it).
Controlled output (short answers or JSON, no filler paragraphs).

In my working scenario that cuts spend by ~82%; once the cache is warm, marginal cost per request drops to a fraction of a cent. It's not "free", but it gets close. And it stays correct because I supply the discipline where the model can't.

The setup: OpenCode + DeepSeek

My model is deepseek/deepseek-v4-flash, served through an OpenAI-compatible provider with caching enabled:

{
  "model": "deepseek/deepseek-v4-flash",
  "provider": {
    "deepseek": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "setCacheKey": true },
      "models": {
        "deepseek-v4-flash": {
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" }
        }
      }
    }
  }
}

Three decisions that matter all day:

Automatic compaction (auto, prune, reserved: 5000): the conversation prunes itself; I don't drag a huge history.
Tool output limits (max_lines: 200, max_bytes: 8192): an npm install doesn't dump 200 lines in my face; if it truncates, I re-run it scoped.
Strict permissions (webfetch: deny, read-only plan mode): the agent can't browse or write outside its lane without my approval.

Above all of this sits one file: my AGENTS.md. It isn't a wish list; it's a work router with a protocol (understand → plan → small change → verify → review), an honest Definition of Done (typecheck, tests, lint, reviewed diff) and spending rules. The model is cheap; the judgement isn't.

Memory and context: stop repeating what it already knows

An agent without memory is an intern with amnesia: every session starts from zero and pays twice. I use the engram + zerotoken plugin: typed memory in SQLite with FTS5, auto-saving error→fix, architecture decisions and compactions, and injecting only 2 memories / 600 tokens at startup. In short: instead of dragging 50,000 tokens of history, I inject just enough.

On top of that I add Context7: when I ask about a specific API or version, it pulls the real documentation and caches it as a memory. Next time I don't re-query it and the model doesn't hallucinate it. Live docs, zero repetition.

My.OpenCode.Conf: the private project that shapes it all

Here's the part most people miss. My config isn't a loose opencode.json: it's a private GitHub project called My.OpenCode.Conf, part of my learning and the way I work. It's a bundle of three independent subprojects that talk to each other through an open protocol (MCP):

Subproject	What it brings	Built with
`skill-matrix`	240+ skills in `SKILL.md` format (technical and design) the agent loads on demand via triggers	Markdown
`second-termux-v2`	An MCP server that runs background jobs and returns a single status line instead of flooding the TUI	TypeScript (ESM)
`engram+zerotoken`	The persistent-memory plugin (FTS5) and the token-saving policy	TypeScript (Bun)

A master prompt ties them together: instead of maintaining a fragile install.sh, the agent configures itself (detects the OS, adapts commands). And, to me, the best part of its design: it's reversible. It uninstalls cleanly, with no lock-in, no telemetry and without touching what you already had. The repo is private for now —I show it, explain it and answer questions— but the lesson is public: a good config is code you can read, verify and undo.

The tools that wire it together (MCP and plugins)

chrome-devtools (headless) — a real browser the agent drives: navigate, extract, and run Lighthouse audits without opening a window.
github — issues, PRs and actions from the conversation itself.
sqlite — queries against my local work database.
context7 — live library documentation.
human-followup.ts — my own plugin using notify-send: when the agent asks for input, needs a permission, or finishes a navigation, I get a desktop notification. I can stop staring at the terminal.
Subagents (explore, general) — to split exploration and heavy work without polluting my context.

Building your own MCP to publish without leaving the agent

The most honest example of a "tool of my own" is this very post. Instead of copy-pasting into a browser, I wrote a local MCP for Coder Legion in dependency-free Node ESM (~300 lines): a JSON-RPC conversation over stdio against the platform's REST API. The agent lists, searches, comments and drafts from the same session where it codes.

What's interesting isn't the happy path, it's the edges:

The API has no draft field. The draft is implemented with POST /posts followed by POST /posts/{id}/hide: the post is born invisible to everyone but the author and mods. Publishing is POST /posts/{id}/reshow.
The MCP never publishes on its own. cl_create_post validates and creates always hidden; if the hide fails it returns the id and warns that the post went public so I fix it immediately. The real publish only happens through cl_publish_post, and that call is mine.
Incremental editing. cl_edit_post does a server-side read-modify-write: append, prepend, insert_before, insert_after or replace against a literal anchor. I add a section without resending 19 KB of markdown, with dry_run to preview before saving.

It's the pattern I keep repeating: the API does the bare minimum, the MCP adds the discipline (draft-first, human review) and the agent keeps the mechanical part. If I can't audit or undo it, I don't automate it.

From TUI to Desktop on Linux (already migrated)

Until recently I ran everything in the TUI (v1.18.34). I've just moved to the Desktop version on Linux Mint 22.3, installing the official release .deb. There's no Homebrew cask on Linux —that's macOS only—; here the right choice is the release packages (.deb, .rpm or .AppImage). The desktop binary registers its launcher in the application menu, so I go from "open a terminal and type" to "open an app". Same config, same memory, same agent; only the wrapper changes. If you're stuck installing it on Linux, I'll walk you through it in the comments.

Ten things my cheap agent does today

Real examples, no hype:

Diagnose a repo: point at it, and it reproduces, minimises and proposes a fix plan using the diagnose skill.
Write tests first: red-green-refactor with tdd, not filler tests.
Review a diff: a parallel audit of standards and spec with review.
Real web audit: spin up the headless browser and run Lighthouse on my site.
Pull up-to-date docs with Context7 and store them in Engram so the query isn't repeated.
Remember a fix across sessions: "this broke before", and the error→fix is there.
Run a long build in the background and get a single done status line instead of 200.
Refactor with a plan: request-refactor-plan breaks it into small, safe commits.
Create its own skill with write-a-skill when I repeat a pattern.
Delegate exploration of an unknown codebase to a subagent while I keep working.

The honest part: what I gain and what I lose

I gain: cents-level cost, memory that persists, permissions I respect, zero telemetry, and the peace of mind of a system I can audit and undo. I lose: a reasoning ceiling —a Flash model isn't a frontier model— and convenience. A cheap agent doesn't think for you; it forces you to say exactly what you want and to verify the result. To me, that trade is an advantage: it's the difference between "I trust it because I read it" and "I trust it because an expensive model said so".

Takeaway

You don't need the most powerful model to produce serious software: you need token economy, memory and discipline. With a cheap model well directed, the limit stops being the price and becomes your judgement.

So what about you? Which cheap model do you use —or would you use— and how do you compensate for its limits? Tell me in the comments; I read and reply to everyone.

_{Licencia de los proyectos mencionados: MIT · Sin secretos ni claves en este post. · Proyectos: github.com/yosoyignicion}

CodeSage: Code Intelligence for AI Agents, and Why I Rebuilt Its Models

Fri, 02 Oct 2026 11:25:42 +0000

Until this week, CodeSage ran its two models exactly as they ship on Hugging Face: Jina's code embedder and the ms-marco MiniLM reranker. A full index of php-src took 1,782 seconds, just under half an hour, and I got tired of waiting.

CodeSage 0.38 does the same full index in 373 seconds. Nothing was retrained. The weights are the same weights; what changed is the inference graph around them, a few things in the chunker, and one SQLite query that had been quietly eating most of the run. The two rebuilt models are now public on Hugging Face, along with the scripts that produce them byte-for-byte.

What CodeSage gives an agent

CodeSage is a code intelligence engine for AI coding agents: a structural graph (symbols, references, dependencies) plus semantic search (embedding retrieval with cross-encoder reranking), in one Rust binary that works as a CLI or an MCP server. An agent asks it questions grep can't answer, like "what depends on this class" or "where does session handling happen", and gets file-and-line answers from an index instead of guesses from a context window.

Parsing is tree-sitter, covering PHP, Python, C, C++, Java, Rust, JavaScript, TypeScript and Go. Each project gets one SQLite database at .codesage/index.db, with sqlite-vec for KNN and FTS5 for literal matches. The MCP side is a stdio shim that starts or reuses a per-user daemon over a Unix socket, so concurrent agent sessions share one project cache, one model pool and one CUDA context. There is no HTTP listener.

The MCP server exposes 22 tools. The ones agents lean on most:

find_symbol, find_references, trace_call_path: where something is defined, who calls it, and the shortest call chain between two symbols.
impact_analysis, assess_risk: what a change to this file can break, scored from the graph plus git history.
search: natural-language retrieval over ~50-line chunks, reranked.
from_trace: maps a pasted stack trace or ASan report (Python, PHP with Xdebug, Rust, Java, Go, Node, gdb) onto indexed symbols.
edit_check: diffs a proposed declaration against HEAD before the agent writes the file.

The graph is only as useful as its recall. In August, impact_analysis reported that AxiosError in axios had 0 dependents. It has 23. File-path imports like ./core/AxiosError.js never resolved; only Rust-style :: paths did. Fixing that, and counting Foo.staticMethod() and x instanceof Foo as usage, took mean dependent recall on axios from 0.37 to 0.66 at precision 0.85. An agent told "0 dependents" by a tool it trusts goes ahead and changes the class.

The index has to keep up with the code

An index that lags the code feeds the agent stale answers with full confidence, so CodeSage re-indexes from git hooks on every commit, checkout and merge. That puts the indexer's fixed cost on the hot path dozens of times a day, which is why a lot of the work across 46 releases since April has gone into cost rather than features.

The per-commit path got there first. In 0.23.0, a no-change incremental run stopped loading the ONNX model and mapping a CUDA context before checking whether any file had changed:

No-change incremental `codesage index`	Time	Peak memory
0.22.0	2.7-4.5 s	1.16 GB
0.23.0	0.08 s	150 MB

The file watcher re-embeds only chunks whose text changed: an 8-save burst marks 90 chunks dirty and embeds 1.

That leaves the full index, which nobody runs on every commit but everybody runs eventually: first onboarding, a model change, a chunker change. 0.38 itself forces one, because the embedder now reads up to 1,024 tokens per chunk instead of 512. When the full run takes half an hour on a large repo, people postpone it, and a postponed re-index is a stale index.

Same weights, rebuilt graphs

The embedder was slow because of how it was exported, not because of what it computes. The upstream Jina v2 ONNX file is a decomposed opset-11 export. Its attention uses ALiBi plus a QK LayerNorm, a combination ONNX Runtime's transformer optimizer doesn't recognize, so nothing fuses. Every layer materializes the full [batch, 12, seq, seq] score tensor several times over, and because the graph outputs per-token hidden states, every batch copies a [batch, seq, 768] tensor from the GPU back to the host just so the caller can average it.

IA0x00/jina-embeddings-v2-base-code-codesage carries two graphs:

onnx/model.onnx (fp32, every execution provider): masked mean pooling and L2 normalization folded into the graph, so the output is the 768-dimension sentence embedding and nothing else crosses back to the host.
onnx/model_cuda_fp16.onnx (CUDA only): the same pooling, plus attention fused by hand into com.microsoft MultiHeadAttention, with ALiBi and the key-padding mask passed as attention_bias. Weights are fp16; the output stays fp32.

One fp16 detail: the attention mask filled padded positions with -FLT_MAX, which overflows fp16. It's -10000.0 now, which is still negative enough to zero those positions after softmax.

Measured on an RTX 4080 Laptop GPU with ONNX Runtime 1.24.4, 2,048 real chunks per corpus of up to 512 tokens each, compared against upstream fp32 with pooling done on the host:

Corpus	Upstream fp32	Pooled fp32	Fused fp16	Min cosine (fp16)	Top-10 neighbour overlap
php-src (C)	59.7 chunks/s	89	249-257	0.99999	0.994
Laravel app (PHP)	67.2	113	301-317	0.999996	0.996
React app (TS/JS)	69.8	109	296-317	0.999995	0.997

A minimum cosine of 0.99999 across 2,048 chunks means the vectors are, for retrieval purposes, the same vectors. Those throughput figures are at the 512-token cap; CodeSage now runs Jina at 1,024, because real C in php-src runs a median of 611 tokens per 1,500-byte chunk and the old cap truncated more than half of them. So the production per-chunk rate is lower than this table, and the chunks carry more of the code.

The reranker needed far less. IA0x00/ms-marco-MiniLM-L6-v2-codesage is a standard BERT, so ONNX Runtime's stock optimizer fuses it (embedding LayerNorm, six Attention nodes, skip LayerNorm, bias GELU) and the work was mostly converting to fp16. Scoring 50 (query, chunk) candidates went from a median 108.0 ms per query to 20.6 ms, with the same top result on 40 of 40 test queries, top-10 overlap of 0.9975, and a maximum logit change of 0.024.

Both repositories are Apache-2.0, the upstream license, and the weights are unchanged apart from precision. CodeSage pins each one by Hugging Face commit and by the sha256 of every graph and tokenizer it loads, and scripts/derive-jina-onnx.py and scripts/derive-reranker-onnx.py in the CodeSage repo download the pinned upstream files, verify them, and write the published files byte-for-byte. You don't have to trust my upload; you can rebuild it. Your config.toml keeps the upstream model names, and the pin table maps them to the derived repos, so there is nothing to change on upgrade.

The biggest single win wasn't a model

Most of the half hour was SQLite. When a file changes, its old chunks are deleted first, and file_path lived in an auxiliary column of the sqlite-vec table and an UNINDEXED column of the FTS5 table. Neither can be searched by index, so DELETE ... WHERE file_path = ? scanned both tables for every file: about one second per file at php-src's 54,000 rows, roughly 20 of the 28 minutes a full index took when I measured it.

The fix is a small sidecar table, <chunk_table>_paths(id, file_path), kept in step on every insert and delete and rebuilt if it goes missing or diverges. Deletes now resolve the path to rowids and remove by rowid: 3.2 ms per file.

Two chunker changes ship in the same release. Chunks that are mostly digits and commas (lookup tables, timezone and Unicode data) are no longer embedded, since no natural-language query is looking for them, and batches are length-sorted and byte-bounded so a batch of short chunks isn't padded out to the length of its longest member.

Before and after, all of it together:

`codesage index --full`	Before	0.38
php-src	1,782 s	373 s
private mobile backend	469 s	80 s
private frontend app	295 s	60 s

That is the combined effect of the fused fp16 graph, the 1,024-token cap, the dropped data chunks, the batching, and the delete fix. I don't have a clean per-change split beyond the delete scan's own estimate, so I'm not going to invent one. Retrieval held: recall@10 is unchanged on three private eval corpora and rose from 0.765 to 0.790 on a php-src session corpus.

Scores that say what they measured

Fast answers are worthless if the agent can't tell a measurement from a default, so several releases since August went into making CodeSage say what it didn't check. impact_analysis reports a lower bound, because dynamic calls and unresolved imports can hide real dependents. assess_risk returns unscored for a file with no indexed git history instead of a low number. find_references marks a count as a floor when the symbol name is ambiguous. An empty search result carries indexed-file counts per language, so "not found" and "never indexed" stop looking identical.

The same rule applies to my own benchmarks. In August I withdrew a published retrieval number (recall@10 0.932, NDCG@10 0.788 over 602 queries) after finding the harness had indexed whole repos instead of each benchmark's root and scored crashed queries as 0.000. The replacement table in the README runs 663 queries across 33 repos in 9 languages, reports per-language NDCG@10 from 0.7455 (C) to 0.9434 (JavaScript), and says it was measured on a modified 0.27.0 build. It hasn't been re-run on 0.38 yet.

Where it falls short

These are the limits I know about, all of them in the README:

Nine languages. On the public benchmark, 47% of queries are in languages CodeSage doesn't parse (Ruby, Kotlin, Swift, Scala) and get no recall at all.
Agents don't reach for it on their own. With CodeSage and Grep both available in Claude Code, agents picked CodeSage on code-identifier queries 1.1% of the time over 30 days of sessions, and 0 of 10 on a controlled harness (measured in April, not re-measured since). That is why the codesage-tools Claude Code plugin serves a codesage brief inline before an Edit or Write in an onboarded project instead of waiting to be asked. It stays silent when there is nothing worth saying.
Every speed number in this post is CUDA. CPU and Apple's CoreML get the pooled fp32 graph but not the fused fp16 one, and I haven't measured the CPU side.
No prebuilt binaries and no documented Windows support. You build it with cargo.
Read-only. It doesn't edit code and doesn't query across repositories.

Try it

cargo build --release -p codesage --features cuda   # drop --features cuda for CPU / CoreML
cd /path/to/your/project
codesage init
codesage index
codesage install-hooks
claude mcp add --scope user codesage -- codesage mcp

Codex users run codesage install codex --global instead of the last line. If you're on Claude Code, whetstone is the other half: CodeSage tells the agent what the code is, whetstone covers how to investigate, review and ship. The first index downloads the models: about 370 MB on CUDA, about 736 MB for the fp32 graphs on CPU or CoreML.

Nothing about CodeSage 0.38 required a better model. It required looking at what the existing one did between input and output, and at what the database did on every file delete. Most of that half hour was overhead around the model, not the model itself.

github.com/iliaal/codesage

Your coding assistant can now run a real SEO engine instead of guessing at one

Fri, 02 Oct 2026 11:23:53 +0000

Ask an AI assistant whether a page has SEO problems and you get an answer that reads well and cannot be checked. It might catch the missing canonical tag. It might invent a rule that does not exist. It might tell you the title is fine when there is no title. You have no way to tell which happened without knowing the answer already.

SEOCode now ships an MCP server, so the assistant stops answering from memory and starts calling the engine. Same rule engine that runs in our CLI and in our GitHub App PR review. It runs locally, on the file you point it at, and the model only formats what comes back.

Setup

One config block:

{
  "mcpServers": {
    "seocode": {
      "command": "npx",
      "args": ["-y", "-p", "@qobi/seocode", "seocode-mcp"]
    }
  }
}

That goes in Claude Desktop's claude_desktop_config.json, Cursor's MCP settings, or .mcp.json for Claude Code. Node 20 or newer. No account, no API key, no project setup.

The client launches seocode-mcp as a local child process and talks to it over stdio. Nothing is uploaded, and there is no network call in the audit path at all.

What it looks like

You ask your assistant to check a file. It calls audit_file and gets back something like this:

**app/products/[slug]/page.tsx** - 1 critical · 6 warning · 7 info

###  Critical
- **geo-ssr-hydration** - Critical metadata is set inside a useEffect hook, so it
  only exists after JavaScript runs on the client. AI crawlers process the
  server-rendered HTML first, so they never see it.
  - Fix: Move it into the Next.js Metadata API, export const metadata or
    export async function generateMetadata().

###  Warning
- **title-too-short**:6 - Title tags under 30 characters miss keyword opportunities.
  - Fix: Expand the title to at least 30 characters. Current: 24 chars.
- **missing-og-image** - Social shares with no og:image show no preview image.
  - Fix: Add <meta property="og:image" content="..." /> inside <head>.
    Recommended size 1200x630.

Every finding carries the rule id, the line where it can be pinned, and the fix. Then you say "fix the lazy loading one" and the assistant calls suggest_fix:

**1-click fix for `image-missing-lazy-loading`** in `public/gallery.html` (line 11):

  <img loading="lazy" src="/big-photo.jpg" alt="A large decorative photo of the skyline" />

This is a deterministic replacement - apply it directly.

That replacement is not written by the model. The engine produced it, then applied it against the current file to confirm it lands cleanly before handing it over.

The two tools

Tool	Arguments	Returns
`audit_file`	`filePath` required, `content` optional for an unsaved buffer	Findings grouped by severity, each with rule id, line, and fix
`suggest_fix`	`filePath`, `ruleId` required, `line` optional	A deterministic code replacement, or written guidance when the rule has no safe rewrite

suggest_fix will tell you when a rule has no auto-fix rather than producing one. Only transforms that can be made with certainty, like adding loading="lazy" or rel="noopener noreferrer", come back as replacements. Everything else comes back as guidance, labelled as guidance.

Why a tool call beats a prompt

The split matters more than it sounds. The engine does the SEO logic deterministically. The model is the interface: it decides which file you meant and reads the result back to you. The checks themselves cannot drift, cannot hallucinate a rule, and cannot be argued into a different answer on the second ask.

It is also the same engine, not a simplified copy. The MCP server loads the same rules/seo-rules.json the CLI and the GitHub App load, so a file that passes in your editor passes in the PR.

Two things it inherits from that engine:

Framework awareness. It reads titles and descriptions through Next.js generateMetadata(), Remix meta(), and Astro frontmatter the way the framework actually renders them. A page whose title comes from generateMetadata is not reported as missing a title. This is the part that makes the difference between a checker you keep and one you turn off after a day.

Your config. It walks up from the audited file looking for .seocode.json and honors the rule disables and severity overrides it finds there. The same file your team already committed for the CLI and the PR review.

What it does not do

It audits the file you point it at, when you ask. It does not scan your repo, track history, hold team config, or gate anything.

That is deliberate. One file on demand is the right scope for an editor. Enforcing the same rules on every pull request, for everyone on the team, without anyone remembering to ask, is a different job and that is what the GitHub App does.

How it is built

MCP is a smaller protocol than the tooling around it suggests. The whole server is about 260 lines with no SDK and no dependencies beyond what the engine already uses.

MCP over stdio is newline-delimited JSON-RPC 2.0. The client writes one JSON object per line to your process's stdin, you write one JSON object per line back to stdout. That is the entire transport. Four methods carry a tools-only server:

switch (method) {
  case 'initialize':
    return result(id, {
      protocolVersion: params?.protocolVersion || '2025-06-18',
      capabilities: { tools: {} },
      serverInfo: { name: 'seocode-mcp', version: version() },
    });
  case 'ping':
    return result(id, {});
  case 'tools/list':
    return result(id, { tools: TOOLS });
  case 'tools/call': {
    const text = await callTool(params.name, params.arguments ?? {});
    return result(id, { content: [{ type: 'text', text }] });
  }
  default:
    return error(id, -32601, `Method not found: ${method}`);
}

Three details worth knowing if you write one of these:

stdout belongs to the protocol. One stray console.log and the client sees a malformed message. All logging goes to stderr, including the startup banner.
Notifications get no reply. A message with no id is a notification. Answering it is a protocol error.
Buffer by newline, not by chunk. A single stdin chunk can hold two messages or half of one, so you accumulate and split on \n.

Because it is plain JSON-RPC on stdio, you can drive it without any client at all:

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18"}}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | npx -y -p @qobi/seocode seocode-mcp

That is also the fastest way to debug a server the client says is failing to start.

Try it

The MCP server is free and needs no account. Setup and troubleshooting live at seocode.io/mcp.

If you want the same rules enforced on every pull request instead of only when someone asks, the GitHub App is free for public repositories: seocode.io.

And if you only want to know whether you are blocking AI crawlers right now, the robots.txt checker at seocode.io/crawlers answers in a second with no signup.

Why the Enterprise Demands VPC for MCP: Deep Dive into SEOSiri’s Isolated AI Security Blueprint

Thu, 01 Oct 2026 08:36:31 +0000

The adoption of the Model Context Protocol (MCP) has changed how developers orchestrate contextual data between Large Language Models (LLMs) and systems. However, as autonomous AI agents move from local terminal playgrounds into the corporate workspace, a significant structural friction point emerges: Network Security.
Engineering and InfoSec teams have reached a turning point where exposing internal resources over standard public proxies is no longer viable.

This post analyzes the architectural necessity of supporting Virtual Private Clouds (VPC) for MCP architectures, details how the updated enterprise suite handles this natively, and explores why the corporate landscape is rapidly adopting SEOSiri Solutions.

1. The Architectural Problem: Why MCP Needed VPC Protection

The Model Context Protocol establishes a direct interface enabling AI clients to read schemas, execute local development scripts, and query underlying file structures. While highly effective, exposing this capability across public endpoints presents fundamental enterprise challenges:

Data Leakage Exposures: Without isolated boundaries, every database pointer, microservice context layer, and internal schema route traverses standard public internet paths.
Compliance Deadlocks: Regulated sectors (such as FinTech, Healthcare, and Defense) operate under strict internal mandates that strictly prohibit public ingress or egress configurations for core computational stacks.
Attack Surface Multipliers: Traditional public gateways require persistent firewall openings, increasing the vulnerability of internal development infrastructure to lateral scan vulnerabilities.

By introducing native VPC Support, MCP operations are brought directly into standard zero-trust network boundaries, enabling secure AI agent interaction behind isolated perimeters.

2. Deep Dive: How SEOSiri Bridges the Isolated Network Layer

The latest deployment module from the SEOSiri Developer Portal adapts the core Model Context Protocol to operate within fully locked-down cloud network structures:

[ Isolated Core VPC Subnet ]
├── Internal Data Source / DB
├── Proprietary Private Repository
└── SEOSiri Hardened MCP Server ──► [ Intercept / Scrubbing Layer ] ──► [ Local AI Client ]

Key Technical Capabilities Built into the Security Layer

Private Ingress Restrictions: Restricts incoming traffic utilizing granular CIDR-block parsing logic, ensuring only explicitly allowed cluster configurations can trigger context exchanges.
The PII Shield Intercept: Integrated directly within the internal server node, this pipeline monitors outgoing strings, automatically redacting and tokenizing sensitive values before structural arrays reach model reasoning endpoints.
Hybrid Cloud Topologies: Native multi-cloud support allows identical initialization frameworks whether your architecture resides on AWS VPC, Google Cloud VPC, or Microsoft Azure VNets.

3. Operational Advantages: The Core Benefits

Implementing an enterprise-grade VPC strategy for your contextual AI layer yields immediate architectural dividends:

Sub-Millisecond Processing Rates: Running the gateway close to local database partitions reduces transit latency overhead during highly interactive multi-turn agent execution sequences.
Native Log Stream Aggregation: System telemetry routes directly into your internal logging tools (like AWS CloudWatch, Google Cloud Operations Suite, or Datadog), keeping compliance audits fully within your administrative perimeter.
Consistent IAM Authentication Policies: Connects directly into existing enterprise access managers using OpenID Connect (OIDC) or strict OAuth2 verification schemas without requiring secondary secret tokens.

4. Why the Corporate World is Standardizing on SEOSiri MCP

Enterprise procurement and security management groups are shifting away from fragmented open-source wrappers toward verified setups for several critical reasons:

Production-Grade Stability: Rather than fragile point-to-point scripts, it provides an audited platform tailored for high-concurrency enterprise microservices.
Simplified Compliance Mapping: Pre-configured network isolation maps provide simple documentation validation for internal security review teams during software vetting cycles.
Future-Proof Extensibility: The platform offers structured integration options that work seamlessly with modern development tools like Claude Desktop, Cursor AI, and Atlassian Rovo without modifying original backend logic.

🛠️ Deploy Within Your Private Network / VPC Tunnels

Setting up an isolated instance within your internal network or Cloudflare Zero Trust framework requires minimal configuration changes. Configure the required secure environment flags upon runtime initialization:

# Initialize the SEOSiri hardened edge gateway via Cloudflare Zero Trust Tunnel (cloudflared)
# or via private container backend within your isolated VPC subnet:
docker run -d \
  --name seosiri-mcp-vpc-instance \
  --network="vpc-private-backend" \
  --publish 127.0.0.1:8080:8080 \
  -e ALLOWED_CIDR_BLOCKS="10.0.0.0/16" \
  -e ENCRYPTION_KEY_SECRET="$VPC_ENCRYPTION_KEY" \
  -e OAUTH_DISCOVERY_URL="https://developers.seosiri.com/.well-known/openid-configuration" \
  ghcr.io/seosiri-official/stal-mcp:latest

To access comprehensive configuration templates, cluster orchestration manifests, and step-by-step guides, visit the documentation space on the [SEOSiri Developer Portal][1].
For additional insights into this architecture and long-term release updates, check out the official announcement breakdown on the [SEOSiri Live Announcement Page][2].
------------------------------


  [1]: https://developers.seosiri.com/
  [2]: https://www.seosiri.com/2026/10/seosiri-mcp-vpc-support.html

How to Build an MCP Server in Golang Using the Official MCP SDK

Wed, 30 Sep 2026 06:51:40 +0000

What is MCP?
The Model Context Protocol is an open standard (by Anthropic) that lets LLM clients (Claude, Cursor, etc.) call external tools, read resources, and get prompted context in a uniform way — without any bespoke plugin per-model. You can read more about this on Model Context Protocol Docs

In this tutorial, we'll build a basic currency conversion MCP server using Golang and the official MCP SDK. We'll explore Streamable HTTP transport for remote access, add authentication to secure our server, and finally deploy the application to Render. By the end of this guide, you'll have a solid understanding of the complete lifecycle of building and deploying an MCP server in Go.

Prerequisites

Go 1.22+
Claude Desktop installed (for local testing)
Basic familiarity with Go modules and net/http

MCP Transports
MCP supports stdio and Streamable HTTP transport mechanisms that define how an MCP client and server communicate with each other. In this tutorial, we'll work with Streamable HTTP.

Streamable HTTP

Streamable HTTP allows MCP clients and servers to communicate over standard HTTP connections. The server runs independently and can be hosted remotely, making it accessible from different environments. Unlike stdio, Streamable HTTP allows the MCP server to live anywhere (local machine, Docker container, cloud VM, Kubernetes, etc.), making it much easier to share across multiple users.

Streamable HTTP is a better choice when you want to:

Deploy your MCP server to the cloud
Allow multiple clients to access the same server
Add features such as authentication and centralized monitoring
Manage your MCP server independently from the client application

Since we'll eventually deploy our currency conversion server to Render, Streamable HTTP will play an important role in moving from a local setup to a production-ready deployment.

Setting up Golang project

You can refer following blog for setting up a basic golang project. We will use the go-sdk for creating mcp server which is maintend by the mcp team.

go mod init example/mcp-server
go get -u github.com/gorilla/mux
go get https://github.com/modelcontextprotocol/go-sdk

Basic MCP Server

To start, we'll set up a very basic mcp server with just 1 tool. Before building the currency conversion tool, let's start with a minimal Greeting tool so we can understand the basic structure of an MCP server.

// main.go
package main

import (
...
)

func main() {
logger := slog.New(slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo}))

err := godotenv.Load()
if err != nil {
logger.Error("error loading .env file", "err", err)
}

mcpServer := server.NewMcpServer(logger)
mcpServer.AddReceivingMiddleware(security.LoggingMiddleware())

mcpHandler := mcp.NewStreamableHTTPHandler(func(request *http.Request) *mcp.Server {
return mcpServer
}, &mcp.StreamableHTTPOptions{
Logger:                     logger,
JSONResponse:               true,
Stateless:                  true,
DisableLocalhostProtection: true,
})

router := server.NewHttpServer(mcpServer, mcpHandler)

mcp.AddTool(mcpServer, &mcp.Tool{
Title:       "Greeting",
Name:        "greeting",
Description: "Greet a person by name",
}, SayHi)

port := os.Getenv("PORT")
if port == "" {
port = "3000"
}

server := &http.Server{
Addr:              ":" + port,
Handler:           router,
ReadTimeout:       5 * time.Minute,
ReadHeaderTimeout: 10 * time.Second,
WriteTimeout:      5 * time.Minute,
IdleTimeout:       5 * time.Minute,
MaxHeaderBytes:    1 << 20,
}

go func() {
logger.Info("starting server", "addr", port)

if err := server.ListenAndServe(); err != nil &&
err != http.ErrServerClosed {

logger.Error("server failed", "err", err)
os.Exit(1)
}
}()

ctx, stop := signal.NotifyContext(
context.Background(),
syscall.SIGINT,
syscall.SIGTERM,
)
defer stop()

<-ctx.Done()

logger.Info("shutdown initiated")

shutdownCtx, cancel := context.WithTimeout(
context.Background(),
30*time.Second,
)
defer cancel()

if err := server.Shutdown(shutdownCtx); err != nil {
logger.Error("shutdown failed", "err", err)
}

logger.Info("shutdown complete")
}

type GreetingInput struct {
Name string `json:"name" jsonschema:"the name of the person to greet"`
}

type GreetingOutput struct {
Greeting string `json:"greeting" jsonschema:"the greeting to tell to the user"`
}

func SayHi(ctx context.Context, req *mcp.CallToolRequest, input GreetingInput) (
*mcp.CallToolResult, any, error) {
return &mcp.CallToolResult{
Content: []mcp.Content{
&mcp.TextContent{Text: "Hi " + input.Name},
},
}, GreetingOutput{Greeting: "Hi " + input.Name}, nil
}

// server.go
package server

import (
...
)

func NewMcpServer(logger *slog.Logger) *mcp.Server {
 implementation := &mcp.Implementation{
  Title:   "MCP Tutorial For Greeting",
  Name:    "greeting-mcp",
  Version: "1.0.0",
 }

 serverOptions := &mcp.ServerOptions{
  Logger:    logger,
  KeepAlive: 5 * time.Minute,
 }

 return mcp.NewServer(implementation, serverOptions)
}

func NewHttpServer(server *mcp.Server, mcpHandler *mcp.StreamableHTTPHandler) *mux.Router {
router := mux.NewRouter()

router.HandleFunc("/health", func(w http.ResponseWriter, req *http.Request) {
w.WriteHeader(http.StatusOK)
_, _ = w.Write([]byte("ok"))
}).Methods(http.MethodGet)

// Optional root route to avoid confusion when testing in browser.
router.HandleFunc("/", func(w http.ResponseWriter, _ *http.Request) {
w.WriteHeader(http.StatusOK)
_, _ = w.Write([]byte("MCP server is running. Use /mcp endpoint."))
}).Methods(http.MethodGet, http.MethodPost, http.MethodOptions)

router.HandleFunc("/mcp", func(w http.ResponseWriter, req *http.Request) {
fmt.Printf(
"method=%s path=%s auth=%q\n",
req.Method,
req.URL.Path,
req.Header.Get("Authorization"),
)
mcpHandler.ServeHTTP(w, req)
}).Methods(http.MethodPost, http.MethodGet, http.MethodOptions)

return router
}

Here you can see for the http server we expose /mcp endpoint. This endpoint is not a REST endpoint that your application calls directly. It speaks the MCP protocol over HTTP and is intended to be consumed by MCP clients.

Understanding MCP Tools
I like to think of MCP tools as API endpoint which an AI agent or client understands and sends request to based on its analysis of the prompt user has typed. So it becomes very important how we name our MCP tool. You can read more on it here

Now lets build a real life example tool which could do currency conversion. For currency conversion I am using this free API which is provided by fawazahmed0 in the following github repo.

package tool

import (
...
)

// ConvertCurrencyInput is the input for the ConvertCurrencyTool
type ConvertCurrencyInput struct {
FromCurrency string  `json:"from_currency" jsonschema:"currency codes are ISO 4217 format, e.g. USD, EUR, GBP, etc. the currency to convert from"`
ToCurrency   string  `json:"to_currency" jsonschema:"currency codes are ISO 4217 format, e.g. USD, EUR, GBP, etc. the currency to convert to"`
Amount       float64 `json:"amount" jsonschema:"the amount to convert"`
}

// ConvertCurrencyOutput is the output for the ConvertCurrencyTool
type ConvertCurrencyOutput struct {
ConvertedAmount float64 `json:"converted_amount" jsonschema:"the converted amount"`
}

type CurrencyResponse struct {
Date string                        `json:"date" jsonschema:"the date of the currency rates"`
Data map[string]map[string]float64 `json:"-" jsonschema:"the currency rates"`
}

const BASE_CURRENCY_API_URL = `https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@latest/v1/currencies`

// ConvertCurrencyTool converts a currency to another currency
func ConvertCurrencyTool(ctx context.Context, req *mcp.CallToolRequest, input ConvertCurrencyInput) (*mcp.CallToolResult, any, error) {
input.FromCurrency = strings.ToLower(input.FromCurrency)
input.ToCurrency = strings.ToLower(input.ToCurrency)
fmt.Println("inside convert currency tool input", input)

apiURL := fmt.Sprintf("%s/%s.json", BASE_CURRENCY_API_URL, input.FromCurrency)
resp, err := http.Get(apiURL)
if err != nil {
return nil, nil, err
}
defer resp.Body.Close()

body, err := io.ReadAll(resp.Body)
if err != nil {
return nil, nil, err
}

response, err := UnmarshalJSON(body)
if err != nil {
return nil, nil, err
}

if _, ok := response.Data[input.FromCurrency]; !ok {
return nil, nil, fmt.Errorf("currency %s not found", input.FromCurrency)
}

if _, ok := response.Data[input.FromCurrency][input.ToCurrency]; !ok {
return nil, nil, fmt.Errorf("currency %s not found", input.ToCurrency)
}

convertedAmount := response.Data[input.FromCurrency][input.ToCurrency] * input.Amount
return &mcp.CallToolResult{
Content: []mcp.Content{
&mcp.TextContent{
Text: fmt.Sprintf("Converted amount: %f", convertedAmount),
},
},
}, nil, nil
}

func UnmarshalJSON(data []byte) (*CurrencyResponse, error) {
var r CurrencyResponse
var raw map[string]json.RawMessage

if err := json.Unmarshal(data, &raw); err != nil {
return nil, err
}

// Extract date
if v, ok := raw["date"]; ok {
if err := json.Unmarshal(v, &r.Date); err != nil {
return nil, err
}
delete(raw, "date")
}

// Remaining keys are currency codes
r.Data = make(map[string]map[string]float64)

for currency, v := range raw {
var rates map[string]float64
if err := json.Unmarshal(v, &rates); err != nil {
return nil, err
}
r.Data[currency] = rates
}

return &r, nil
}

Now to add the mcp server we do the following

// main.go

....

func main() {
...

mcp.AddTool(mcpServer, &mcp.Tool{
Title:       "Currency Conversion",
Name:        "currency-conversion",
Description: "Convert an amount from one currency to another. Requires from_currency, to_currency (ISO 4217 codes), and amount. Uses latest exchange rates from an external API.",
}, ConvertCurrencyTool)
...
}

Now lets understand what is happening here and how it works. First we register this tool using mcp.AddTool. Here Title is just human readable text and does not provide any help or context to the AI agent. Name and Description are 2 important things when registering a tool as this 2 piece of information helps the AI agent to make the decision on which MCP server should be used.

Now lets go to the ConvertCurrencyTool. This function takes 3 arguments which is the method signature and the 3rd parameter which is input is what we will focus on. It is like the request body that we expect to receive from the AI agent. In my case I am expecting fromCurrency, toCurrency and amount. For all the fields I have jsonschema specified which, like the tool description, helps the AI understand what each field represents. The SDK converts these tags into the MCP Tool schema that the model receives during tool discovery

The ConvertCurrencyTool makes an API call to fetch the latest exchange rates, performs the currency conversion, and returns the result to the MCP client.

There are a few more things which can be done during mcp server creation. Another useful server configuration is Instructions. These provide additional context to the AI model and can improve tool selection and overall responses.

func NewMcpServer(logger *slog.Logger) *mcp.Server {
implementation := &mcp.Implementation{
Title:   "MCP Tutorial For Currency Conversion",
Name:    "currency-conversion-mcp",
Version: "1.0.0",
}

serverOptions := &mcp.ServerOptions{
Logger:       logger,
KeepAlive:    5 * time.Minute,
Instructions: `You are a helpful assistant that can convert currencies. You can convert currencies using the currency-conversion tool.`,
        Capabilities: &mcp.ServerCapabilities{
Tools: &mcp.ToolCapabilities{},
},
}

return mcp.NewServer(implementation, serverOptions)
}

There is also one more important setting that we should we about when configuring the streamable http transport

mcpHandler := mcp.NewStreamableHTTPHandler(func(request *http.Request) *mcp.Server {
return mcpServer
}, &mcp.StreamableHTTPOptions{
Logger:                     logger,
JSONResponse:               true,
Stateless:                  true,
DisableLocalhostProtection: true,
})

Here the options part is important to understand. JSONResponse is basic tells if the response type is json or not. Stateless - this is one of the key option to understand. Stateless mode tells the server not to rely on MCP sessions. Every request should contain all information required to process it, making deployment behind load balancers and horizontal scaling much easier.. This is very well explained in Anthropic courses named Model Context Protocol: Advanced Topics. I ideally like to keep it to true as a REST API is always stateless and we use Authorization headers to validate the user so we can follow the same setup here too. The last option which is DisableLocalhostProtection again an important flag to be set to true when deploying to production. You can read more on this here.

To find more examples on how to create Prompt, Resource you can always refer following docs

How registration works

When we call:

mcp.AddTool(mcpServer, &mcp.Tool{
    Title:       "Currency Conversion",
    Name:        "currency-conversion",
    Description: "Convert an amount from one currency to another...",
}, ConvertCurrencyTool)

we are not creating a new HTTP endpoint like we would in a typical REST application. Instead, we're registering the tool with the MCP server.

From this point on, the lifecycle looks like this:

The tool is registered: The MCP server stores the tool's metadata, including its name, description, and input schema.
The MCP client connects: When a client such as Claude Desktop connects to the server, it asks the server which tools are available.
The server advertises its tools: The server responds with the list of registered tools, including their descriptions and JSON schemas.
The LLM decides whether to use a tool: When the user asks a question like:

How much is 28 USD in INR?

the model analyzes the request and determines that the currency-conversion tool is appropriate.

The client invokes the tool: The client sends a tool invocation request to the MCP server containing the required input
```
{
  "from_currency": "USD",
  "to_currency": "INR",
  "amount": 28
}
```
Your Go function executes: The Go SDK automatically deserializes the request into a ConvertCurrencyInput struct and calls: ConvertCurrencyTool(ctx, req, input)
The result is returned: Your function performs the currency conversion, returns the result, and the SDK sends it back to the client. Claude then uses that result to generate its final response to the user.

Conclusion
In this tutorial, we built a complete MCP server in Go using the official Go SDK. We started with a simple greeting tool, expanded it into a practical currency conversion service, exposed it using Streamable HTTP, discussed important server configuration options.

In the next step, you can deploy the same server to Render and make it accessible remotely without changing the MCP client configuration.

The complete source code for this tutorial is available on GitHub:

GitHub Repository: https://github.com/shaileshhb/mcp-tutorial

One common misconception about MCP:

Tue, 29 Sep 2026 05:10:52 +0000

MCP is used to connect AI agents to tools.

Not only that.

Tools are just one of the three core primitives an MCP server can expose.

These three components are:

Resources - data/context that the AI application can access

For example, an email, a file, a database record, or documentation.

Prompts - reusable prompt templates for specific interactions.

For example, a predefined "review this pull request"; prompt.

Tools - functions that the AI application can execute.

For example, send an email, create a Jira ticket, or book a flight ticket.

So a better mental model is:

Resources ->Read

Prompts -> Guide

Tools -> Do

This distinction matters because when you think of MCP only as a way to connect tools, you miss a significant part of what the protocol actually provides.

Now, the question for you is

Why not just put the prompt in the agent's system prompt? Why access it through MCP?

CData's New AI Gateway Puts Context at the Center — Fixes the Three Reasons Enterprise AI Stalls

Tue, 29 Sep 2026 00:06:14 +0000

Most enterprise AI programs are stuck. Not because the models are bad, but because the underlying infrastructure can't keep up. Costs are climbing, productivity gains are flat, and organizations are locking down access rather than expanding it because they don't have the governance controls they need to feel comfortable.

CData Software has been watching this pattern play out across hundreds of enterprise deployments over the past year. On September 29, the company is announcing what it sees as the fix: CData Connect AI Gateway, a single control point between AI agents and the enterprise systems they need to act on.

Three Problems. One Control Point.

Marie Forshaw, CData's SVP of Product Marketing, laid out the three challenges clearly during a pre-launch briefing. They're likely familiar to anyone who's been building or deploying AI in an enterprise context.

The first is rising costs. AI budgets are burning through faster than organizations can justify. Without fine-grained visibility into who's using what model for what task, finance teams are doing the only thing they can: shutting things down.

The second is stagnant productivity. Some of that is the lockdown. But Forshaw pointed to two other contributing factors: ongoing accuracy and reliability issues with AI responses, and a near-total freeze on write operations. Most organizations have enabled read use cases — querying data, summarizing it, surfacing it. Very few have enabled AI agents to actually take action. The risk is too high, and the controls aren't there.

The third is governance. This is where the developer-versus-leadership tension gets real. Forshaw made the point directly: developers may not care much about centralized control, but CTOs and CIOs absolutely do. And without their sign-off, AI projects don't scale.

Connect AI Gateway is designed to address all three from one place.

What the Gateway Actually Does

The platform has four layers. Two of them — data connectivity and security controls — are existing CData capabilities. The two new layers are the gateway itself and a context engine, and they're where most of the interesting development is happening.

The Gateway Layer handles model routing, MCP traffic, and agent orchestration. It registers models, MCP servers, and agents once, then routes requests based on availability, cost, and latency. Intent-based routing is part of this — the system reads the complexity of a prompt and sends simpler requests to cheaper models automatically. Token budgets can be set at the team, agent, or tool level, giving organizations real cost visibility and control rather than a blunt shutdown switch.

The Context Engine is the more distinctive part of the announcement. CData's argument is that most gateway providers are just routing traffic between models and MCP servers. Because CData owns the connection all the way down to the source system, it can build up and apply business context at every step of a request — and that's what separates useful AI from AI that keeps getting things wrong.

The context engine pulls from four sources: company knowledge (documented processes, SOPs, Slack and Teams conversations), semantic definitions (imported from Power BI, BigQuery, dbt, or built natively in the platform), system context (schema, relationships, and field meanings from connected source systems), and data modeling (cross-source joins and derived views that calculate answers before they reach the model).

Everything gets normalized into Open Knowledge Format and visualized as a context graph that administrators can edit and extend.

The Self-Learning Loop

One of the more forward-looking pieces of this announcement is a self-learning capability CData is calling the self-learning loop. The idea is that every interaction makes the system smarter — prompt patterns become vocabulary, query patterns become join hints, user-level corrections get written back to the knowledge bundle, and facts that multiple users share get promoted to company-wide knowledge.

This capability is pre-beta at announcement. No customers are in production with it yet, so there's no empirical data on how long the improvement curve takes in practice. CData acknowledges that directly. The honest answer is: we'll know more in six months.

Organizations will have control over what gets promoted from personal to shared knowledge. Everything can require human approval before it becomes part of the company context, or you can set specific categories to promote automatically. That configurability matters for teams with compliance requirements.

The Numbers: Accuracy and Cost

CData's accuracy benchmarking from earlier this year showed Connect AI at 98.5% accuracy across 378 enterprise queries, compared to 65–75% for competing MCP providers. That gap matters more as AI moves from read to write operations — a 70% accuracy rate on an agent that's taking action in your ERP is not a productivity tool. It's a liability.

The newer study, published just before this briefing, tested 22 models against live enterprise data — with and without Connect AI's data layer configured. With it, every model answered correctly. Without it, every model made mistakes. The cost spread between the cheapest model tested (Mistral Small) and the most expensive (Claude Fable 5.1) was 175x.

Jared Johnson, CData's Director of Technology Evangelism, explained the mechanism clearly. When you ask an AI to list your five healthiest customers, it has no idea what "healthy" means in your context. You can put that definition in the system prompt, but that doesn't guarantee it gets honored. When you build that definition into a derived view inside Connect AI, the model can't get it wrong — because it doesn't have access to the raw fields. It only gets the calculated answer. The model isn't doing the reasoning. CData is.

That's the architecture. And it's why the same cheap model can deliver the same correct answer as one that costs 175 times more.

Developer Setup: Minutes to Hours

Adobe cut regression test delivery from ten weeks of manual effort to roughly one week by connecting to SAP through Connect AI and running a test automation agent. For developers wondering what setup actually looks like: basic authentication to a source system can be done in minutes. A working agent with governed access typically takes hours to a day. From there, it's an iterative process — start with minimal configuration, dial in derived views and custom tools over time as the workflow becomes clearer.

The path from 70% to 98.5% accuracy isn't a configuration switch. It's a development process. But the starting point is lower-friction than building your own MCP server stack.

The Honest Case for Switching

For development teams already running their own MCP servers, the question is fair: why hand that off to a managed platform? Johnson's answer was practical — it can seem cheaper and faster to manage your own servers when you're working on one system. The complexity compounds when you're trying to manage MCP access across multiple systems with different security models, different permission structures, and different teams using different tools.

What CData is offering is the centralized governance layer that makes it possible to turn on write operations without giving a CIO a reason to shut the whole program down. That may matter less to individual developers in the short run. It matters a lot to the people deciding whether to renew the AI budget.

Bottom Line

CData Connect AI Gateway enters an increasingly crowded market. Several AI gateway announcements have come out in the past few months, and CData is not the only company making the data-layer argument. But the company has a legitimate differentiator in owning the source system connection — not just the routing layer above it — and the cost study is a concrete illustration of what that unlocks.

The self-learning context engine is the most interesting long-term bet in this announcement, and also the one with the least evidence behind it yet. Worth watching as customer data comes in.

Connect AI Gateway is available through an early access program beginning September 29, 2026. More information at cdata.com.