u/ProfessionalPage7174

Ibirdui is a shadcn-style React registry (you own the code) where every component handles loading/empty/error/success and ships an axe a11y test. This week I added an MCP server so AI assistants build with the real components instead of guessing. Open source.

I kept hitting the same wall with AI coding: ask for "a users list with loading, empty and error states" and you get markup that looks right but is subtly wrong and not accessible. The model has no idea what's actually in your library.

So over the last 5 days I shipped:

ibirdui-mcp (Model Context Protocol server) — three tools for an assistant:

• search_components — rank the catalog against a plain-language need
• list_components — filter by async state (loading/empty/error/optimistic/offline)

Add it in one line:

claude mcp add ibirdui -- npx -y ibirdui-mcp

Then "use ibirdui to build a save button with a loading state" pulls the real async-button source and composes with it.

Also new this week:

• ibirdui doctor — read-only health check (flags components you've edited locally or that have updates available)
• live, interactive previews on the docs site

The thesis (shadcn's ownership idea, taken further): you own the code and it's state-complete + accessibility-tested out of the box.

Repo + live docs: https://github.com/Geekles007/ibirdui

website: https://ui.ibird.dev

Install a component: npx ibirdui add async-button

It's a solo open-source project and I'd genuinely love feedback — especially on the MCP tool design: are search/get/list the right primitives? What would you want an assistant to be able to query?

There's a polished SDK for talking to LLMs on the web (the Vercel AI SDK). On the Dart/Flutter side there was nothing equivalent — everyone re-wires the same plumbing (request shaping, SSE streaming, tool-call round-trips, multi-provider) by hand.

So I built llm_sdk: one interface, three brains behind it.

• 🔁 Multi-provider — Claude, OpenAI, Gemini. Swapping is literally one line.
• ⌨️ Streaming — streamText gives you a Stream<String>, word by word.
• 🛠️ Tool calling — declare a Tool, the SDK orchestrates the whole loop.
• 📋 Structured outputs — generateObject<T> fills a typed Dart object.

The whole design rests on a 2-method provider contract; all the logic (tool loop, streaming, structured outputs) lives once in the client. Adding a provider is pure dialect translation.

Pure Dart package (no Flutter dependency), MIT, fully tested (mocked request/response + SSE).

pub.dev: https://pub.dev/packages/llm_sdk GitHub: https://github.com/Geekles007/llm_sdk

Feedback very welcome — especially on the API ergonomics and which provider you'd want next (Mistral? Ollama? local?).