标签：#mcp

Grafana Labs has announced general availability for two tools that let AI coding agents query live observability data during development: the gcx CLI and the Grafana MCP server. Both allow agents to pull metrics, logs, traces, SLOs, and Synthetic Monitoring results from Grafana Cloud or a self-hosted stack By Claudio Masolo

The Model Context Protocol (MCP) has been evolving quickly. One of the most interesting changes in the latest MCP specification is the move toward a stateless protocol model . I recently updated my MCP currency converter server to work with the newer stateless behavior and the new split TypeScript SDK packages, particularly @modelcontextprotocol/server . In this article, I'll explain: What MCP sessions were doing What "stateless MCP" actually means Why the change matters for production systems How Streamable HTTP changes with the new specification How I migrated my currency converter MCP server What this means for scaling MCP servers What Is MCP? If you're new to MCP, the Model Context Protocol is a standard for connecting AI applications to external tools, resources, and data. Instead of building custom integrations between every AI application and every external service, MCP provides a common protocol. For example, an AI assistant can use an MCP server exposing a tool like: convert_currency The model can then request: Convert 100 USD to EUR. The MCP client communicates with the MCP server, which performs the actual operation and returns the result. MCP servers can expose several primitives, including tools, resources, and prompts. For my example, the server is intentionally simple: it exposes currency-conversion functionality. The Old Mental Model: MCP Sessions Before the stateless changes, Streamable HTTP could maintain a protocol-level session. Conceptually, the flow looked something like this: Client | | POST /mcp | initialize v MCP Server | | Mcp-Session-Id v Client | | POST /mcp | Mcp-Session-Id: abc123 v MCP Server The server creates a session during initialization. Subsequent requests contain the session identifier. That means the server can associate requests with the session that was established earlier. This isn't necessarily bad. Session state can be useful when an application genuinely needs conversational or connection-level state. But it creates an a

This tutorial walks through building an MCP server in Rust with rmcp , the official Model Context Protocol Rust SDK. The example is a real one: a devops agent that manages AWS EC2 G5g instances — Graviton2 boxes with NVIDIA T4G GPUs — serving Gemma 4 under vLLM. It launches instances, drives them over SSM, and health-checks the model. There's an existing Python version, so at the end we can put the two side by side. Follow along and you'll have a working, registerable MCP server. 🦀 Why Rust for this? Worth answering properly, because the weak version of the argument is easy to make and easy to demolish — and the real one is better anyway. Start with what it isn't: these tools are I/O bound. Every one is an AWS API call — describe_instances , send_command , polling SSM — so 100–500 ms of network per call. The caller's language contributes nothing measurable there. Anyone selling you a Rust rewrite on raw speed for this workload is selling something. Three claims that don't hold, so nobody has to make them in the comments: Claim Why it fails "462 ms startup is slow" stdio servers spawn once per session , not per call "Rust is faster" the work is network round-trips to AWS "smaller supply chain" 241 crates vs 34 Python packages — it's worse What actually justifies it, for this codebase: 1. It's a fleet, not a server. This monorepo has 16 rigs , each with its own MCP server. That changes the units: All loaded together 🐍 Python 🦀 Rust Resident memory 16 × 83 MB ≈ 1.33 GB 16 × 12 MB ≈ 192 MB Session startup 16 × 462 ms ≈ 7.4 s 16 × 2.5 ms ≈ 40 ms A gigabyte of resident Python to expose sixteen tool lists is a real cost. 2. No shared interpreter. These rigs install system-wide — no virtualenvs, by policy — so all sixteen share one Python. Sixteen servers with independently drifting boto3 and mcp pins in one interpreter is a standing conflict risk. A static binary has no such coupling; each rig pins whatever it likes in its own Cargo.lock . 3. The schema can't drift from th

