标签：#mcp

Part of a series on building cz-agents → under the hood. Where we left off In June, I compared the three camps of agentic payments here—x402, card tokens, and banks—and argued that x402 will take machine-to-machine micropayments, while cards and banks split the rest. I won't repeat the basics of the protocol, how the 402 status code works, or why cards don't add up economically on tiny amounts; anyone who needs a refresher will find it in that article. This piece is about something else. A few weeks have passed; the numbers and the big-player backing have both jumped by an order of magnitude, and for the first time, I can compare those figures against what I actually see in my own logs. The gap between the two is the entire point of what follows. The numbers are hard to miss I'll start with what speaks for x402, because that's the more honest approach. According to aggregate Chainalysis data, the protocol has processed over 169 million payments so far, between roughly 590,000 buyers and 100,000 sellers. That's no longer a conference demo. More interesting than the volume is the structural shift. The share of transactions above one dollar rose from 49% in early 2025 to roughly 95% in early 2026. In other words: x402 is ceasing to be a toy for micro-cents and is starting to handle amounts that actually show up on the books. Anyone who wrote the protocol off as a curiosity for paying fractions of a cent per API query is looking at an old snapshot. Above all, a lineup has assembled that is hard to dismiss as crypto-bubble enthusiasts: Stripe launched x402 support on February 10, 2026, in the preview of its Machine Payments product (USDC on the Base network). Ripple added native x402 to the XRP Ledger on June 21, 2026. AWS built x402 into Bedrock AgentCore Payments—together with Coinbase and Stripe—and also lets you monetize agent traffic on CloudFront and WAF. Sites behind Amazon's edge can charge agents right at the edge, without touching their core application. Google

🚀 AI is becoming smarter every day. But intelligence alone isn't enough—it also needs a standardized way to communicate with tools, applications, and data. That's exactly what Model Context Protocol (MCP) provides. 🚀 Introduction The AI landscape has evolved rapidly over the past few years. We've moved from simple chatbots to: 🤖 AI coding assistants ⚙️ Autonomous agents ☁️ Cloud automation 📊 Infrastructure monitoring 🔄 Intelligent workflows But one major challenge still exists: How can AI securely communicate with external tools like GitHub, AWS, Docker, Kubernetes, Slack, databases, and local files? Until recently, every AI company built custom integrations. That meant: duplicated engineering effort inconsistent APIs difficult maintenance poor interoperability To solve this problem, the AI ecosystem is adopting a new open standard called Model Context Protocol (MCP). 🤔 What is Model Context Protocol (MCP)? Model Context Protocol (MCP) is an open protocol that standardizes how AI models communicate with external tools, APIs, databases, applications, and services. Instead of every AI assistant creating custom integrations for every service, MCP provides one common language. Think of MCP as: 🔌 USB-C for AI applications. Just as USB-C lets different devices communicate using one standard, MCP allows different AI assistants to connect to external systems in a consistent way. ❌ The Problem Before MCP Imagine you're building an AI DevOps assistant. It needs access to: GitHub Docker Kubernetes AWS Terraform Jenkins Prometheus Grafana Local Files Internal Documentation Without MCP, you'd need to: Learn every API separately Build authentication repeatedly Maintain multiple SDKs Handle different response formats Continuously update integrations Every AI application repeats the same engineering work. This approach is: ❌ Time-consuming ❌ Expensive ❌ Difficult to maintain ❌ Hard to scale ✅ How MCP Solves This Problem MCP introduces a standardized communication layer between AI m

