Lifecycle / MCP & agent skills

Agents

Most people now reach this library through a coding agent. These are the three ways to make sure the agent gets it right rather than guessing.

1. The registry namespace

// components.json
{
  "registries": {
    "@inputcn": "https://input-cn.vercel.app/r/{name}.json"
  }
}

This needs no code from us — shadcn’s own MCP server reads any spec-compliant registry. Add it and an agent can browse and install inputcn components by name.

2. The skills

npx skills add 42aditya31/inputcn

Three skills: inputcn for building a field, inputcn-blocks for a whole form, and inputcn-migrate for moving off another library. They carry the canonical-value table, the generated prop list and the traps — loaded into the agent at the moment it writes code, not left in documentation it may not read.

3. The MCP server

{
  "mcpServers": {
    "inputcn": { "command": "npx", "args": ["-y", "@inputcn/mcp"] }
  }
}

What the server answers

TOOLQUESTION IT REPLACES

inputcn_list_componentsWhich component do I need, and what does it emit?

inputcn_get_propsWhat props does this really have? (guessing is the failure)

inputcn_canonical_valueWhat do I actually store, and what is the usual mistake?

inputcn_list_blocksIs there already a whole form for this?

inputcn_validate_specIs this spec correct, before I write any files?

inputcn_generate_formWrite the form for me, correctly.

Why this matters more than documentation

Agents are not bad at finding component libraries. They are bad at value semantics. An agent will happily write a phone field that stores (415) 555-2671 and a price field that stores a float. The code looks right, passes review, and is wrong.

Every tool above exists to answer one of those questions with the real answer, read from the same extracted interfaces the documentation is built from. The server cannot tell an agent something the library does not do.