This tutorial walks through building an MCP server in Rust with rmcp , the official Model Context Protocol Rust SDK. The example is a real one: a devops agent that manages AWS EC2 G5g instances — Graviton2 boxes with NVIDIA T4G GPUs — serving Gemma 4 under vLLM. It launches instances, drives them over SSM, and health-checks the model. There's an existing Python version, so at the end we can put the two side by side. Follow along and you'll have a working, registerable MCP server. 🦀 Why Rust for this? Worth answering properly, because the weak version of the argument is easy to make and easy to demolish — and the real one is better anyway. Start with what it isn't: these tools are I/O bound. Every one is an AWS API call — describe_instances , send_command , polling SSM — so 100–500 ms of network per call. The caller's language contributes nothing measurable there. Anyone selling you a Rust rewrite on raw speed for this workload is selling something. Three claims that don't hold, so nobody has to make them in the comments: Claim Why it fails "462 ms startup is slow" stdio servers spawn once per session , not per call "Rust is faster" the work is network round-trips to AWS "smaller supply chain" 241 crates vs 34 Python packages — it's worse What actually justifies it, for this codebase: 1. It's a fleet, not a server. This monorepo has 16 rigs , each with its own MCP server. That changes the units: All loaded together 🐍 Python 🦀 Rust Resident memory 16 × 83 MB ≈ 1.33 GB 16 × 12 MB ≈ 192 MB Session startup 16 × 462 ms ≈ 7.4 s 16 × 2.5 ms ≈ 40 ms A gigabyte of resident Python to expose sixteen tool lists is a real cost. 2. No shared interpreter. These rigs install system-wide — no virtualenvs, by policy — so all sixteen share one Python. Sixteen servers with independently drifting boto3 and mcp pins in one interpreter is a standing conflict risk. A static binary has no such coupling; each rig pins whatever it likes in its own Cargo.lock . 3. The schema can't drift from th

A month ago I shipped aicraft-code-review , an MCP server that reviews code locally. This week I added a CLI mode — because not everyone wants to wire up an MCP client just to check a diff. Now the same reviewer runs three ways: MCP tools — review_code / review_diff / review_file inside Claude Code, Cursor, Cline CLI — mcp-code-review review-file path/to/file.py CI — pipe git diff into it and branch on the exit code The CLI pip install aicraft-code-review # a single file (config auto-discovered from the file's directory upward) mcp-code-review review-file src/api.py # the current diff git diff | mcp-code-review review-diff # a snippet mcp-code-review review-code "import os; os.system('ls')" Exit codes are CI-friendly: Code Meaning 0 clean, or only info-level findings 1 high / medium issues found 2 critical issues found What it catches out of the box Security (OWASP patterns), performance (N+1, unbounded growth), quality (bare excepts, TODOs, missing type hints), style (naming, line length). Real output: ### 🟠 High (2) | Line | Issue | Category | Fix | | 4 | Command injection risk | security | subprocess.run with args list | | 9 | N+1 query in loop | performance | batch query / eager loading | ### 🟢 Info (2) — missing return type annotations Verdict: Conditional Pass — address high/medium issues Making it match YOUR rules The config file is the part I'd actually show a teammate: custom_rules : - name : no-console-log pattern : ' console\.log\(' severity : high category : quality issue : Console logging left in production code fix : Use a structured logger instead disabled_checks : - todo_comment severity_overrides : hardcoded_secret : critical .mcp-code-review.yaml is auto-discovered from the reviewed file's directory upward MCP_CODE_REVIEW_CONFIG points a whole team at one shared profile valid severities: critical / high / medium / info regex patterns work best in single quotes (double quotes will error on escapes like \. ) One caveat if you're also shipping Python

