Pushes a composed deck (stats tiles, lists, calendar, text notes) to the CDeck dashboard app running on a paired Apple TV, so the TV shows a live personal dashboard; also retrieves check-off status from the TV so completed items can be actioned at their source.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cdeck-mcp Pair my Command Deck, code ABC123, and build my dashboard."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Claude side of CDeck, an Apple TV dashboard that your own Claude keeps up to date.
No accounts. The 6-character code on your TV is the account.
Install CDeck on your Apple TV. It shows a code.
Add this MCP to Claude (Claude Desktop → Settings → Connectors → Add, or in claude_desktop_config.json):
{ "mcpServers": { "cdeck": { "command": "uvx", "args": ["cdeck-mcp"] } } }Tell Claude: "Pair my Command Deck, code ABC123."
Claude calls cdeck_pair, reads cdeck_schema, looks at whatever connectors you have (Gmail, Outlook, Planner, Fathom, Linear, …), builds a deck, pushes it, and sets up a recurring scheduled task to keep it fresh. The TV polls the feed on the interval the deck asks for.
Related MCP server: iCloud MCP Server Apple
tool | does |
| claim the code on the TV |
| deck format + how to compose a good one |
| replace what the TV shows |
| last update + items you checked off on the TV |
| paired TVs |
| forget a TV |
{"v":1,"updated":"2026-10-29T20:00:00Z","title":"Command Deck","subtitle":"Jane · Acme",
"refresh_seconds":1200,
"sections":[
{"type":"stats","items":[{"n":"3","label":"Open action items","sub":"1 overdue","kind":"hot"}]},
{"type":"list","title":"YOUR ACTION ITEMS","width":0.6,
"groups":[{"title":"Weekly sync · Oct 29","items":[{"id":"fathom:123","text":"Send the proposal"}]}]},
{"type":"list","title":"INBOX — NEEDS REPLY",
"items":[{"id":"mail:abc","tag":"HOT","kind":"hot","text":"Invoice question","meta":"Jane · 2h ago"}]},
{"type":"calendar","title":"TODAY","items":[{"time":"2:00 PM","text":"Vendor call","meta":"Zoom"}]},
{"type":"text","title":"NOTES","text":"Anything else worth a glance."}
]}stats renders as a tile row; every other section becomes a column. Items with an id get a checkbox on the TV; checked ids come back in cdeck_status() so Claude can complete them at the source.
The service is a single Cloudflare Worker + KV namespace (api/ in the CDeck repo). Deploy it, set CDECK_SERVER, and rebuild the TV app with your URL in project.yml.
The hosted service stores: a random device token, a random push token, and the last deck JSON your Claude pushed. Nothing else. cdeck_unpair deletes all of it.
MIT · 800 Pound Gorilla Inc.
List the TVs paired on this machine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. "List" plus "paired on this machine" does communicate a read-only, machine-local scope, which is useful, but it says nothing about whether the local pairing service must be running, latency, or behavior when nothing is paired.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the scope constraint ("on this machine") front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema, the description covers what is listed and the scope of the listing. The only meaningful gap is the empty-result / service-not-running case, which is minor given the output schema documents the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema is fully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("List") and a specific resource ("the TVs paired on this machine"), which cleanly separates it from the mutating siblings cdeck_pair/cdeck_unpair/cdeck_push. It does not explicitly differentiate itself from cdeck_status, which could plausibly also report paired devices, so sibling differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the read/inventory call to make before pairing or pushing. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. "use cdeck_status for connection health").
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pair with the Apple TV showing this 6-character code. name labels this TV locally
(default 'tv'); use distinct names if you pair more than one TV.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| name | No | tv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that names are local labels with a default of 'tv' and that distinct names matter for multiple TVs, but says nothing about failure modes, whether pairing persists across sessions, network/prerequisite requirements, or whether re-pairing replaces an existing entry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, the action and its input front-loaded, followed by the only non-obvious parameter caveat. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, and both params are described. But with zero annotations and no behavioral notes on persistence, idempotency, or errors, the agent lacks information needed to recover from a failed pairing or decide whether to re-pair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does: `code` is characterized as the 6-character code shown on the TV, and `name` as a local label defaulting to 'tv' with guidance to use distinct names for multiple TVs. That covers both parameters meaningfully, though it doesn't state code format constraints beyond length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — pairing with an Apple TV using a 6-character code — and is immediately distinguishable from the sibling set (cdeck_unpair, cdeck_push, cdeck_list). An agent knows exactly what operation this performs without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the precondition that the TV must be displaying a pairing code, which is real usage context. It doesn't route the agent away from alternatives (e.g., when to use cdeck_unpair or cdeck_status instead), but for a single-purpose pairing tool the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a deck to the paired TV. deck is the JSON document (object or JSON string) in the
format from cdeck_schema(). Replaces whatever the TV is showing.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | ||
| name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation replaces whatever the TV is showing, but it omits permissions, error behavior if unpaired, and validation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences front-load the action and then cover the key input format and overwrite behavior. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple push operation with an output schema, the description covers the core invocation, required input format, target, and overwrite effect. The main remaining gap is the undocumented optional name parameter and unpaired-TV behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The required deck parameter is explained as an object or JSON string using the cdeck_schema() format, which adds real value over the empty schema descriptions. However, the optional name parameter is not described at all despite 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Push" with the resource "deck" and target "paired TV," making the action unambiguous. Referencing cdeck_schema() further distinguishes it from schema/list/status siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: the deck must be in the format from cdeck_schema() and is pushed to the paired TV. It does not explicitly state when not to use it or name alternatives, but the prerequisite is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The deck document format (schema v1) plus guidance on what makes a good deck. Read this before the first push.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. Referring to it as documentation content implicitly signals a pure information read with no side effects, and the output schema covers the return shape, but the description never states explicitly that it is read-only, non-destructive, or requires no pairing/auth state — all of which are relevant given siblings like cdeck_pair and cdeck_unpair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states what it returns, the second states when to call it. Nothing is wasted and the content statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a full output schema, and a simple read-only purpose, the description covers everything an agent needs to decide to call it. Only the explicit absence of side effects or prerequisites is missing, which is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly adds no parameter detail and instead spends its words on content and timing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource it returns: the deck document format schema (v1) plus guidance on building a good deck. This clearly separates it from siblings like cdeck_push and cdeck_status, which operate on decks rather than describing the format. It stops short of an explicit verb (e.g. 'returns' or 'retrieves'), leaving the action slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read this before the first push' gives a concrete, actionable trigger tied to a named sibling tool, so the agent knows when to call it. There is no explicit when-not or note about whether re-reading later is useful, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When the TV's deck was last updated, and which item ids the viewer has checked off on the TV ('acks'). Use acks to complete/clear those items in their source before the next push.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description has to carry the load. It usefully discloses that the response includes 'acks' and what they mean operationally, and 'last updated' implies a read-only status call. It does not state that it is non-mutating, whether polling is expected, or any auth/pairing requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the payload described first and the actionable guidance second; nothing is padded. The density is bought partly with undefined jargon, which costs a little clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape needn't be explained, and the ack semantics are covered. But the single undocumented parameter and the unexplained deck/TV model leave real gaps for a first-time caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'name', at 0% description coverage, and the description never mentions it — so whether it selects a deck, a paired TV, or defaults to the only active pairing is left to guesswork. This is the main place the description needed to compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the concrete resource and payload: the deck's last-updated timestamp and the item ids the viewer has acked on the TV. An agent can tell this is a status/read tool, though the domain jargon ('deck', 'TV') is never defined and it doesn't contrast with cdeck_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a workflow directive for the output: 'Use acks to complete/clear those items in their source before the next push,' which implies this is checked before pushing. But it never says when to call cdeck_status versus cdeck_list or cdeck_schema, nor any prerequisite (e.g. pairing via cdeck_pair).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forget a paired TV: revokes the push token server-side and removes it locally. The TV will show a new pairing code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the server-side token revocation, the local removal, and the visible after-effect on the TV. It does not cover permissions, what happens if the name doesn't match a paired device, or whether the pairing can be restored without re-pairing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and scope, followed by the concrete consequence. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values needn't be explained because an output schema exists, and the side effects are well covered. The remaining gap is operational: the argument's meaning and the failure mode for an unknown name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single parameter "name" is untyped beyond string. The description implies the name identifies the TV but never says explicitly that the argument is the paired TV's name, nor where to obtain it (presumably cdeck_list) or how matching works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb pair (forget/revoke) and resource (a paired TV), and states the two-part effect: server-side token revocation plus local removal. It is clearly the inverse of the sibling cdeck_pair, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Forget a paired TV" gives a clear context for use and the follow-up sentence signals the consequence (the TV shows a new pairing code), which implies the operation is intentionally destructive to the pairing. There is no explicit exclusion or named alternative, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0cdeck_listcdeck_paircdeck_pushcdeck_schemacdeck_statuscdeck_unpairScored across 6 tools
Each tool targets a distinct action in the pairing/deck lifecycle: pair, list, unpair, push, status, and schema. The only potentially adjacent tools, cdeck_list and cdeck_status, are clearly separated as listing paired TVs versus inspecting deck update state and acks.
All tool names use the same cdeck_ prefix and snake_case convention. The suffixes are concise and consistently readable, even when mixing verbs (pair, push, list) and noun-like tools (schema, status).
Six tools is well-scoped for this server: pairing lifecycle, schema guidance, push, and status. No tool appears redundant or out of place.
The surface covers the core workflow: schema discovery, pairing, listing, unpairing, pushing a deck, and checking acks/status. A minor gap is the absence of a direct tool to read back the current deck, though status plus source-side ack handling may be sufficient for the intended workflow.
Deploy sims to any screen. Control your displays with Claude.
Deploy sims to any screen. Control your displays with Claude.
Connect Claude to your Platform7n workspaces: chat, links, work and decks. One-click OAuth.
Notes and actions in one app. Let Claude or ChatGPT read and update them.