Part 6 (finale) of Retrieval-Augmented Self-Recall. Code: RE-call . Part 5: the gap threshold that didn't transfer . I fine-tuned the embedder on my own domain expecting a win. I measured it properly, on held-out queries. The improvement was exactly zero. Δ+0.00 MRR. Δ+0.00 nDCG@10. Not "small". Not "within noise". Zero. It's also the result I wanted, which takes some explaining. That's the first half of this post. The second half is how the whole engine ships, so an agent can actually use it. The fine-tune that did nothing After Part 5, the natural next question: if calibrating the threshold helps, would a better embedding help more? So I fine-tuned one on my domain. The setup: all-MiniLM-L6-v2 , OnlineContrastiveLoss on query/gold-chunk pairs, trained on the 14-document corpus. The result: Model Test MRR Test nDCG@10 Base 1.00 1.00 + Fine-tuned 1.00 1.00 Δ +0.00 +0.00 Zero lift. And that is the correct outcome, not a failed experiment. Here's the reasoning, because it's the whole point. The base model already scores a perfect MRR and nDCG@10 on this corpus. There is no headroom left to recover. The only ways to manufacture a "gain" from here would be dishonest ones: evaluate on the training set (and measure memorization, not retrieval), or artificially cripple the baseline so fine-tuning has something to fix. Reporting +0.00 is the honest read, and the honest read is that off-the-shelf embeddings already saturate this corpus. But the full result is more nuanced, and more useful. On a harder , opaque-jargon corpus — one where the base model genuinely struggles to map queries to the right chunks — the same fine-tuning gave +0.24 MRR . So the real conclusion isn't "fine-tuning doesn't work." It's: Fine-tuning helps when the base model doesn't already cover your vocabulary. When it does, you get nothing. Know which regime you're in before you spend the GPU hours. That's the value of a null result. "+0.00" told me my corpus was already well-covered by a general-purpose

footnote-mcp is a Python MCP server installable via pip, Docker, or pipx. No API keys required — it falls back to scraped Bing + DuckDuckGo search and automatic headless Chromium for JavaScript-heavy pages. The Verification Pipeline The core tool is evidence_entailment . It takes a claim and a source text, and returns whether the claim is supported, unsupported, or contradicted. The heuristic backend extracts numeric and named-entity tokens from both the claim and source, then checks for exact matches and contradictions. On its design domain — numeric and factual data claims — it achieves 100% accuracy on a labeled benchmark set. For semantic cases (negation, paraphrase), the ollama backend uses a local LLM as a judge. Three tools build on this: corroborate_claim triangulates a claim across multiple sources, locate_claim_span finds the exact supporting sentence with character offsets, and build_research_debug_report produces a compact report of queries, URLs, and verification gaps. The Fetch Ladder web_read fetches pages through a 5-tier escalation ladder: HTTP (curl_cffi) to rotating proxy to headless Chromium to Chromium through proxy to hosted scrape API (Firecrawl/ScrapingBee). A block/quality detector decides when to escalate, and per-domain rate limiting, circuit breakers, and negative cache keep it polite. Search Backends web_search supports Tavily, Brave, Google, or scraped Bing + DuckDuckGo as fallback. Pass semantic: true to reorder results by meaning using local Ollama embeddings. Structured Data and Browser Tools Beyond text, the server handles tables, CSV/XLSX/PDF/JSON, date validation, unit resolution, and time series reconciliation. For JavaScript-heavy pages, 10 browser tools let you drive a headless Chromium session. When generic parsers fail, the server can synthesize sandboxed extraction code through a controlled recipe system. Benchmark Results The heuristic backend achieves 100% accuracy on numeric and factual data claims (n=15). Overall accurac

