标签：#mcp

While LLMs are great, there are some limitations in using LLMs: LLMs can hallucinate, presenting factually incorrect information when they don't know the answers, and their knowledge gets frozen at the time of training. That's when Retrieval Augmented Generation (RAG) addresses both of these problems. It is the process of optimizing the output of the LLM. This article walks through what RAG is, why it matters, and how to build a working RAG pipeline using two of the most popular tools in the space: LangChain , a framework for building LLM-powered applications, and Pinecone , a managed vector database designed for fast similarity search at scale. A typical RAG pipeline has three core steps: Retrieve : When a query is entered, the system searches an external data source (like a vector database) for the most relevant documents. Augment : The system attaches those relevant retrieved documents to the original user prompt. Generate : The LLM reads the appended context and formulates a highly accurate, grounded answer. RAG is popular because it solves practical problems that pure fine-tuning or prompting can't easily solve: Freshness — You can update the knowledge base without retraining the model. Domain specificity — You can ground responses in your company's internal documents, product manuals, or proprietary data. Traceability — Because answers are based on retrieved documents, you can cite sources and reduce hallucination. Cost — Retrieval is far cheaper than fine-tuning a model every time your data changes. Why LangChain and Pinecone? LangChain drastically speeds up AI development. It is an open-source orchestration framework that provides pre-built components to connect Large Language Models (LLMs) to external data, manage memory, and create multi-step workflows. It abstracts away the complex boilerplate usually required to build production-ready AI applications. Pinecone is a purpose-built vector database. Once your documents are converted into embeddings (numerica

The previous code-graph series was about reshaping a static analysis graph so AI could query it. The same kind of reshaping is needed on the observability side. This post walks through four axes — application / infrastructure / CI / LLM — and the deliberately different shapes each one ends up in. The design judgments worth calling out: computing Gemini cost client-side instead of from billing API, sending Claude Code OTel straight to BigQuery instead of Loki, and shipping CI logs via post-hoc pull instead of webhook push.

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup. By Matt Saunders

これは、Apidog が API テストおよび API ライフサイクル管理のためのコマンドラインツールである Apidog CLI をどのように開発したかを共有する全10回のシリーズです。順番に読むか、必要なテーマから直接参照してください。 今すぐApidogを試す タイトル 焦点 1 当社は126のMCPツールを構築しました。しかし、それはAgentにとって最良の解決策ではありません 問題の発見 2 なぜ当社は全く新しいApidog CLIを開発したのか アーキテクチャ開発 3 黄金律：CLIは事実を生成し、モデルは事実に従って行動する 核となる哲学 4 agentHints : CLIにAgentとの会話を教える 構造化出力 5 SKILL：運用経験をコードとして出荷する 運用経験 6 数字は嘘をつかない：ツール呼び出しは30%減、トークンは25%減 定量的結果 7 PRDからテストループまで：Apidog CLIによる完全なAgentワークフロー 実践的なチュートリアル 8 なぜCI/CD互換性がAgentツールにとって不可欠なのか DevOpsの視点 9 AIブランチ：AI Agentによるより安全なプロジェクト変更 セキュリティレイヤー 10 Spec-Firstは昨日。Skill-Firstへようこそ。 ビジョンと未来 当社は、MCPが最適化しない複雑なワークフロー、つまり検証ゲートと構造化された実行を伴うワークフローを処理するために、CLI + SKILLを構築しました。 MCPはその目的を果たし続けています CLI + SKILLに入る前に、前提を明確にします。 Apidog MCPは現在も利用可能で、メンテナンスされています。 MCPは、プロトコルに従って標準化されたツール接続を提供します。特に以下の用途に適しています。 シンプルで明確に定義された操作 MCPベースのワークフローを好むユーザー MCP準拠クライアントとのエコシステム統合 当社はMCPを置き換えたわけではありません。CLI + SKILLはMCPを補完するために構築されました。 MCPは ツール接続 に優れています。一方で、検証、読み戻し、実行確認を伴う多段階のR&Dワークフローでは、Agentに対して 実行可能なエンジニアリングプロセス を提供するほうが安定します。そこにCLI + SKILLが適合します。 タスクごとに使い分けると、次のようになります。 タスクタイプ 推奨されるアプローチ シンプルなツール呼び出し（例：エンドポイントの取得） MCPまたはCLI。どちらも機能します 多段階ワークフロー（例：テストの作成、検証、実行） CLI + SKILL。より良い体験になります CI/CD統合 CLI。ネイティブに適合します MCPエコシステム統合 MCP。プロトコル標準に適合します 古いCLI：最後にテストを実行する Apidog CLIは長年、APIテストを実行するためのコマンドラインのエントリポイントでした。 apidog run --project <projectId> --test-scenario <scenarioId> --environment <environmentId> この基盤は今も重要です。チームには以下を行うための信頼できる方法が必要です。 ターミナルからAPIテストを実行する CIパイプラインでレポートを生成する 自動化ワークフロー内で品質ゲートを維持する ただし、古いCLIの主な役割は テスト実行 でした。つまり、ワークフローの終盤で使われます。 設計 → ドキュメント化 → モック → デバッグ → テスト → [CLIがテストを実行] CLIは最後のステップでした。他の作業が完了したあとに、既存のテストを実行するためのものだったのです。 新しい要件：Agentにはより多くの操作が必要 API開発は変化しています。 AI Agentは現在、APIライフサイクルの複数段階に参加します。 段階 Agentの活動 API設計 PRDからエンドポイント定義を生成する テスト生成 API仕様からテストケースを作成する デバッグ 障害を分析し、修正案を提示する 移行 プロジェクト間でAPIを移動する メンテナンス API変更時にテストを更新する このようなワークフローでは、CLIは既存テストを最後に実行するだけでは不十分です。 Agentが安定して作業するには、CLI側で次の操作を提供する必要があります。 APIアセット（エンドポイント、スキーマ、環境）を読み取る テストアセット（テストケース、テストシナリオ）を作成または更新する 書き込み前に構造化された変更を検証する 変更をプロジェクトに書き戻す 実行結果を検証

The obvious fix for "my projects all look similar" is a better README — more screenshots, clearer descriptions, maybe a comparison table. I considered that for about five minutes and decided it was still just a nicer list of links. What actually made a portfolio project feel different was making it something you could talk to instead of read. That's what MCP (Model Context Protocol) is built for — it's the standard that lets AI clients like Claude Desktop call external tools directly, not just process text. So I built a server that exposes my 9 projects as queryable tools instead of static entries. What is MCP, and why does it matter here Almost every AI-developer portfolio I've seen is a list of links. Mine now includes something you can actually talk to . Open Claude Desktop, connect my server, and ask "what has Ayush built with FastAPI?" — it doesn't guess from a cached README, it calls a real tool and answers from structured, live data. What I built A Python MCP server ( FastMCP , stdio transport) exposing five tools: list_projects — short summary of all 9 projects get_project_details(project_name) — full stack, GitHub link, demo URL for one project, fuzzy-matched by name search_projects_by_stack(technology) — "show me everything using Groq" or "LangGraph" or "React" get_flagship_project — the single best project to look at first get_resume_summary — background, target role, core stack The data itself lives in plain Python dictionaries right now — no database needed for something this size. Each tool is a thin function around that data, decorated with @mcp.tool() . @mcp.tool () def search_projects_by_stack ( technology : str ) -> list [ dict ]: """ Find all projects that use a given technology or tool. """ query = technology . lower (). strip () matches = [ { " name " : p [ " name " ], " stack " : p [ " stack " ], " github " : p [ " github " ]} for p in PROJECTS if any ( query in tech . lower () for tech in p [ " stack " ]) ] return matches or [{ " message " : f

Most SaaS backends were built around a simple assumption: The user pays a subscription, then uses the product. That assumption breaks down for AI apps. An AI app does not just serve screens. It spends money while it works. A user searches the web. A model summarizes a report. An image model generates a draft. An agent calls an MCP tool. A workflow buys data from an API. A future x402 endpoint charges for a capability call. Every one of those actions can have a marginal cost. That means the backend for an AI app is no longer just a place to store users, projects, and settings. Increasingly, it is a system of record for economic activity. In other words: AI app backends are becoming accounting systems. The old SaaS model was simpler Traditional SaaS could survive with coarse billing. You had: monthly subscriptions seats tiers maybe a usage limit somewhere That worked because the marginal cost of most product actions was close enough to zero. If a user clicked a button, edited a document, opened a dashboard, or created a project, the backend cost was usually small compared with the subscription price. The business could average it out. AI apps are different. The product may call paid APIs on almost every useful action. Search once. Summarize once. Generate once. Transcribe once. Call an agent tool once. The unit economics are inside the interaction loop. If the product cannot see who spent what, when, and why, the business is flying blind. Usage billing is not an add-on For AI apps, usage billing is often treated like a pricing feature. I think that is too narrow. Usage billing is really a cost ledger. It answers: which user triggered the cost? which project or app did it belong to? which capability was called? what did it quote before execution? what did it actually cost? was it retried? was it idempotent? did the end user pay for it? is there a payment or checkout record attached? If you cannot answer those questions, you do not have a reliable production backend for

Introduction Every agent needs tools, and every tool needs a way to reach the model. Building Agentic Workflows in Python built that connection by hand — a hand-written JSON schema, a loop that dispatches on block.name . LLM Frameworks vs. the Raw SDK in Python showed LangChain's @tool turning a plain function into that same schema via bind_tools . Both are still bespoke : the tool lives inside one process, wired to one agent, in one language. The Model Context Protocol (MCP) solves a different problem: it standardizes the wire format between an AI application and a tool server, so the server doesn't have to be rewritten per agent, per framework, or per language. This post covers what that buys you, builds a minimal MCP server and a client that consumes it — both on the official Python SDK — and gives an honest answer to when reaching for a protocol is worth it over a direct tool call. The Problem MCP Solves Without a shared protocol, every pairing of agent framework and tool needs its own glue code: a LangChain @tool wrapper, a hand-rolled schema for the raw SDK, a different wrapper again for whatever framework a teammate picks next — an integration per framework, per tool. That's an M×N problem. MCP flattens it to M+N. A server exposes tools, resources, and prompts once, over a standard JSON-RPC protocol. Any host application — Claude Code, Claude Desktop, VS Code, or your own agent — creates an MCP client that speaks that same protocol, regardless of which framework built the host. Write the server once; every MCP-aware host can use it without new integration code. The protocol itself is intentionally boring: JSON-RPC 2.0 messages for lifecycle negotiation, tool discovery, and tool execution. Discovery ( tools/list ) and execution ( tools/call ) are the two calls that matter for this post: // tools/list response (abbreviated) { "jsonrpc" : "2.0" , "id" : 2 , "result" : { "tools" : [ { "name" : "get_account_balance" , "description" : "Look up the balance for an ac

Introduction Every agent needs tools, and every tool needs a way to reach the model. Building Agentic Workflows in Java built that connection by hand — a hand-written Tool schema, a loop that dispatches on toolUse.name() . LLM Frameworks vs. the Raw SDK in Java showed LangChain4j and Spring AI turning an annotated Java method into that same schema via reflection. Both are still bespoke : the tool lives inside one process, wired to one agent, in one language. The Model Context Protocol (MCP) solves a different problem: it standardizes the wire format between an AI application and a tool server, so the server doesn't have to be rewritten per agent, per framework, or per language. This post covers what that buys you, builds a minimal MCP server and a client that consumes it — both on the official Java SDK — and gives an honest answer to when reaching for a protocol is worth it over a direct tool call. The Problem MCP Solves Without a shared protocol, every pairing of agent framework and tool needs its own glue code: a LangChain4j tool wrapper, a Spring AI @Tool method, a hand-rolled schema for the raw SDK — three integrations for one capability, repeated for every tool and every framework you add. That's an M×N integration problem. MCP flattens it to M+N. A server exposes tools, resources, and prompts once, over a standard JSON-RPC protocol. Any host application — Claude Code, Claude Desktop, VS Code, or your own agent — creates an MCP client that speaks that same protocol, regardless of which framework built the host. Write the server once; every MCP-aware host can use it without new integration code. The protocol itself is intentionally boring: JSON-RPC 2.0 messages for lifecycle negotiation, tool discovery, and tool execution. Discovery ( tools/list ) and execution ( tools/call ) are the two calls that matter for this post: // tools/list response (abbreviated) { "jsonrpc" : "2.0" , "id" : 2 , "result" : { "tools" : [ { "name" : "get_account_balance" , "description"

Back when we introduced MCP support , we ended on a teaser: Phase 3 would tackle Sampling —letting servers request completions from the host instead of only exposing tools and resources to it. NodeLLM 1.17 delivers on that, and pairs it with a second, unrelated but overdue improvement: precise control over how tool calls execute, now available consistently in both core and the ORM persistence layer. 🔄 MCP Sampling: Closing the Loop Sampling inverts the usual MCP direction. Instead of the client asking the server for tools, the server asks the client to run an LLM completion on its behalf. This lets an MCP server offer LLM-powered capabilities—summarization, classification, drafting—without needing its own API key or provider integration. createLLMSamplingHandler answers those requests using a real NodeLLM instance, so a server's tool ends up powered by whatever model you configure client-side: import { createLLM } from " @node-llm/core " ; import { MCP , createLLMSamplingHandler } from " @node-llm/mcp " ; const llm = createLLM ({ provider : " openai " }); const mcp = await MCP . connect ( { command : " node " , args : [ " ./sampling-server.mjs " ] }, { sampling : createLLMSamplingHandler ( llm , " gpt-4o-mini " ) } ); const tools = await mcp . discoverTools (); // The server only advertises sampling-backed tools once it sees // the client declared sampling support during the handshake. If you need full control over how a sampling request is answered—routing by model hint, injecting your own guardrails—pass a plain handler function instead of { llm, model } . It receives the raw sampling/createMessage params and returns a CreateMessageResult , so you decide exactly how (or whether) to answer. ⚡ Concurrent Tool Execution When a model returns several independent tool calls in the same turn, NodeLLM has always executed them one at a time. That's safe by default, but wastes time when the calls don't depend on each other—three weather lookups for three different cities, s

For the past two years, most of us integrated AI into our workflow using a "ping-pong" model: we write a prompt, get some code, copy-paste it, hit a bug, and paste the error back. But in 2026, the tech stack is shifting from simple chat interfaces to Autonomous AI Agents . We aren't just talking about smarter chatbots. We are talking about production-ready systems that can plan, use specialized tools, debug themselves, and interact with our local development environments. The Core Blueprint of an AI Agent Unlike a standard LLM call that finishes after a single response, an AI Agent operates in an Evaluate-Act-Learn loop. To actually build or interact with one, you need to understand its three core pillars: State & Memory: Maintaining context across complex, multi-step tasks (both short-term session state and long-term vector-based memory). Planning & Reflection: The ability to break down a high-level goal (e.g., "Scrape this e-commerce site and update our DB schema" ) into a sequence of executable tasks, and pivot if a step fails. Tools (The Game Changer): Giving the model execution capabilities via APIs, sandboxed code execution environments, and file system access. Enter MCP: The Architecture Connecting It All The biggest catalyst for this shift right now is the adoption of the Model Context Protocol (MCP) . Think of MCP as an open standard that acts like a universal adapter. Instead of writing custom, brittle glue-code for every single tool you want an AI to use, MCP provides a secure, structured way for LLMs to safely read and write to local repositories, query databases, or trigger deployment pipelines. [ AI Agent ] ──( MCP Protocol )──► [ MCP Server ] ──► [ Local Files / DB / API ] When an agent is plugged into your workspace via MCP, it doesn't just guess what your code looks like. It can scan an entire TypeScript repository, map out your Tailwind components, identify type mismatches, and apply a refactor across multiple files simultaneously. From Dev to Arch

CAI.com — a custodial @cai .com email, multi-chain stablecoin wallet, and MCP-installable agent API A custodial email, a stablecoin wallet, a credential vault, and an agent-ready API — all at one @cai.com address. This post walks through what CAI is, what you get when you sign up, and how to wire the agent side into any MCP-compatible host. What you get at cai.com/app A free @cai.com email comes with four product surfaces, all under one account: A real inbox at @cai.com . Send and receive mail like any other address. The signup gives you the address; the dashboard gives you the SMTP/IMAP credentials if you want to use a desktop client. A custodial multi-chain stablecoin wallet. Built in. Six chains. External wallets supported. MoonPay for fiat on-ramp (partial-live, third-party KYC and region limits apply — see cai.com/capabilities.html ). A user vault for site credentials. Store website logins and passwords. The agent you build retrieves them when needed, with your explicit confirmation. The vault is for your site credentials, not the agent's API key. An API key for the agent you build or use. Free tier covers read scopes; pay and full scopes may require verification. The key is in the account dashboard. How the signup works The signup at cai.com/app is four steps. About 2 minutes. Go to cai.com/app . Pick "Apply for @cai.com email." Enter your name. That's the only field on the first screen. CAI emails a 6-digit verification code to the address you provide. The code expires in 15 minutes. The email has a one-time link, not the code — copy the code from the email and paste it into the form. Enter the code, create a password, and you're done. At the end you have: A @cai.com email address. A custodial multi-chain stablecoin wallet. A user vault for site credentials. An API key for the agent you build or use. No card. The email is free. The agent side (for the technical reader) For the technical reader, the agent side is the reason to look at CAI. The install is one c

I open sourced a project I have been building on the side: a Go MCP server that connects Claude Code (or Cursor) directly to a live PostgreSQL database. Repo: github.com/gupta-akshay/postgres-mcp The problem it solves Most "AI plus database" workflows still look like this: copy SQL out of a chat window, paste it into a DB client, run it, copy the output back. It breaks flow, and the assistant never sees your actual schema, so it guesses. MCP fixes the connection problem. This server is what sits on the other end for Postgres. What it does The server exposes nine tools over MCP: Schema introspection - real tables, columns, indexes, constraints execute_sql - run queries directly (read only in restricted mode) explain_query - EXPLAIN ANALYZE, including against a hypothetical index get_top_queries - pull slow queries from pg_stat_statements Index advisors - recommend indexes using a greedy Database Tuning Advisor built on hypopg analyze_db_health - vacuum, XID wraparound, replication lag, invalid indexes, and more, checked in parallel That means you can ask "why is this query slow" and the assistant actually runs the EXPLAIN, checks the stats, and can simulate an index before anyone touches the schema. Why Go The project is inspired by the Python crystaldba/postgres-mcp . I rebuilt it from scratch in Go so it ships as a single ~15 MB static binary. No Python runtime, no dependency chasing. docker build , point Claude Code at it, done. Restricted mode wraps every call in a read only transaction, so write protection comes from Postgres itself, not string matching on the query text. Where to look The repo has the full setup instructions, the Docker config, and the test suite (unit, integration, and end to end against a real Postgres container with pg_stat_statements and hypopg ). CI fails under 95% coverage. If you spend real time in Claude Code or Cursor and also spend real time worrying about Postgres performance, take a look: github.com/gupta-akshay/postgres-mcp I wrote

The original safety gate on the Dolt-over-MCP plugin tried to keep a Claude Code agent harmless by excluding "history-affecting tools" from its MCP grant. It was the wrong granularity, and it did nothing. MCP exposes the entire database through one tool — query / exec — and that tool carries every SQL verb. SELECT rides it. So does CALL DOLT_PUSH , CALL DOLT_RESET('--hard') , DROP DATABASE , and CALL DOLT_BRANCH('-D', 'main') . Excluding "dangerous tools" from the grant accomplishes nothing, because the dangerous verbs live inside the one tool you already granted. The destructive operations were never separate tools to exclude. This is the reframe the whole Phase 0 hardening pass turned on: a tool-name allowlist is meaningless for any tool that carries a sub-language. SQL is a sub-language. So is the shell behind a Bash tool. So is anything behind an eval . If the tool can run arbitrary statements in some grammar, the only boundary that means anything is one that reads the statement. It is the move from tool-name allowlisting to capability-based security: the grant stops being "you may call the query tool" and becomes "you may run these statement classes inside it." Why not just allowlist the safe tools? Because there is exactly one tool, and it is not safe or unsafe — it is whatever statement you hand it. You cannot partition a single door into a safe door and a dangerous door by naming. The same logic kills the next-obvious fix: a denylist of dangerous verbs. Blacklist DOLT_PUSH , DOLT_RESET , DROP ... and miss DOLT_REBASE , or the proc Dolt ships next quarter, or a CALL whose name your regex didn't anticipate. A denylist is only as good as your imagination on the day you wrote it. The fix inverts that. You add safety by enumerating what is safe, not by blacklisting what is dangerous. Anything you cannot positively classify as safe is treated as the most dangerous thing it could be. Default-deny the unknown. It's least privilege applied to a grammar: the agent get

Contorium is a local-first system that introduces persistent project cognition into AI-assisted development workflows. Instead of treating AI as a tool that operates on code, Contorium treats the project itself as a structured, evolving system. ⸻ 🧠 Problem Modern AI coding workflows suffer from a structural limitation: Even with tools like: Cursor Claude Code MCP-based agents IDE copilots context is still: fragmented session-based non-persistent weakly structured This leads to: repeated explanations, lost reasoning, and architectural drift ⸻ 🧩 Solution: Project Cognitive Runtime (PCR) Contorium introduces a runtime model where project understanding is persistent and structured. ⸻ Core Components ⸻ PIK — Project Intent Kernel PIK defines the system-level intent of a project: primary goal constraints non-goals priority weighting It acts as a stable semantic anchor. ⸻ CIL — Cognitive Interaction Layer CIL captures reasoning: why decisions were made what alternatives were considered how context influenced outcomes It makes reasoning persistent instead of ephemeral. ⸻ Timeline Layer All system changes are recorded as events: code changes AI outputs tool interactions architectural decisions This enables replay and evolution tracking. ⸻ Drift Detection Layer A continuous alignment system compares: current behavior vs PIK intent It detects: intent drift structural drift behavioral drift And produces measurable deviation signals. ⸻ 🔁 System Loop Contorium forms a continuous loop: PIK defines intent Execution produces behavior Timeline records evolution Drift system evaluates alignment Suggestions guide correction This creates a self-regulating project system. ⸻ 🧠 Key Insight Contorium is not an AI coding tool. It is a: Project Cognitive Runtime (PCR) A system where software projects maintain structured intelligence over time. ⸻ 🚀 Why it matters The bottleneck in AI development is no longer capability. It is continuity of understanding across: time tools agents sessions Conto

TL;DR codegraph , codebase-memory-mcp , and serena all got there first, handing a coding agent code intelligence over MCP so it stops grepping. On my own open-ended questions the token bill didn't budge: the agent kept sliding back to grep, and no amount of forceful prompting could stop it. So I built @ttsc/graph . It gives the agent an index the TypeScript compiler already resolved, never the source bodies, through a single tool with a forced chain-of-thought. On "how does this work?" questions that works out to roughly 10× fewer tokens, and the answers are no worse. That figure is a median, and a conservative one. Repository: https://github.com/samchon/ttsc Benchmark: https://ttsc.dev/docs/benchmark/graph 1. Preface 1.1. What @ttsc/graph Is On the left, the agent is lost in a maze of files, chasing dashed arrows dozens deep. On the right, it's reading a single compiler-built graph of nodes and edges, with the file:line anchors it can open and check. You're new to a TypeScript repo, so you ask the agent for a tour: what's the main runtime flow, from the public API down to the code that does the work, and what should you read first? You know how it goes. It opens a file, follows an import into another, then another, and a few dozen files later it gives you an answer. @ttsc/graph cuts that crawl short. Over MCP, it hands your agent a graph of your TypeScript codebase that the compiler itself drew: what calls what, what depends on what, and where each piece lives. The agent answers structural questions straight from the graph instead of spelunking through files, and every claim it makes points at an exact file:line the compiler resolved. Nothing invented, just a location you can open and check for yourself. It's the same question and the same agent in every case, and only @ttsc/graph stays flat across the repos no matter how big they get. The other three, codegraph, codebase-memory, and serena, swing all over the place, and a few even spend more than the baseline does

What Claude Sonnet 5 Means for AI Infrastructure in East Africa The release of Claude Sonnet 5 on June 30, 2026 changes something specific about building AI agent infrastructure for regions like East Africa: the model tier that couldn't reliably finish a multi-step workflow now can. This isn't a general AI update note. It's about a concrete technical constraint that just moved. The constraint that moved East Africa's AI infrastructure problem isn't compute or APIs. M-PESA has an API. Africa's Talking has an API. NDMA publishes drought data. KRA has a taxpayer portal. The constraint has been that an AI agent calling several of these in sequence — check drought severity → trigger insurance evaluation → notify county — would stop partway through, lose context, or require manual handholding to continue. Sonnet 4.6, released in February, scored 67.0% on Terminal-Bench. Sonnet 5, released today, scores 80.4%. That 13-point gap isn't abstract. It's the difference between an agent that stalls at step two of a cascade and one that finishes. What this means for the East Africa coordination stack The 31 MCP servers in this portfolio — covering M-PESA, drought data, tax, credit scoring, crop insurance, land records, labor rights, county data, and more — are now meaningfully more useful as a system than they were yesterday. The key change: africa-coord-bus , the coordination event bus that connects these servers, is now the kind of tool Sonnet 5 was designed to orchestrate. A drought alert from wapimaji-mcp , cascading through bima-mcp for insurance evaluation and county-mcp for notification, is exactly the multi-hop tool chain where the 13-point Terminal-Bench improvement shows up in practice. The model to use # Claude API client = anthropic . Anthropic () response = client . messages . create ( model = " claude-sonnet-5 " , max_tokens = 1024 , tools = [...], # your MCP tools messages = [{ " role " : " user " , " content " : " ... " }] ) For compliance and vulnerability analysi

Most "agent memory" and "agent context" tools today require sending your data to someone else's cloud. If you operate in a regulated, air-gapped, or simply privacy-conscious environment, that rules them out before you've even tried them. I build the opposite: two MIT-licensed, local-first MCP servers that do this work entirely on your own hardware. The problem Agent memory and context assembly are converging on a cloud-only default. That's a non-starter for defense, healthcare, finance, legal, and any team that can't or won't let agent context leave their VPC. It's also just slower and less deterministic than it needs to be: agents re-discover the same facts about your repo and services every session, burning tokens and turns before doing any real work. Mimir: persistent memory, fully offline Mimir is a single ~8MB Rust binary. It encrypts everything at rest with AES-256-GCM, and it works with no API key, no model download, and no network access at all, because the embeddings used for dense search are bundled directly into the binary. It's bi-temporal: every fact carries a validity window, so you can query memory "as of" any past point and supersede facts without deleting history. 43 MCP tools, SQLite + FTS5 hybrid search under the hood. One honest tradeoff worth naming: the FTS5 index needed for fast keyword search currently sits over plaintext, even though the underlying record is encrypted at rest. We're upfront about this in the docs rather than overstating the encryption story. Perseus: compile-before-context Perseus takes a different approach to context than runtime tool-call discovery. Instead of letting an agent rediscover your git state, running services, and test status through a chain of tool calls every session, it compiles all of that into a ready briefing the moment a session starts. The result is deterministic and byte-stable: the same repo state always produces the same compiled context. Honest, reproducible benchmarks On paraphrased queries, Mimir's

I got tired of manually writing MCP tools for every REST endpoint I wanted to expose to an LLM. So I automated it. mcpgen reads an OpenAPI JSON or YAML file and generates a complete, ready‑to‑run MCP server in Python. 🔧 What it does Parses OpenAPI 3.0 / 3.1 specs Creates one MCP tool per endpoint (with snake_case names) Handles auth automatically (API key, Bearer, etc.) Outputs a clean, human‑readable Python script Zero runtime surprises – just mcp and httpx 🚀 Quick start bash pip install mcpgen mcpgen my-api.json -o my-mcp-server python my-mcp-server/server.py The generated server runs over stdio – ready to plug into Claude Desktop or any MCP client. 🧪 Real‑world test Recently a contributor added an OpenAPI 3.1 fixture (Xquik API) with lookupTweet and getUser endpoints. The tool generated the correct tools, including path parameters and x-api-key auth, on the first try. All 18 tests pass. It works. 🤔 Why you might want it If you’re building LLM agents that need to interact with APIs, mcpgen eliminates the boilerplate. You don’t have to write a single @app.tool() decorator by hand. It also makes it dead simple to experiment – change your API spec, regenerate the server, and you’re done. 📦 Links GitHub: JnanaSrota/mcpgen PyPI: pip install mcpgen MIT licensed, open to contributions 🙏 Feedback If you try it with your own API spec and something breaks (or works beautifully), I’d love to hear about it. Drop a comment or open an issue. Thanks for reading!

Artificial Intelligence is rapidly evolving from chatbots to autonomous agents capable of...

Elastic open-sourced Atlas, a system built on Elasticsearch that maintains three categories of memory for agents. Atlas integrates with agents via MCP and maintains per-user isolation of memories. When evaluated on question-answering capability, it scored 0.89 Recall@10. By Anthony Alford