Candor UI docs

How to set up Candor UI

get_started

Read-onlyIdempotent

How to install Candor UI in a React or Next.js app, render a chat, connect an agent SDK, add licensed items and keep them updated. With prompt: true, only "Give this to your agent": one block of text for adopting Candor into an app that already exists (it asks about the stack and the agent's API first, installs with the CLI, leaves the licence key to the person and names the providers to wrap the app in).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_started"
  }
}

Input Schema

Name	Required	Description	Default
`prompt`	No	true: only the adoption prompt, to hand to a coding agent.
`version`	No	A release, e.g. "2.6.2": the page as that release published it, for a project that has that version installed. Default: the version the server's URL passes (`?kit=`, which `npx candor-ui mcp` writes from candor-lock.json), else the current docs. When that release's docs weren't kept, or the page isn't in them, the answer is the current page with a note saying so.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedInput schema / properties / prompt

Added value: +{
+  "description": "true: only the adoption prompt, to hand to a coding agent.",
+  "type": "boolean"
+}

addedInput schema / properties / version

Added value: +{
+  "description": "A release, e.g. \"2.6.2\": the page as that release published it, for a project that has that version installed. Default: the version the server's URL passes (`?kit=`, which `npx candor-ui mcp` writes from candor-lock.json), else the current docs. When that release's docs weren't kept, or the page isn't in them, the answer is the current page with a note saying so.",
+  "maxLength": 32,
+  "type": "string"
+}

First observedNov 8, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish that this is a safe, read-only, idempotent documentation tool. The description adds useful behavior beyond those annotations, especially that `prompt: true` returns only one block of text for an existing app, including CLI installation, leaving the licence key to the person, and naming providers to wrap the app in.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, and there is no filler. The second sentence is dense with parenthetical detail, but each clause carries useful meaning about the `prompt: true` mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only documentation guide with annotations covering safety and a fully described schema for `version`, the description provides enough context to call the tool correctly. It explains the non-default prompt mode well, though it does not explicitly cover when to prefer this over sibling documentation tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters in detail. The description still adds semantic value by explaining that `prompt: true` is specifically for an existing app and describes what that adoption prompt will ask about and do, which goes beyond the schema's brief parameter note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource: setup and installation guidance for Candor UI in React or Next.js, covering chat rendering, agent SDK connection, licensed items, and updates. It does not explicitly name or contrast with sibling tools such as get_component_docs or search_docs, but the intended scope is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: use this when setting up or adopting Candor UI. The `prompt: true` mode gives a scenario for adopting Candor into an existing app, but the description does not name alternatives or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Candor UI docs tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.