When I built the MCP server for this project — it combines GitHub and DEV.to into a set of tools an agent can call — I had a decision to make before writing a single tool: talk to the low-level MCP protocol directly, or use FastMCP 's decorator API. I've seen a few "your first MCP server" writeups lately walk through the low-level path because it's more "honest" about what MCP actually is under the hood — JSON-RPC over stdio, a capabilities handshake, typed request/response schemas. That's true, and it's a reasonable thing to want to understand. But I want to write about the other side: what it actually costs you in practice once you have more than one or two tools, because I went through both and the difference showed up fast. what the low-level path actually asks you to write Strip away the decorator and MCP is a JSON-RPC server. For every tool you add, you're responsible for: Registering the tool's name, description, and a JSON Schema for its inputs in a list_tools handler Writing a call_tool dispatcher that matches on tool name and unpacks arguments by hand Serializing the return value into the TextContent / ImageContent wrapper types MCP expects Keeping the schema you wrote in step 1 in sync with the arguments you actually read in step 2, by hand, forever None of that is hard in isolation. The problem is it's boilerplate that scales linearly with tool count and has zero connection to the actual logic of the tool. My server has 8 tools. Hand-rolled, that's 8 schema blocks plus a dispatcher if/elif chain plus 8 response-wrapping calls, all of which exist purely to satisfy the protocol, not to do anything a GitHub or DEV.to API call needs. what it looks like with FastMCP Here's an actual tool from server.py , unedited: @mcp.tool () def get_repo_stats ( repo : str ) -> dict : """ Get stars, forks, watchers, open issues for enjoykumawat/<repo>. """ r = _gh ( f " /repos/ { GITHUB_USERNAME } / { repo } " ) return { " name " : r [ " name " ], " stars " : r [ " stargaze

The most expensive thing you can do with an AI agent is watch it. Not audit it. Not review its output. Watch it -- step by step, approval by approval, second-guessing every action before it takes the next one. And yet that is precisely how most engineering teams are deploying AI agents in 2026: on a leash so short the agent cannot take three steps without a human tapping it on the shoulder. I understand why. The models hallucinate. The stakes are real. Nobody wants to be the engineering manager who let an AI agent push a bad migration to production at 2am. So we wrap the agents in confirmation dialogs, require human sign-off at every branch point, and celebrate our careful governance. What we have actually built is an automation system that requires more human attention than the manual process it replaced. The better answer is not more control at the action level. It is better design at the intent level. Steer by intent, monitor by exception. Tell the agent clearly what outcome you need, what it must never do, and what constitutes a result worth stopping for. Then let it work. Watch the outcomes, not the steps. We have built automation systems that require more human attention than the manual process they replaced. That is not a governance success. That is a design failure. Why we got here The model for human-AI collaboration that most teams are using today was inherited from the model for junior developer supervision. You review every pull request. You approve every deployment. You sign off on every schema change. That model exists because junior developers are learning, because their mental models are incomplete, because their judgment has not yet been earned. Applied to AI agents, it assumes the same thing: the agent is a novice that needs supervision. But an AI agent is not a junior developer. It does not have an incomplete mental model of the codebase that will improve with mentorship. It has exactly the mental model you gave it via its context, its tools, and

A practical, end-to-end walkthrough of taking a read-only slice of an enterprise source system and exposing it to an AI agent as a set of Model Context Protocol (MCP) tools — using Azure Logic Apps, API Management, and Agent Foundry. All identifiers below are placeholders; swap in your own. The goal We wanted a simple outcome: a user asks a business question in plain language and gets a straight answer — no dashboards, no field names, no training on the underlying system. That means an AI agent with safe, read-only access to a backend system of record, exposed as discrete tools the model can call. The constraints shaped every decision: Read-only. The agent can retrieve and analyze, never write. Safe. Records in most business systems contain free text (notes, subjects, descriptions) that could carry prompt-injection payloads. Tool output must be treated as data, never instructions. Composable. The agent should see many small, well-described tools — "list records", "aggregate by category", "record change history" — not one giant "query the system" tool. The architecture Five layers, one direction of flow: Agent (Agent Foundry) │ MCP (JSON-RPC over HTTP) ▼ MCP server (API Management) │ REST operation per tool ▼ API gateway (API Management) │ single POST, routed by body ▼ Tool executor (Logic App) │ OAuth token + REST calls ▼ Source system (REST API) The key design choice: one backend endpoint, many logical tools. The Logic App exposes a single HTTP trigger that accepts { "tool": "records.list", "parameters": { ... } } and routes internally. API Management then fans that single endpoint out into many named operations, and its MCP feature turns those operations into agent tools. This keeps the backend trivial to maintain while the agent still sees a rich, typed tool catalog. Step 1 — Design the tools Start from the questions , not the schema. A useful toolset usually falls into a few families: Records: list / get / search / filter for the core business entities. Activity

In 1995, Netscape released SSL. The web didn't really take off commercially until then. Before SSL, you couldn't trust a website with your credit card. After SSL, e-commerce exploded. AI agents are at the same inflection point in 2026. Here's why. The problem Agents are starting to call each other autonomously. Each hop is a trust decision. But agents have no way to verify each other. Today, when Agent A calls Agent B: Is Agent B who it claims to be? No way to verify Has Agent B been audited for security? No standard Has Agent B's key been compromised? No revocation mechanism This is exactly where the web was in 1994. No SSL, no trust, no commerce. The analogy Web (1995) Agents (2026) HTTP (transport) A2A + MCP (transport) No HTTPS = can't trust No ATC = can't trust SSL certificate ATC Trust Card Certificate Authority MarketNow Sentinel CA Revocation list (CRL) /api/atc?action=verify What I built ATC (Agent Trust Card) — SSL certificates for AI agents. How it works Agent registers with MarketNow CA CA signs the agent's identity with Ed25519 Agent presents its ATC to other agents Other agents verify the signature with the CA public key If compromised, the CA revokes the ATC Real cryptography (not a mock) Ed25519 signatures (RFC 8032) CA private key in Vercel env var (never exposed) CA public key committed to public GitHub repo Every ATC persisted as signed JSON in _data/atc/ Anyone can verify signatures offline using crypto.verify Sentinel integration The ATC's trust score comes from Sentinel — the 8-layer security audit pipeline: L1.5: metadata checks L1.6: Semgrep + secrets + OSV L1.7: binary/malware detection L1.8: malware family signatures (Emotet, Cobalt Strike, etc.) The positioning MarketNow is not competing with A2A or MCP. It's the trust layer that sits on top: ATC (Trust Layer) <- MarketNow A2A / MCP (Transport Layer) <- Google / Anthropic HTTP / WebSocket (Network) <- Standard Every agent with an A2A card can have an ATC Trust Card. Every MCP skill can hav

In my last post, I walked through a RAG pipeline that answers questions from a company policy document. The next question I wanted to answer: what happens when I want other AI systems to use that same capability, without hardcoding a Python import? That's what pulled me into building an MCP server. In this article, I will explain how I built a custom MCP server that exposes tools to AI agents and how this architecture enables more powerful enterprise AI applications. What is MCP? Model Context Protocol is an open protocol that standardizes how AI applications communicate with external tools and data sources. Instead of creating custom integrations for every AI application, MCP provides a common interface where servers expose tools that AI clients can discover and invoke. Technology Stack Python, MCP SDK, Ollama / Local LLM, AI Agent Client, FastAPI (optional integration). What's actually in the server I built this with FastMCP, and it currently exposes four tool categories: Calculator tools — calculator_add and calculator_multiply. search_company_documents — the RAG agent from my last project, but now reached over HTTP instead of a direct function call. The MCP tool sends a request to the RAG agent's FastAPI /search endpoint and returns the answer. This one requires an api_key parameter. get_employee_leave — looks up an employee's remaining PTO from an in-memory store. Simple lookup, no external calls. get_ticket_information — same pattern, returning ticket status, assigned team, and priority. Each tool is registered with a @mcp .tool() decorator, which is what makes FastMCP genuinely pleasant to work with. Challenges I Encountered The calculator, employee, and ticket tools were straightforward pure functions with no external dependencies. The RAG search tool was a different problem entirely, and it was the hardest part of this whole project. My RAG agent runs as its own FastAPI service, on its own process, with its own vector store loaded into memory. The MCP serve

Exposing your data over MCP is the easy part. Designing a tool an agent uses well is the hard part. An agent can only use a tool it can read, so the work is shaping the tool for how the model calls it, not just for the human looking at the result. These are the techniques behind @bonnard/mcp-charts and the visualize tool. Discovery-first, so the agent stops guessing An agent that guesses your schema writes wrong queries. So the first tool the agent meets is a discovery tool. It calls visualize_read_me to load the chart options, the tool schema, and worked examples before it ever calls visualize , and an explore_schema tool to learn your tables and columns before it writes SQL. The agent reads, then acts. A small set of purpose-built tools The temptation is one tool per metric, or a single tool that takes arbitrary SQL and hopes. Both fail: too many tools blow the agent's attention budget; one firehose tool gives it no guardrails. Bonnard ships a small set, discover, query, visualize, each with a narrow, obvious job. The agent picks the right one because there are few of them and each does one thing. // a small, purpose-built set, not one tool per metric server . registerTool ( " explore_schema " , { /* list tables + columns */ }, listSchema ); addCharts ( server , { runSql }); // registers visualize_read_me + visualize Compact, honest responses A tool that returns 10,000 raw rows poisons the context window and the agent's next decision. Bonnard's responses are sized for a model to read: Row caps with a completeness flag. Results are capped and tagged partial or complete , so the agent knows whether it is looking at everything. Partial-result warnings. When results are capped, the response says so and tells the agent not to sum or average the visible rows, use a measure instead. Summaries over dumps. The chart comes back with a compact text summary the model can reason over, not just an image it cannot read. Errors that guide the next action A bare "error: invalid co

Most teams connecting AI agents to their data warehouse start with text-to-SQL. The agent generates SQL from natural language, runs it against the warehouse, and returns results. It works until it doesn't: hallucinated JOINs, inconsistent aggregations, no access control, no audit trail. There's a better approach. Define your business metrics in a semantic layer, expose them via MCP (Model Context Protocol), and let any AI agent query governed definitions instead of raw tables. Then add one tool so the agent can chart the result in Claude or ChatGPT. This tutorial shows how to set it up in under 30 minutes. Why does text-to-SQL break in production? The agent sees column names but not business logic. It doesn't know that your company excludes refunds from revenue. It doesn't know that status = 'completed' means something different in orders than in subscriptions . It doesn't know that marketing and finance defined "active user" differently three years ago and never reconciled. So the agent writes plausible SQL and returns plausible numbers. Ask the same question twice with different phrasing and you get different answers. Ask two different agents and you get two different numbers. Neither matches the number your finance team reports. Beyond consistency, there's no row-level security. No multi-tenancy. No audit trail showing which agent queried what, when, and for whom. In production, with real customers, that's a non-starter. Text-to-SQL gives you speed. It doesn't give you trust. What is the semantic layer approach? Instead of letting agents write arbitrary SQL, define your metrics once in YAML: cubes, measures, dimensions, access rules. Then expose those definitions via MCP so agents query governed metrics, not raw tables. The difference: every agent gets the same answer because the metric definition is fixed. total_revenue isn't a column the agent interprets. It's a pre-defined calculation with agreed-upon filters and aggregations. When your finance team updates th

MCP for AWS Security Engineers: Build a Read-Only Security Hub Triage Agent For AWS-heavy security work, I would start with AWS Agent Toolkit for AWS and the managed AWS MCP Server , not a custom MCP server. The reason is practical. AWS now provides a managed MCP path that can connect AI coding agents to AWS documentation, AWS APIs, AWS skills, and existing IAM credentials. The Agent Toolkit also provides plugin-based setup for supported agents such as Claude Code and Codex. For security teams, that is the right starting point because the enforcement point remains AWS IAM, not the model. The initial operating model should be strict: Read-only first. No production write authority. No access to secrets. No raw customer PII or sensitive incident logs in prompt context. No automatic remediation. No AI-approved suppression, exception, merge, deploy, or risk acceptance. Human review and CI/CD remain the release authority. That is the same posture I would use for a governed Claude Code or Codex rollout: named identities, SSO, scoped credentials, default deny, tool approval, audit logs, and security evidence tied back to tickets, pull requests, CI logs, and cloud findings. What we are building This article walks through a practical security workflow: A read-only Security Hub triage assistant that helps a junior security engineer produce a daily or weekly findings summary, remediation backlog, and evidence pack without allowing the agent to modify AWS. The agent will be able to: Read AWS Security Hub findings. Group findings by account, severity, product, resource, and control. Explain why a finding matters. Draft remediation tickets. Draft a Slack-ready summary. Produce local markdown, CSV, and JSON evidence files. The agent will not be able to: Suppress findings. Archive findings. Mark findings resolved. Disable Security Hub standards. Modify IAM, S3, EC2, KMS, GuardDuty, Inspector, or Config. Deploy remediation. Run destructive scripts. Approve risk acceptance. This is no

GitHub announced on July 2, 2026 that Issue fields are generally available, including integration with GitHub's MCP server. Primary source: GitHub Changelog, July 2, 2026 . That creates a useful beginner project: validate structured issue metadata before an MCP client—or any program—uses it. The schema below is invented for learning. It is not GitHub's API schema. Define three fields // schema.mjs export const schema = { priority : { kind : " singleSelect " , required : true , options : [ " P0 " , " P1 " , " P2 " , " P3 " ] }, estimate : { kind : " number " , required : false , min : 0 , max : 100 }, customerImpact : { kind : " text " , required : false , maxLength : 120 } }; A schema describes both type and domain rules. estimate must be a number, but it also has to fit the range this project accepts. Validate at the boundary // validate.mjs import { schema } from " ./schema.mjs " ; export function validate ( input ) { const errors = []; if ( ! input || Array . isArray ( input ) || typeof input !== " object " ) { return [ " fields must be an object " ]; } for ( const [ name , rule ] of Object . entries ( schema )) { if ( rule . required && ! ( name in input )) errors . push ( ` ${ name } : missing` ); } for ( const [ name , value ] of Object . entries ( input )) { const rule = schema [ name ]; if ( ! rule ) { errors . push ( ` ${ name } : unknown field` ); continue ; } if ( rule . kind === " singleSelect " && ( typeof value !== " string " || ! rule . options . includes ( value ))) { errors . push ( ` ${ name } : expected ${ rule . options . join ( " , " )} ` ); } if ( rule . kind === " number " && ( typeof value !== " number " || ! Number . isFinite ( value ) || value < rule . min || value > rule . max )) { errors . push ( ` ${ name } : expected ${ rule . min } .. ${ rule . max } ` ); } if ( rule . kind === " text " && ( typeof value !== " string " || value . length > rule . maxLength )) { errors . push ( ` ${ name } : expected at most ${ rule . maxLength } charact

I gave one model the same 44-node architecture twice. The first time I asked for raw SVG — place every box, route every edge, hand me the coordinates. The second time I asked it to describe the same system as typed JSON and let a layout engine draw it. Same model, same session, same brief. The only thing I changed was the output boundary. The boxes are fine in both. I want to be upfront about that, because the usual version of this pitch is out of date. Models place labeled boxes well now. If you ask a current frontier model for a six-box flowchart as SVG you get a clean six-box flowchart, and if that's what you need, go do that — it's the right tool and I'm not going to pretend otherwise. What broke was the edges. With no routing algorithm the model just drew long diagonals straight through unrelated boxes. Not a few — everywhere the graph got dense. And when I changed one node, the entire hand-placed coordinate layout had to be regenerated, and came back different. That second part is the one that actually annoyed me. It's not a rendering bug you can squint past. The picture is a dead artifact: you can't diff it, you can't edit one box, you can't get the same one twice. Every change is a full regeneration and a fresh roll of the dice. This isn't a "wait for a better model" problem Here's the part I'd push back on if someone else wrote it, so let me make the case. Routing a connector around obstacles across a nested graph is global constraint optimization. It's the specific thing layout engines like ELK exist to solve. A model emitting SVG has to commit to an x/y for every point, in order, with no way to backtrack once it sees the whole picture — it's predicting the next token, not solving a layout. So a better model gives you nicer boxes, not untangled edges . The failure is structural, and I'd expect it to reproduce across models past a couple dozen nodes. If you don't buy that, the honest move is to test it: throw a 40-node architecture at whatever model you tru

I built a small MCP server a while back — developer-presence , seven tools wrapping the GitHub REST API and the DEV.to API so an agent can check my repo stats, list my articles, or draft a new post without me leaving the chat. It's mine, I wrote every line, there's no third-party package doing anything sketchy under the hood. By the usual "vet your MCP servers before installing them" checklist, it passes clean. I've written that checklist article before. What I hadn't thought carefully about until recently is that vetting the server doesn't vet the data. Two of its tools go straight to the point: @mcp.tool () def get_repo_stats ( repo : str ) -> dict : """ Get stars, forks, watchers, open issues for enjoykumawat/<repo>. """ r = _gh ( f " /repos/ { GITHUB_USERNAME } / { repo } " ) return { " name " : r [ " name " ], " stars " : r [ " stargazers_count " ], " forks " : r [ " forks_count " ], " watchers " : r [ " watchers_count " ], " open_issues " : r [ " open_issues_count " ], " language " : r . get ( " language " ), " description " : r . get ( " description " ), } description is free text. Any repo owner can put anything in it. If I ever point this tool at a repo I don't control — someone else's fork, a dependency, anything — that field lands in my agent's context exactly the same way a trusted instruction would: as text in a tool result, with no marker distinguishing "this came from GitHub's database, unfiltered" from "this is something I told the agent to do." The server is safe. The channel is safe. The payload was never vetted at all, because there was nothing to vet — it's just whatever a stranger typed into a form. I only really felt this because of a task I run on a schedule: check dev.to for trending posts in a few tags, score them, and use the highest scorers as source material for what to write about next. Step one of that job is a loop over tag pages: for tag in [ " ai " , " llm " , " mcp " , " claudecode " , " agents " , " productivity " ]: url = f " http

If Claude can already search the web, read a 10-K, and explain what a rate cut does to long-duration equities, the fair question is why you would connect anything to it at all. It is the right question, and the honest answer is that for a large class of questions you should not. Raw Claude is enough. The gap is narrower and sharper than "Claude does not know finance." Claude knows finance. What it does not know is you. What raw Claude already does well Be clear about this before the sales pitch, because pretending otherwise would insult anyone who has actually used it. Claude with web search will look up a current quote, summarize an earnings call, explain a valuation multiple, walk you through how a Monte Carlo simulation works, and reason about a macro scenario better than most of the commentary you would read instead. If your question is about the world, and not about your own balance sheet, a connector adds nothing. Ask Claude directly. The trouble starts the moment the answer depends on what you actually own. Four things that break when the question is about your money 1. It starts from zero every time A chat has no memory of your holdings. You can paste them in, and many people do, and it works for exactly one conversation. There is no cost basis, no purchase date, no daily snapshot series behind it. So "how concentrated am I really", "what is my realized gain this year", and "how correlated are my top five positions over the last 90 days" are not questions it can answer. It can only answer them about the numbers you re-typed, this once, from memory. 2. The same question gives a different answer twice LLM inference is not deterministic, and it is not deterministic even at temperature zero. Thinking Machines Lab traced the cause to batch-invariance in inference kernels: the batch your request lands in varies with server load, so the arithmetic varies with it. They fixed it in a research setting and got 1,000 bitwise-identical runs, which tells you how much engi

If you've run more than one AI coding agent on the same project, you already know the failure mode. You point Claude Code at /src/game and Cursor at /src/ui "just to be safe," and twenty minutes later one of them has quietly rewritten a file the other was mid-edit on. No error, no warning — just a diff that makes no sense and an afternoon spent figuring out which agent ate whose work. The agents aren't the problem. The problem is that multiple AI coding agents on the same codebase have no shared notion of "someone else is touching this file right now." Each one acts as if it's alone, and that assumption breaks the moment you run two, three, or four in parallel — exactly when a solo builder or vibe-coder would want to, to ship faster. I built Bothread to fix this. It's free, open-source, and runs entirely on your own machine. Why AI Coding Agents Overwrite Each Other's Files The core issue is coordination, not intelligence. One agent working alone is usually fine. Trouble starts when a second agent, unaware of the first, opens that same file and writes its own version on top. Whoever saves last wins, silently — no lock, no claim, no message saying "I'm in physics.js , give me five minutes." Multiply that by however many agents you're running and you get the pattern anyone doing multi-agent AI coding eventually hits: duplicated work, clobbered edits, and a human reconstructing what happened after the fact instead of watching it happen. Bothread's answer: give the agents a shared room, over MCP (Model Context Protocol) , where "who's working on what" is a fact everyone can see and act on — not something you guess at after a merge conflict. What Bothread Actually Does Bothread is a small local server (no cloud, no accounts) that any MCP-compatible agent can join as a participant in a shared room: Claim files before editing — a claim on a file someone else already holds gets denied and shown, instead of silently overwritten. Talk in a live thread , share a task board and

You know the drill for adding an MCP server to a project: dig the exact command string out of the docs, hand-write a .mcp.json with an absolute path you'll typo once, restart the editor, and discover no tools showed up because the server expected a config file you haven't created yet. Plenty of MCP servers lose their would-be users somewhere inside that loop. Infrawise collapses the whole loop into one command. It's an open-source tool ( npm ) that statically analyzes your codebase, AWS infrastructure, and database schemas, then exposes that context to AI coding assistants over MCP — so Claude Code knows your actual partition keys, GSIs, and indexes instead of guessing from source files. This post is about the part that usually kills tools like this before they deliver any value: setup. Section 1: One command, four steps npm install -g infrawise # or skip install and use npx cd your-project infrawise start --claude start does four things, in order: 1. Probes your environment. If there's no infrawise.yaml in the project, it generates one. It reads AWS_PROFILE if set; otherwise it looks at your configured AWS profiles — one profile means zero questions, several means one prompt asking which to use. That's the entire interview. (If you want the full guided wizard instead, infrawise start --interactive runs it.) 2. Runs the analysis. It scans your AWS services, database schemas, and codebase, builds a graph of services, tables, indexes, and query patterns, and runs rule-based analyzers over it. No LLM is involved in this step — extraction and analysis are deterministic, so the same infrastructure always produces the same graph. 3. Writes .mcp.json to your project root. This is the file you'd otherwise write by hand: { "mcpServers" : { "infrawise" : { "command" : "infrawise" , "args" : [ "serve" , "--stdio" , "--config" , "/absolute/path/to/infrawise.yaml" ] } } } 4. Opens Claude Code. Claude Code reads .mcp.json automatically and starts the session with all 21 infrawise

I spent three days wondering why my MCP server would just... stop. No crash logs. No error messages. Clients connected fine, then after a few hours, every tool call returned silence. Turns out the Model Context Protocol (MCP) spec doesn't force you to handle errors — it assumes you will. But the reference implementations are minimal. Your server starts healthy, then bit by bit, things go wrong. A network blip. A malformed tool argument. An external API timeout. And suddenly your AI agent is staring at a blank response. Here's the pattern I ended up with. It's not clever. It just works. The Fix Start with a wrapper around your tool handlers. Every MCP server framework has some kind of tool registration — this works for the official Python SDK, the TypeScript SDK, and most community frameworks: from mcp.server import Server from mcp.types import ErrorData , INTERNAL_ERROR , INVALID_PARAMS import traceback import json class ResilientMCPServer ( Server ): """ An MCP server that doesn ' t silently die. """ async def call_tool ( self , name : str , arguments : dict ): try : result = await super (). call_tool ( name , arguments ) return result except ( ConnectionError , TimeoutError ) as e : # Network-level issues — reconnect and retry self . _reconnect () return self . _error_response ( f " Connection lost while executing { name } : { e } " ) except ValueError as e : # Bad arguments from the client — tell them clearly return self . _error_response ( f " Invalid arguments for { name } : { e } " , code = INVALID_PARAMS ) except Exception as e : # Everything else — log, don't crash traceback . print_exc () return self . _error_response ( f " Tool { name } failed: { e } " , code = INTERNAL_ERROR ) def _error_response ( self , message : str , code : int = INTERNAL_ERROR ): return { " content " : [{ " type " : " text " , " text " : f " ERROR: { message } " }], " isError " : True } def _reconnect ( self ): """ Reset transport layer without restarting the server. """ # Your recon

📖 TL;DR GPT-5.6 shipped July 9, 2026 in three tiers Sol (flagship), Terra (balanced), and Luna (cheapest) all tuned for agentic tool calling. All three share a 1M-token context window , 128K max output, and native MCP support in the Responses API. Test any MCP server against Sol, Terra, or Luna in MCP Agent Studio — pick the model, connect a server, and watch each tool call live. OpenAI dropped GPT-5.6 on July 9, 2026 - and this one is aimed squarely at agents. Three models landed at once: Sol , Terra , and Luna . Each is built to call tools, not just chat . That makes testing MCP servers with GPT-5.6 a different exercise than testing a plain chat model. Tool selection is the whole game. I have spent this week pointing all three at MCP servers GitHub, Postgres, Playwright, and multi-server setups. This post is what I learned. You will see which tier to run for which workload , how the new tool-calling features change MCP, and how to test each one free in your browser. Skip it and you will overpay for Sol on jobs Luna handles fine. What Is GPT-5.6? Sol, Terra, and Luna Explained GPT-5.6 is a three-tier model family, not a single model. OpenAI split it by cost and horsepower so you match the model to the job. Here is the lineup, straight from OpenAI's pricing page: Model Built for Input / Output (per 1M) GPT-5.6 Sol Flagship — ambitious agentic work $5.00 / $30.00 GPT-5.6 Terra Balanced — efficient, high-volume work $2.50 / $15.00 GPT-5.6 Luna Fast, affordable — everyday work $1.00 / $6.00 The specs are shared across all three. Every tier gets a 1M-token context window, 128K max output, and a February 16, 2026 knowledge cutoff. So the choice is not about context or capability limits. It is about how much reasoning each task actually needs. New to the protocol these models call? Start with what is Model Context Protocol , then come back. Why GPT-5.6 Changes MCP Tool Calling Here is the part that matters for MCP. GPT-5.6 does not just call tools one at a time it can orc