InstaDeck

Validate deck

validate_deck

Read-onlyIdempotent

Checks a deck for structure, data, contrast, text fit, motion budget, and visual rhythm, flagging overflow so you can fix issues before presenting.

Instructions

Checks a deck: structure, data, contrast, text length, motion budget and visual rhythm. The local server also measures text that overflows its space in a browser, on the hosted connector the deck view reports overflow when it renders.

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": {
      "deck_id": "<deck_id>"
    },
    "name": "validate_deck"
  }
}

Input Schema

Name	Required	Description	Default
`deck_id`	Yes	Deck id from create_deck or list_decks

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 21, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description does add genuine behavioral nuance by noting that overflow measurement differs between the local server (browser-measured) and the hosted connector (reported at render time). However, it says nothing about what the validation returns, severity levels, or whether it mutates nothing (left to annotations).

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?

Two sentences, front-loaded with the primary purpose and the checklist immediately after. The second sentence is slightly convoluted around the local-vs-hosted distinction but still earns its place by flagging an environment-dependent behavior.

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

Completeness3/5

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

For a read-only single-parameter tool this is close to adequate, and annotations carry the safety story. The missing piece is the result shape: with no output schema, the description should say whether it returns a pass/fail verdict, a list of issues, or per-category findings, since that determines how an agent acts on the result.

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?

There is one parameter with 100% schema description coverage, and the schema already explains it comes from create_deck or list_decks. The description adds nothing beyond the schema, so the baseline of 3 is the correct ceiling here.

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 gives a specific verb ('Checks a deck') and enumerates exactly what is inspected: structure, data, contrast, text length, motion budget, visual rhythm. That is far more concrete than a tautology. It stops short of a 5 only because it never positions itself against adjacent read tools like get_deck or get_deck_view.

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 implied rather than stated: by listing validation categories, an agent can infer this is a pre-flight QA step, but nothing says when to run it, whether it should precede apply_ops/export_deck, or whether it is safe to call repeatedly. No alternatives or exclusions are named.

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