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

With no annotations present, the description carries the full burden. It usefully discloses the blast radius (plugin-drawn content only) but says nothing about reversibility, undo behavior, whether confirmation is needed, or what happens if nothing was drawn — meaningful gaps for a destructive, unrestricted tool.

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 with the action and scope front-loaded and the preservation guarantee immediately after. No filler or redundant restatement of the title.

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 no-argument tool with no output schema and no annotations, the description covers the essential what and how-much. The remaining gap is post-invocation behavior — return value and whether the deletion can be undone.

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 no argument semantics to explain. The description correctly implies the implicit scope is 'current page' rather than requiring an argument.

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?

A specific verb (remove) plus an explicit resource set (every flowchart and shape the figma-flow plugin drew), with the scope narrowed to the current Figma page. This is easily separable from the creation-oriented siblings draw_demo_flowchart and create_flowchart.

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?

The second sentence defines the boundary condition — everything else on the page is left alone — which effectively tells the agent when this tool is and isn't the right lever. It does not explicitly name an alternative or state when not to call it, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that server-side auto-layout is top-to-bottom, that shapes auto-size to labels, that each call is additive (new frame to the right of earlier charts), and that the figma-flow plugin must be running. These are non-obvious operational traits an agent could not infer from the schema.

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?

Front-loaded with the essential constraint (structure only, no coordinates) before the detailed bullet guidance. Every sentence either constrains input or explains behavior; nothing is 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?

For a 3-parameter tool with no output schema, the definition covers input shape, layout behavior, frame placement, and the plugin prerequisite. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so the baseline is 3; the description adds real semantic value with modeling rules for node types and branching that go beyond field descriptions. Some content (e.g. labeling decision edges "Yes"/"No") duplicates the schema's own edge-label text, preventing a 5.

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 concrete verb and resource ("Draw a flowchart in the open Figma file") and immediately defines the input contract (structure only, no coordinates). An agent can distinguish this from draw_demo_flowchart or clear_canvas without inspecting the schema, and the title/frame behavior makes the output tangible.

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?

Gives rich when-to-use guidance in the form of modeling rules (start/end nodes, process vs input_output, decision phrasing) and a prerequisite check via get_status. It does not explicitly contrast with sibling draw_demo_flowchart or state when *not* to use it, which keeps it below a 5.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the prerequisite that a Figma file must already be open and that the call has side effects on that document ('draw ... in the open Figma file'). It does not say what is added, whether existing canvas content is preserved or clobbered, or what happens if no file is open.

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, no filler, with the action and its target front-loaded before the justification. Every sentence earns its place.

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, no-output-schema demo helper, the description covers what it draws, where it draws it, and why you would call it. The remaining gap is failure behavior when no file is open and whether the drawing pollutes an existing canvas.

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 for the description to disambiguate. The baseline of 4 applies; the description correctly implies the only input is the ambient open-file state.

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 concrete verb and resource: draw a sample login flowchart into the open Figma file. The word 'sample' plus 'demo' in the name signals it is a smoke-test artifact rather than a real diagram, which is the key distinction from the sibling create_flowchart. It does not name that sibling explicitly, so the 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?

'Useful to check the setup works end to end' gives a clear when-to-use condition tied to verification. There is no when-not guidance and no explicit routing to create_flowchart for real diagrams or to clear_canvas to remove the demo artifact, both of which an agent would want to know given the sibling set.

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

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

With no annotations, the description carries the full disclosure burden; 'Report' implies a read-only, side-effect-free call, which covers the safety profile reasonably. However, it says nothing about what happens when the plugin is disconnected (error vs. negative result), whether the check is live or cached, or how long it may take.

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?

One sentence, front-loaded with the verb and the check being performed, with no filler or repetition of the title.

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?

There is no output schema and no annotations, so the description should say what a status report looks like (boolean, connection details, error state). It only states the question being answered, leaving the agent to guess the shape of the result and the disconnected-case 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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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 ('Report') and resource ('whether the figma-flow Figma plugin is connected to this server'), so an agent knows exactly what question the tool answers. It does not differentiate itself from the sibling 'ping', which is presumably also a connectivity/health check, leaving ambiguity about which to call.

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 would infer you call this to verify the plugin connection before invoking draw/create tools. There is no explicit when-to-use, no when-not-to-use, and no routing guidance relative to 'ping' or the other siblings.

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

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

No annotations are provided, so the description must carry the burden. It makes clear this is a non-mutating liveness probe and discloses the return payload ('pong'), which is exactly what an agent needs to know for a health check. Minor gap: it does not say how the optional message parameter changes the response.

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, purpose first and return value second, with zero filler. Nothing could be removed without losing information.

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-required-parameter health check with no output schema and full schema coverage, the description covers everything needed to invoke it correctly. The only missing piece is a pointer to the sibling get_status for semantically adjacent checks.

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 100% and the single optional 'message' parameter is fully documented as text to echo back in the schema. The description adds nothing about it and arguably implies a fixed 'pong' reply, so it neither compensates nor contradicts; baseline 3 applies.

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: check that the figma-flow MCP server is running, and what it returns. It is clear in isolation, but does not distinguish itself from the sibling get_status, which plausibly answers a similar liveness question.

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?

The liveness-check intent implies when to use it (before other calls, after connection issues), but there is no explicit guidance on when to prefer this over get_status or what to do with either result. Usage is inferred rather than stated.

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