MCP Registry Has 31,309 Unique Servers, Not 101,219 — 23% Lack Source Code

·17 views

A developer analysed the official Model Context Protocol registry via its public API on 14 September 2026, finding that the widely cited figure of over 100,000 MCP servers is inflated by roughly 3.2x due to historical versioning. After deduplication, the registry contains just 31,309 distinct servers, with 69% of entries representing superseded older versions. Nearly 23% of servers — about 7,090 — have no linked source repository, making them impossible to audit without directly connecting to them. Concentration is also notable, with three hosts alone accounting for 14.5% of all servers and 17.4% sharing a hostname with at least 50 others. Monthly new server registrations surged from 456 in September 2025 to 6,673 by August 2026, raising concerns about the scalability of any manual review process.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Running Analytics Beside Live Logistics Transactions Without Slowing Them Down

Heavy analytical queries compete with transactional workloads for CPU, memory, and I/O on the same database, which can sharply increase latency for live operations. For logistics apps, this can delay order updates and route optimizations, with knock-on effects like missed delivery windows. The article argues that composed HTAP architectures, which separate transactional and analytical engines and sync them via shared storage or replication, can isolate these workloads. However, this approach introduces its own challenges, including network latency and replication lag that can cause stale analytics. The author recommends measuring p99 latency rather than averages and choosing an architecture based on workload patterns.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

MiMo V2.6 Flash Run Locally on Two Mac Studios Trails Cloud Version in Benchmark

A developer ran Xiaomi's MiMo V2.6 Flash, a 309-billion-parameter model, locally by splitting its layers across two Mac Studios linked by a Thunderbolt 5 cable. On a payments-app build benchmark, the local setup scored 0.6605, compared with 0.7909 for the same model on Xiaomi's cloud endpoint. Most of the gap came from a benchmark ceiling triggered by failed 3D checks, since the two runs earned nearly identical scores before that cap was applied. Adding vision support removed several failing checks, while the cloud run was stronger on 3D pixel work. The author presents this as a single-task field report rather than a broad comparison.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

MQTT Is Not a Message Queue: Why Persistent Sessions and QoS Matter for IoT Data

A team building an IoT system lost data from over 200 devices when a Python worker restarted during a deployment, with no error logs or dead letters. The article explains that MQTT is a lightweight publish/subscribe protocol rather than a true message queue, so messages are only delivered to active subscribers unless specific settings are enabled. It distinguishes QoS levels, retained messages, and persistent sessions, noting that QoS only guarantees delivery across a single hop and that persistent sessions are the closest equivalent to queuing. The author demonstrates how to configure a Mosquitto broker and a paho-mqtt client with fixed client IDs, non-clean sessions, and session expiry intervals so that messages are buffered while a consumer is offline. Because QoS 1 provides at-least-once delivery, the consumer must also handle duplicate messages, for example by tracking sequence numbers.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Chrome extension rebuilds Jira worklogs from issue changelog history

A developer built a Chrome extension that reads Jira issue changelogs to reconstruct when tickets were assigned and in working statuses, then turns that into draft worklogs. The tool estimates time from status and assignee transitions rather than tracking activity, so nothing is posted automatically and every draft is reviewed first. The changelog only records changes, so the approach reconstructs earlier states by walking the history backwards from the current state. Working windows, daily caps, and splitting time across overlapping tickets are applied, with entries rounded to 30-minute blocks while keeping daily totals consistent.

0 comments Read more at DEV Community