AI Agents & MCP
No language model was trained on Bst-Table. Ask a coding agent to "build a Bst-Table grid with
batch editing" and it will confidently write some other grid library's code — the very
libraries this project exists to replace. The @bloomskill/table-mcp server fixes that: point
your agent at it and it gets the real API — searchable docs, the full feature-toggle registry,
every cell type, exact type signatures, and the ability to scaffold and validate working grids.
Works with anything that speaks MCP — Claude Code, Cursor, VS Code (Copilot), Claude Desktop.
No MCP? Copy the prompt
Not every assistant speaks MCP, and sometimes you just want to paste something into a chat box.
The agent prompt is that: one self-contained briefing — the entry points, the enable* /
show* rule, every flag in this release, all the cell types, and the dependencies that are easy
to miss — small enough to sit at the top of a conversation.
It is generated from the same corpus as this site and the MCP server, so the flag list is the real one for the version it ships with. Fetch it however suits you:
curl -O https://gitofkumarsathish.github.io/bst-grid/prompt.txt # the raw file
npx -y @bloomskill/table-mcp prompt # print it locally
MCP clients can also read it as the bst://prompt resource, and attach it when handing work to a
model that cannot reach the tools. The prompt is the floor; the server is the ceiling — with MCP
registered, the agent can look anything up instead of relying on one message.
Register the server
Nothing to install first — npx fetches the package on first run.
Claude Code
claude mcp add bst-table -s user -- npx -y @bloomskill/table-mcp
-s user makes it available in every project on your machine; drop it for the current directory
only, or use -s project to write a .mcp.json your team gets on clone.
Cursor · Claude Desktop (mcpServers key)
{
"mcpServers": {
"bst-table": {
"command": "npx",
"args": ["-y", "@bloomskill/table-mcp"]
}
}
}
What the agent gets
The server exposes nine tools:
| Tool | What it does |
|---|---|
bst_search_docs | full-text search across the corpus |
bst_get_feature | a flag's layer, type, default, dependencies and status |
bst_get_cell_type | a meta.type cell's value shape, cellMeta and editability |
bst_get_api | exact type signatures from the built .d.ts |
bst_get_example | runnable usage examples |
bst_scaffold_grid | generate a working grid from a feature list |
bst_validate_config | check a grid config against the dependency rules |
bst_detect_version | resolve which release an API belongs to |
bst_list_versions | list the released versions, newest first |
Why it stays correct
The corpus is generated from source at build time — the same feature registry, cell types,
.d.ts signatures and coverage matrix that produce this documentation site. When a feature ships,
it flows into the MCP server automatically, so the agent's knowledge tracks the code release for
release. It's the same guarantee these docs give: what you read is what the compiler accepts.
These docs, the agent prompt and the MCP server are three faces of one corpus. Humans read the
Feature Guides; agents query bst_get_feature; a chat box gets the
prompt. None of them can drift from the code.