Candor UI docs

Read a screen from the catalogue

get_screen

Read-onlyIdempotent

Read one screen as Markdown: what it's for, two or three layouts with when to pick each, the Candor UI items that build each (with tiers), an install command, the honesty rules that matter most on it, and a brief to hand to the coding agent that builds it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_screen"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	The screen's slug, as list_screens or suggest_components gives it, e.g. "approvals-inbox".
`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.

Changed1 schema field changedNov 10, 2026

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"
+}

AddedNov 8, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description's real contribution is enumerating the returned Markdown contents, which matters because there is no output schema. It adds no auth, rate-limit, or failure-mode context of its own, and the version fallback note lives in the schema rather than here.

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?

A single front-loaded sentence with the verb and return format first, then a compact list of what the Markdown contains. Dense but every clause names a distinct payload element; no filler.

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?

With no output schema, the description carries the burden of telling the agent what comes back, and it does so thoroughly for a read tool. What remains thin is guidance on selecting this over sibling retrieval tools, which the description leaves implicit.

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

Parameters3/5

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

Schema coverage is 100%, so both slug and version are already fully documented, including the version fallback rule. The description adds no syntax, format, or default behavior beyond what the schema states, so the baseline 3 applies.

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?

"Read one screen as Markdown" gives a specific verb and resource, and the enumeration that follows (layouts, UI items with tiers, install command, honesty rules, agent brief) makes the payload concrete. It does not name a sibling to contrast with, so an agent must infer the boundary against get_pattern or get_component_docs from the word "screen" alone.

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?

The only routing signal is the slug provenance ("as list_screens or suggest_components gives it"), which implies you fetch this after discovering a screen. There is no explicit when-to-use versus when-not, and no statement of what this tool is not for relative to the sibling docs tools.

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.