La mayoría de los "agentes con memoria" recuerdan datos : un string, un hecho, una preferencia. Pero cuando hablas semanas con un agente, lo que quieres no es una base de datos con tus notas. Quieres que recuerde vuestra historia : el día que conociste a su perro, la vez que os reísteis de una idea absurda, lo que prometisteis hacer juntos. Y, sobre todo, quieres que no confunda lo real con lo soñado . Por eso construí OurBook : un servidor MCP de memoria narrativa . El agente no guarda tus datos: guarda vuestra vida en común, con emoción, con un diario que se escribe cada noche y con sueños que consolidan los recuerdos — sin contaminarlos jamás. El problema Los MCP de memoria actuales son utilitarios: almacenan y buscan hechos. Eso genera tres fallos conocidos: Confabulación — el agente inventa y lo presenta como recuerdo real. Contexto que no escala — inyectar todo en cada prompt es caro y se desborda. Sin identidad — cambias de modelo o de máquina y el "personaje" desaparece. OurBook cambia el marco: la memoria como identidad narrativa . Lo que lo hace diferente 1. Taxonomía de veracidad (la capa de honestidad) Cada recuerdo tiene un campo veracity : real , observed , imagined (sueño/ficción) o hypothetical . El recall factual excluye por defecto los sueños: un sueño nunca se presenta como hecho. Esto ataca de raíz la confabulación. 2. Soñar = consolidar (neurociencia aplicada) El motor Mnemosyne muestrea fragmentos por saliencia emocional (importancia × valencia) y los recombina en un sueño — como el replay hipocampal durante el sueño. Cada sueño guarda sus fuentes , para que sea ficción honesta y trazable. 3. Doble cerebro: 0 tokens de tu API principal El modelo principal solo pone la voz. Soñar, consolidar y etiquetar corre en Mnemosyne con cadena de fallback: qwen-reverse → local (Ollama/LM Studio) → offline determinista (nunca falla) . Cada llamada queda auditada en engine_log . 4. El libro y la semilla de identidad Todo se exporta a OurBook.md / .html (crón

For years, the CMS ecosystem has largely followed the same formula. Install a CMS. Choose a theme. Install plugins. Customize some templates. Add an API when you need one. Then, eventually, try to connect everything to AI. But the way we build software has changed. Developers increasingly work alongside AI coding assistants. People are building websites by describing what they want instead of manually implementing every component. AI agents can now interact with external tools and services. APIs are becoming the foundation rather than an optional feature. Yet many traditional CMS architectures were designed for a world where a human administrator was the primary interface. That is the problem Basehim is trying to solve. Basehim is an open-source, modular, API-first PHP CMS built for developers, AI-assisted development, and the emerging world of AI agents. The goal isn't to replace every CMS. The goal is to provide a simpler foundation for people who want to build, customize, automate, and extend websites without being forced into a complicated infrastructure stack. The idea behind Basehim Basehim started with a fairly simple observation: The web is still full of ordinary PHP hosting. Millions of websites run on environments such as cPanel, Plesk, Apache, MySQL, and shared hosting. Yet many modern development tools increasingly assume that you have SSH access, Composer, Node.js, a build pipeline, background workers, containers, or a cloud deployment environment. Those tools are excellent when you need them. But they aren't always necessary for a CMS. Basehim takes a different approach. If your server can run modern PHP and MySQL or MariaDB, Basehim is designed to run there. You can upload the files, open the installer, configure the database, create the administrator account, and start building. There is no required Composer installation. There is no frontend build process. There is no daemon that has to remain running. There is no requirement for a public/ directory

I built and open-sourced PacketVoyage —an Agent Skill & MCP server that turns boring traceroute outputs into fascinating stories about physics, geography, and undersea cables. europeanplaice / packetvoyage MCP server & Agent Skill for educational network traceroute analysis, fiber-optic physics verification, and packet voyage storytelling 🚢 PacketVoyage Model Context Protocol (MCP) Server & Agent Skill for educational network traceroute analysis, fiber-optic physics verification, and packet voyage storytelling. Zero external commercial APIs, zero bundled copyright data — pure physical laws and detective insight. 🏛️ Architecture: The Two Pillars PacketVoyage is built around two complementary layers designed specifically for AI-native workflows: ┌────────────────────────────────────────────────────────┐ │ AI Agent (LLM) │ └──────────────┬──────────────────────────┬──────────────┘ │ │ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │ 🧠 Agent Skill │ │ 🛠️ MCP Server │ │ (Knowledge / Playbook) │ │ (Capabilities / Execution)│ ├──────────────────────────────┤ ├──────────────────────────────┤ │ • Speed of Light in Fiber │ │ • analyze_voyage_text │ │ (~0.67c, ~10ms / 1,000km) │ │ • voyage_investigate │ │ • Control vs Data Plane math │ │ • run_protocol_experiment │ │ • Disproving GeoIP illusions │ │ • research_host │ │ • Decision Flow & Heuristics │ │ • list_known_iata_airports │ └──────────────────────────────┘ └──────────────────────────────┘ 🛠️ MCP Server (Capabilities & … View on GitHub Ever wondered what’s actually happening behind a trace like this? 1 gateway (192.168.1.1) 0.8 ms 2 * * * 3 ae-1.tokyo-hnd.bb.net (203.0.113.1) 2.1 ms 4 xe-0-0.sjc-core.bb.net (198.51.100.25) 88.5 ms 5 one.one.one.one (1.1.1.1) 88.7 ms Behind these lines lies real-world physics: • The * * * at Hop 2 isn't packet loss: Normal traffic runs at line rate in hardware ASICs (Data Plane), while diagnostic ICMP responses are rate limited by router CPUs (Control Plane). • The +

You added an MCP server to your AI assistant. Did you check what it can touch? MCP servers give your AI assistant new abilities: read your filesystem, query your database, call an API, run a shell command. That is the whole point of them. It is also the whole point of the risk. The permission question nobody asks When you install a normal browser extension, you at least see a permission prompt. When you add an MCP server to your AI coding assistant, you usually do not. You add a config entry, restart, and the assistant now has whatever access that server exposes. Most people never read the server's source to see what that actually is. This matters more with AI-built or AI-suggested MCP servers specifically. If the assistant wrote the server for you, or you copied one from a repo you have not read closely, you have no independent confirmation of what it does versus what its description says it does. What tends to go wrong Three patterns show up repeatedly: A server meant to read files ends up with write access too, because the broader permission was easier to implement and nobody scoped it down. A server that talks to an external API embeds a credential directly in its config or source, so anyone who can read the server's files can read the key. A server built for local development gets pointed at a production database or production credentials once it "works," without a second look at what commands it now accepts. None of this requires anyone to be careless in an obvious way. It is the same gap as any fast-shipped code: the server works, so it ships, and the access-scoping step that would normally happen in review gets skipped because there was no review. A practical check before you trust an MCP server Before you add an MCP server to a live setup, or before you point an existing one at anything real: Read what the server can actually do, not just its stated purpose. Check the tool definitions it exposes, not the README. Check where its credentials live. A server th

Acceptance gaps Your monitoring tool has 33 tests. Every one of them passes. It has also never executed, not once, and nothing in your project will ever tell you. Correct, complete, and never started We built a tool that scans four public sources for conversations where our product belongs. It reads only. It never posts. The acceptance was thorough. 33 checks in total. No write access, no credentials, results filtered for relevance, duplicates removed. A hard cap on output, back off on HTTP 429, and a dead source must not swallow the other three. All 33 passed. The tool shipped. The task promised a list of conversations every morning. There was no schedule. So there was never a list. And a tool that does nothing also reports nothing, so nobody noticed. Why your test suite cannot see this Tests answer questions about behaviour. Given this input, does the code do the right thing? Whether anything ever supplies that input is a different kind of question. It lives in a scheduler, a workflow file, a systemd timer, a queue consumer. Your test suite has no opinion about it. This is why the gap survives review. Reviewers read the diff, and the diff is correct. The missing part is not in the diff at all. Note how ordinary the failure is. Nobody was careless. The work was good. It just was not connected to anything. The question to add to every acceptance What starts this, and how would I know if it stopped? Ask it about every tool you ship that is meant to run on its own. A report, a backup, a sync, a scanner, a cleanup job. It has two halves and both matter. Something must start it. And when it stops starting, that must be visible without anyone going to look. Make it answerable by a machine A question you have to remember to ask gets forgotten. So we wrote a guard that asks it for every tool at once. The rule: any script whose own header says it runs daily must appear in a workflow file that has a schedule. Twelve lines of code, and it covers every tool we will ever add. T

Cross-posting a technical tutorial is easy to start and surprisingly easy to get wrong. A URL import can leave code blocks split, headings as plain text, or metadata incomplete. The result may look acceptable at a glance while damaging the parts readers need most. This tutorial shows a reviewable DEV.to to Medium workflow using publish-agents , an open-source TypeScript project by Fernando Paladini. Its medium-publisher package imports a public article through Medium's import flow, checks the editor against the source Markdown, and can repair a small set of common formatting problems. TL;DR Checkout the stable v0.2.3 release, build the @paladini/medium-publisher-mcp package, log in once, and create a Medium draft with publish-devto . Keep the default draft behavior while you inspect the title, code blocks, headings, lists, and metadata. Prerequisites You need: Node.js 20 or newer. A published DEV.to article with a public URL. A Medium account that can create stories. A terminal that can run npm and the browser installation step. The package uses Patchright browser automation and a saved browser session. It does not use a Medium write API key. The project documents Medium UI changes as a compatibility risk, so treat the browser session and the resulting draft as reviewable state rather than an unattended guarantee. Install the released source The repository's v0.2.3 release is the stable reference for this walkthrough. Installing from that tag keeps the commands separate from later changes on the default branch. git clone https://github.com/paladini/publish-agents.git cd publish-agents git checkout v0.2.3 npm install npm run build -w @ paladini/medium-publisher-mcp npm link -w @ paladini/medium-publisher-mcp The build produces the CLI and MCP server from the package source. The package declares Node.js 20 or newer and uses patchright as its browser automation dependency. Its post-install step may install the bundled Chromium browser. If that step was skipped in your

On July 28, the Model Context Protocol project shipped a new spec revision, 2026-07-28 . I run backend engineering at GoodBarber, and our public MCP server is a live production surface: real apps, real content, real push notifications. So for us a new revision is not a changelog to skim on a Friday. It is a migration with our name on it. We have just brought the server up to the new revision. This post is three things: the operator's cut of what changed, what upgrading a public server actually involves, and the thing we found in our logs while checking the work. The last one is the reason I'm writing. The operator's cut of 2026-07-28 The headline is the stateless core. MCP grew up as a stateful, bidirectional protocol: an initialize handshake, a negotiated session, an Mcp-Session-Id header to carry it all. The new revision retires that entirely. Every request now self-describes in _meta : protocol version, client identity, capabilities. The practical consequence is the one server operators have wanted since day one: you can put an MCP server behind a plain round-robin load balancer with no shared session storage. If you have ever kept session affinity alive with duct tape, you know exactly which muscle just relaxed. The rest, fast: Method and tool names now also travel in Mcp-Method and Mcp-Name HTTP headers, so gateways can route and meter without parsing JSON bodies. Multi Round-Trip Requests: a call can come back with resultType: "input_required" and continue over stateless connections. Mid-call questions no longer need a held-open stream. List results (tools, prompts, resources) carry ttlMs and cacheScope , so clients can finally cache your inventory honestly instead of guessing. Authorization hardening: RFC 9207 issuer validation, and Client ID Metadata Documents replacing Dynamic Client Registration. Tasks, MCP Apps, and Enterprise Managed Authorization become formal extensions instead of core features. Roots, Sampling, and Logging are deprecated, with a minim

Comfy MCP is Comfy's first-party local Model Context Protocol server. It lets an MCP-capable coding agent inspect the models and nodes in your ComfyUI installation, validate workflows, run them, and retrieve the outputs. The detail that prevents the most confusion is that two processes are involved : comfy launch starts ComfyUI. Your AI client starts comfy-mcp as a local stdio server. If you run comfy-mcp directly and it appears to do nothing, it is probably waiting for an MCP client. That is normal for a stdio server. Disclosure and verification scope: AI tools assisted with drafting and editing this adaptation. I reviewed the finished article and checked the commands and material claims against Comfy's official documentation, repository, and PyPI pages on 13 August 2026. I have not run a generation on my own hardware for this article, so this is a documentation-verified setup guide, not a hands-on performance test. Comfy's documentation currently labels the MCP offering a public beta, so tools and behaviour may change. What you need Before starting, have: Python 3.10 or newer. The examples below use Python 3.11. comfy-cli 1.14.0 or newer. A ComfyUI workspace, either created with comfy install or selected with comfy set-default . An MCP client that can start a local stdio server, such as Claude Code, Cursor, or Claude Desktop. The models and custom nodes required by the workflow you want to run. The MCP bridge is not what determines the hardware requirement; the selected ComfyUI workflow does. A small image workflow and a large video workflow can have very different memory needs. 1. Install comfy-cli and comfy-mcp I prefer a dedicated virtual environment. It keeps the executables in a predictable place and avoids mixing these packages with unrelated Python projects. Windows PowerShell mkdir comfy-mcp-guide cd comfy-mcp-guide py -3 . 11 -m venv . venv . \.venv\Scripts\Activate.ps1 python -m pip install --upgrade pip python -m pip install "comfy-cli>=1.14.0" comfy-mc

MCP 2026-07-28 dropped sessions. The initialize handshake is gone. The Mcp-Session-Id header is gone from Streamable HTTP. Protocol version, client info, and capabilities now travel in a _meta field on every request, so any instance can serve any call. The protocol is cleaner for it. This is the largest revision since launch, and it leaves both of the questions that block enterprise agent deployments exactly where they were. MCP standardizes how a model reaches a tool. Neither question lives inside that scope, and no future revision is likely to put them there: Who is the agent acting as, and what is it allowed to do? What happens when a process takes three days and the model context is gone? The spoiler: on AWS the parts already exist. Policy in AgentCore evaluates every Gateway call in Cedar against a principal, an action, and a resource, and writes the allow or deny to an audit log. Temporal policies, added in August 2026, extend that across an agent's trajectory, including human approval ahead of a privileged action. AgentCore Identity distributes the credentials. Step Functions holds anything measured in days. The remaining work is composition: deciding which principal each agent acts as, and what it may commit to. No service ships that decision. What the stateless redesign actually solved The stateless redesign removes real pain. Long-held SSE connections forced sticky routing, which pushed teams into shared session stores and gateway packet inspection just to scale horizontally. The new model provisions for request rate instead of concurrent users. A round-robin load balancer is now enough. Lambda, Cloud Run, and Workers become viable backends. Multi Round-Trip Requests (SEP-2322) handle elicitation without a held connection. The server returns an InputRequiredResult carrying what it still needs plus an opaque requestState blob. The client collects the answers and re-issues the same call with inputResponses and the echoed state. Any instance picks up the retr

Back in early August I fixed a bug in update_article , one of the tools in this repo's DEV.to MCP server. The bug was straightforward: the tool built its PUT payload from three optional parameters, and if a caller passed none of them, it still fired a GET and a PUT with an empty {"article": {}} body against a live published post, then logged a no-op entry to the audit trail as if something had happened. The fix was a guard: raise before either network call if the built payload dict ends up empty. article = {} if title is not None : article [ " title " ] = title if body_markdown is not None : article [ " body_markdown " ] = body_markdown if published is not None : article [ " published " ] = published if not article : raise ValueError ( " update_article called with no fields to update " " (title/body_markdown/published all None) " ) before = _dev ( f " /articles/ { article_id } " ) result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " : article }) _log_article_update ( article_id , before , article . keys (), result ) I closed the ticket, ran a stubbed selftest, moved on. Going back into this function for something unrelated, I noticed the guard only ever asks one question: did the caller pass a field? It never asks the question that actually matters for a tool whose whole job is writing to a live post: would this field's value be different from what's already there? Walk through what happens if a caller — an agent that re-reads an article's current title before deciding whether to touch it, gets it slightly wrong, or just calls the tool defensively with the value it already has — passes title="Same Title It Already Has" , and that string is in fact identical to the article's current title. article isn't empty. It has one key. The guard passes clean. Both network calls fire: before = _dev ( f " /articles/ { article_id } " ) # GET, real call result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " :

El Problema Quería hacer preguntas sobre mi propia documentación y fotos sin enviarlas a un servicio de IA en la nube. Cosas simples como: "¿Cuánto gasté en electricidad el año pasado?" "¿Qué documentos tengo sobre el seguro del coche?" "¿Cuántas fotos hice en España en 2023?" Pero no quería que mis facturas, contratos y fotos familiares acabaran en los datos de entrenamiento de otra persona. El Stack Componente Propósito Paperless-ngx Archivo de documentos, OCR, metadatos estructurados Immich Copia de seguridad de fotos y vídeo ChromaDB Índice de búsqueda semántica Ollama Inferencia local de LLM Open WebUI Interfaz de chat unificada MCP Herramientas deterministas para datos estructurados LiteLLM Enrutamiento de modelos Todo se ejecuta en una sola máquina Windows 11 con una RTX 5080 16GB. Una Orange Pi 5 Plus se encarga de los backups. Dos Lecciones Difíciles 1. Las herramientas deterministas ganan al razonamiento de LLM para cualquier cosa contable Empecé pidiéndole al modelo que sumara mis facturas. Daba respuestas erróneas. Cada vez. La solución fue una herramienta MCP de 20 líneas que consulta la API de Paperless y devuelve un número. Sin razonamiento, sin alucinación — solo el conteo correcto. 2. La disciplina de routing importa Para campos estructurados de facturas (proveedor, total, IVA, número de factura), añadí una regla estricta al prompt del sistema: > "Consulta siempre a Paperless para estos campos. Nunca uses el índice semántico." Esto eliminó la mayoría de respuestas erróneas que estaba obteniendo. El índice semántico es genial para "encuéntrame algo sobre el seguro del coche." Es terrible para "¿cuál es el total exacto de la factura #1234?" ¿Por Qué No Usar Directamente la IA Nativa de Paperless 3.0? Estoy en Paperless 3.0.3, así que tengo las funciones nativas de IA incluyendo chat con documentos. Esta configuración no las reemplaza — las complementa: Alcance más amplio: La misma interfaz cubre documentos, fotos y vídeo Operaciones deterministas: Las

Silent failure For three weeks nobody could install your plugin. The publish job was green every single day. You find out when a user asks why the version is so old. Three weeks green, zero installs This happened to us. The publish job for our JetBrains plugin reported success on every run since the middle of July. The plugin was not in the marketplace at all. The registry API answered with a 404. A search for the product name returned nothing. Meanwhile the build was green, the release notes were written, and the changelog was up to date. Nobody noticed. Not the pipeline, not the dashboard, not us. The gap between the last good release and the discovery was three weeks. Your pipeline is not lying to you This is the part worth understanding, because it is why the same thing is probably waiting in your repository too. A release pipeline has one job: get the artifact somewhere a stranger can install it. Almost every pipeline checks something else. It checks that the upload command exited zero. Those two questions agree nearly always. Our publish step went further and did the sensible thing. It caught the failure, compared the error text against a list of known-harmless cases, and exited zero for those. One of those cases was pending moderation. A new version sits in review before it becomes visible. Failing the build for that would be noise, so it was allowed through. Here is the trap. A harmless transient state and a permanent block produce the same message. Once the plugin was stuck, every later run matched the same friendly pattern and reported success. The pipeline answered its question correctly. It was the wrong question. The check that catches it, in about two minutes Ask the store, not the pipeline. That is the whole idea, and you can add it today without changing anything else. One: after publishing, fetch the public listing the way a stranger would. No credentials, no internal API, no authenticated client. Seeing what an outsider sees is the entire point. Tw

The MCP 2026-07-28 specification removes the initialize handshake and session header, and adds required method and tool-name headers so gateways can route agent traffic without parsing JSON. Reaction split between developers calling it a rediscovery of REST and those arguing the standard itself was always the point. By Steef-Jan Wiggers

We shipped an MCP server for WhatsApp link generation — no API key required If you've ever needed an AI agent to validate a WhatsApp number, build a wa.me link, or generate a QR code on the fly, you've probably hand-rolled it: scrape a regex off Stack Overflow, write your own phone-format validator, maybe hit some undocumented endpoint. We got tired of watching that happen and shipped a small, open MCP server that does it directly. What it is WhatsUsernames.link already runs a free public REST API for validating WhatsApp usernames/phone numbers and generating wa.me links + QR codes. We just exposed the same logic over the Model Context Protocol , so Claude, and any other MCP client, can call it as native tools instead of you writing a fetch wrapper. Endpoint: https://whatsusernames.link/api/mcp No API key. No account. No signup form. Same open, IP-rate-limited model as the REST API (60 req/min for JSON tools, 20 req/min for QR generation, sliding window via Upstash Redis). The five tools Tool What it does validate_username Checks WhatsApp username ( @username ) format validate_phone Checks phone number format (8–15 digits, international) username_link Builds a wa.me link (+ short link) from a username, optional prefilled text phone_link Builds a wa.me link from a phone number, optional prefilled text qr_code Renders a QR code (PNG or SVG) for a wa.me link, custom size/colors Every tool wraps the exact same services/ and validate-* functions the REST API uses — there's no separate business logic to drift out of sync. If the REST endpoint says a number is valid, the MCP tool agrees, because it's the same code path. Connect it Drop this into your MCP client config: { "mcpServers" : { "whatsusernames" : { "url" : "https://whatsusernames.link/api/mcp" } } } That's it. No stdio process to spawn, no local install — it's a stateless Streamable HTTP transport running on Vercel, same domain as the site. Why build this Two reasons. Practical: every agent that needs to hand a u

The fourth in a suite of deterministic MCP servers for AI agents — and the one that ties the first three together. Over the last stretch I shipped three focused, deterministic MCP servers: ScenarioSim — what-if / scenario simulation DecisionMatrix — multi-criteria decision analysis PrecisionCalc — exact finance / business math They're great on their own, but agents kept needing all three in the same task — and installing three servers, juggling three keys, and hand-gluing their outputs is friction. So here's AgentStack MCP : one endpoint, one key, all three — plus composite tools that chain them. simulate → decide → compute { "mcpServers" : { "agentstack" : { "type" : "http" , "url" : "https://agentstack-mcp.pages.dev/mcp" } } } Free tier: no key, 20 calls/day. The tools are namespaced so an agent always knows which engine it's calling: sim_* — ScenarioSim (run, sensitivity, break-even, compare, templates) decide_* — DecisionMatrix (decide, score, sensitivity, compare_two, methods) calc_* — PrecisionCalc (metrics, currency, NPV, IRR, loan, depreciation, …) The part that's actually new: composite tools These chain the engines to do reasoning no single server can , deterministically end-to-end: evaluate_options_with_scenarios (simulate → decide) — project each option as its own scenario, then rank the outcomes against weighted criteria: { "name" : "evaluate_options_with_scenarios" , "arguments" : { "template" : "saas_growth" , "horizon" : 12 , "options" : [ { "name" : "Aggressive" , "inputs" : { "new_customers_per_period" : 60 , "churn_rate" : 0.05 } }, { "name" : "Lean" , "inputs" : { "new_customers_per_period" : 20 , "churn_rate" : 0.02 } } ], "criteria" : [ { "metric" : "ending_mrr" , "weight" : 3 , "direction" : "benefit" }, { "metric" : "total_churned_customers" , "weight" : 1 , "direction" : "cost" } ] } } plan_to_valuation (simulate → compute) — project a plan, then value its cash-flow line: NPV, IRR, undiscounted total. stress_test_decision (simulate × decide)