API Plan Finder

Change what the canvas shows

canvas_do

Use this when: you have opened a canvas with canvas_open, or a search answer gave you a canvas_id for its analysis_url page (that page is a canvas too: once the person has opened it and tapped it you can change it), and want to show the user what you are explaining. One action per call (unknown or empty args are refused, not ignored; the applied field of the result says what changed): send action and args, e.g. {canvas_id, action: "sort", args: {by: "cost"}}, and make a second call for the next. Actions: filter {only_full, billing, providers}; exclude {offer_ids}; sort {by: cost|name|provider; on a search answer page also score, its default}; compare {offer_ids, 2 to 4} puts plans side by side and charts their cost by volume; highlight {offer_ids, note}; explain {text} adds your explanation to the canvas, marked as yours; what_if {change: search fields} asks the engine again with changed conditions (a budget goes here as max_monthly_cost_usd; a field set to null is removed; at most 6 per canvas); chart {kind: cost_by_volume|none}; reset. To narrow a search answer or add a condition, call search again with this canvas_id (the person keeps the same page). Returns the new summary. Read each shown plan's fails and not_stated before using what_if.

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": {
      "canvas_id": "<canvas_id>",
      "action": "<action>"
    },
    "name": "canvas_do"
  }
}

Input Schema

Name	Required	Description	Default
`args`	No
`action`	Yes
`canvas_id`	Yes

Output Schema

Name	Required	Description	Default
`shown`	Yes
`version`	Yes
`canvas_id`	Yes
`canvas_url`	Yes
`what_if_left`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description discloses that only one action is applied per call, that unknown or empty args are refused rather than ignored, that the result's 'applied' field reports what changed, that what_if is capped at 6 per canvas, that null removes a field, and that the new summary is returned. These are real behavioral traits an agent could not infer from the 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?

Information density is high and the when-to-use lead is front-loaded, with no filler sentences. However, the single run-on paragraph with nested parentheticals and inline caveats makes the action list harder to scan than a short structured breakdown would be.

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

Completeness5/5

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

For a 9-action mutation tool with an opaque nested args object, the description covers preconditions, per-action semantics, argument constraints, failure behavior, and limits. Return details are covered by the output schema and summarized in one clause, so 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.

Parameters5/5

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

Schema coverage is 0% and args is an opaque object, yet the description documents each action's argument payload (filter {only_full, billing, providers}, exclude/highlight {offer_ids}, sort {by}, compare {2 to 4 offer_ids}, explain {text}, what_if {change}, chart {kind}) including enum values and limits. This fully compensates for the absent schema documentation and is exactly what the description should carry 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 makes clear that this tool mutates an existing canvas opened via canvas_open (or a search answer page reached through canvas_id), and it enumerates the concrete actions (filter, sort, compare, what_if, etc.). It is distinguishable from canvas_open and search, but the opening sentence is framed as a 'use this when' condition rather than a crisp statement of what the tool does, so purpose emerges from context plus the action list.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance: an already-opened canvas, or a canvas_id from a search answer, with the precondition that the person has opened and tapped the page. It also gives an explicit alternative for a different goal ('To narrow a search answer or add a condition, call search again with this canvas_id') and a caution to read fails/not_stated before what_if.

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

All API Plan Finder tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?