Dev Breakfast · 2026-10-02

Figma's remote MCP server only accepts clients on its supported list; Pi isn't on it, and getting in requires filling out a form. This tweet has already been viewed 395,000 times. An open protocol does not mean an open ecosystem — if you're wiring tools together with MCP, first glance at whether your stack is on the list.

Figma's MCP Only Accepts Whitelisted Clients, and the MCP's Creator Has Spoken Out

Figma's remote MCP server only accepts clients from its supported list, and Pi isn't among them. The official reply was courteous: check the current list on the MCP catalog, and if you want Pi on it, submit a form to apply. The tweet has 395,000 views, and David Soria Parra, the creator of MCP, replied as well — he envisioned an open ecosystem, finds this kind of restriction regrettable, and hopes Figma will either be more open or at least make the whitelist onboarding process simple enough. Someone put it well: this is like decreeing that only Firefox can access your website.

The protocol is open, but whether to accept a client, and which ones, is still up to the service provider. Anyone chaining a toolchain together with MCP should first confirm whether their stack is on the list.

Sources:

• Figma replies that Pi is not on the supported list, with links to the MCP catalog and the application form

turbopuffer Demotes ANN to a Secondary Index: Are Vector Databases Really Dead?

turbopuffer published a post titled "RIP, vector database," announcing a storage architecture overhaul for v3: the ANN vector index, long treated as the primary index, is being demoted to "just another" secondary index, replaced by a new primary index. In its own account, in the v1 era documents only had IDs and vectors; v2 added attribute filtering and BM25 full-text search, but the storage layout was always built around ANN — that is exactly the problem. Looking at its report card, the architecture isn't bad at all: 100B+ vectors in a single index, 200 ms p99, 1k+ QPS, with object storage as the source of truth to trade for cost, and NVMe SSD plus memory as tiered caching to trade for performance. So "dead" here isn't a case of being defeated by anyone — it's that it jammed itself up.

Where it jams, the original post spells out in detail. First is storage amplification: with multi-vector representations (nested documents, late interaction), the non-vector data has to be replicated once per vector. Second is write amplification: SPFresh may re-cluster on every insert, update, or delete, and since documents are stored entirely at ANN addresses, one rebalancing has to move the entire document content plus the attribute indexes and FTS indexes that reference it — touching one vector can drag along hundreds of attributes and their indexes. Third is that vectorization is constrained. These three factors directly suppress query plans like GROUP BY and aggregation. The path it chose is worth watching too: the primary index moved from SPANN to SPFresh for incremental indexing, using hierarchical clustering rather than a graph index, because clustering trees get along better with object storage.

For people who write code, you don't need to change dependencies short-term — v3 is still mid-migration, and the official team is simply "opening the door and letting people watch." What's really worth remembering is this judgment: vector retrieval isn't the endpoint; it's just one of many query plans. Whoever treats it as the primary key is forced to make trade-offs for it. If you're designing the storage layer for RAG, don't rush to lock down a "vector-first" schema — first work out how much of your querying is filtering, aggregation, full-text, and what fraction vectors actually occupy. As for that verdict in the title, a rough translation would be: it's not that vector databases died; it's that "only doing vectors" is no longer enough.

Sources:

• hackernews · razin

From v0.1.9 to v0.1.13: TileLang Writes GPU Kernels in Python

A DSL for writing high-performance kernels in Python has been making waves on GitHub recently. TileLang's positioning is straightforward: describe operators like GEMM, Dequant GEMM, FlashAttention, and LinearAttention with Pythonic syntax, with TVM's compiler infrastructure underneath. You write logic at the "tile" level, and the compiler is responsible for translating downward into something GPU/CPU/NPU can actually run — what it saves you is all the tedious work of hand-written CUDA: synchronization, scheduling, memory layout.

What's worth noting is its pace over the past few months. The version number has gone from v0.1.9 to v0.1.13, with an LLVM backend, a tile scheduler, a backend registry, a pass visualizer, and cross-host CUDA binary caching all packed in along the way. On the hardware front, Blackwell's SM120 NVF4 block-scaled MMA, Apple M5's Metal 4 cooperative-tensor GEMM, and AMD gfx950's FP4 E2M1 have been added one after another, and even Huawei Ascend 950 NPU gets native code generation. On the tooling side, an LSP has also been open-sourced, offering inlay hints for buffer shape, dtype, scope, and inferred layout. One concrete figure: DeepSeek V3.2's sparse-attention top-k selector saw its memory access pattern optimized, with roughly a 1.9× improvement reported.

But first, the costs. The v0.1.13 release removed several legacy APIs, so you have to read the compatibility notes before upgrading — in DSL projects at a fast-iterating stage, interface stability typically comes after features, and pinning versions plus reading release notes is routine. On top of that, it's built on TVM, which means accepting the mental model of that IR and pass system; during debugging you're facing intermediate representations inside TIRX, not the Python stack you're used to. When something really breaks, no matter how friendly the error messages are, you'll have to trace down through the passes yourself.

For people who write code, the significance here isn't "should I switch now" — it's that there's one more path available. In the past, touching this kind of kernel basically meant hand-written CUDA plus endless tuning; now you can describe the structure in Python and hand the optimization to the compiler. If you're doing performance work on the inference side, it's worth pulling down its examples first to see what the generated code looks like, then judging whether it can plug into your existing pipeline. As for going to production, waiting until it has stabilized the legacy API pitfalls a bit more is perfectly fine too.

Sources:

• tile-ai/tilelang - GitHub

OpenID Publishes a 33-Page Whitepaper: Agents Should Have Their Own Identity Credentials

The OpenID Foundation released a 33-page whitepaper dedicated to identity management for Agentic AI. Its core claim is that an Agent shouldn't act under a user's identity to call services; instead, it should be issued independent credentials and go through an explicit "on-behalf-of" authorization flow. It names MCP as the currently dominant framework for connecting models with external tools, while acknowledging that approaches like function calling and A2A should also be supported. It also notes that OAuth 2.1 suffices for single-trust-domain, synchronous calls, but struggles in cross-domain, highly autonomous, asynchronous scenarios where one Agent acts on behalf of multiple users at once. The whitepaper also warns that vendors each building their own private Agent identity systems will cause fragmentation, forcing you into a pile of one-off integrations. If you're building Agents that call third-party services, the permission model is something you should think through now, not patch after something goes wrong. Issuing Agents their own identities is a better investment than letting them impersonate you.

Sources:

• Identity Management for Agentic AI (PDF)

---

The MCP's creator says he hopes Figma will be more open — whose side are you on: should the service provider set its own list, or should an open protocol mean anyone can connect? See you at 8 AM tomorrow.

This issue selected 4 items from 59 pieces of information gathered across X / Hacker News / GitHub Trending over the past 24 hours (collected and written hourly throughout the day, fact-checked, then compiled in the morning). The content was LLM-assisted, with a link to the original source for each item; please cross-verify important decisions.