The Comp Desk Builder

build_workspace_page

Compose a WHOLE Pro Workspace page instead of one tile: several tiles (published slugs and/or inline declarative specs) over one shared global AWW and date of accident, each with its own inputs, in a saved layout. Returns the page object plus a self-contained HTML file that renders it with the live workspace renderer — the same no-eval whitelisted evaluator, so the numbers are the workspace's numbers, not this API's. Code tiles are never auto-run. Nothing publishes: create the calculators in your sandbox and submit_for_review as usual. Statutory max/min come from the date of accident via calc-core and cannot be supplied.

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": {
      "tiles": "<tiles>"
    },
    "name": "build_workspace_page"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`tiles`	Yes
`global`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses that code tiles are never auto-run, nothing publishes, statutory max/min are derived from the date of accident and cannot be supplied, and returned HTML uses the live no-eval whitelisted workspace renderer. It does not cover auth requirements, rate limits, or idempotency, which are relevant for a composite build operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then adds return behavior, renderer semantics, non-publishing, and derived statutory values. Every sentence carries substantive information, and there is no filler or repetition.

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?

For a complex nested tool with no annotations or output schema, the description covers the essential behavior: what is composed, how it is rendered, what is returned, what is not published, and that code tiles are not executed. It still leaves some parameter-level details undocumented, but the overall behavioral picture is strong enough to call the tool correctly.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It explains that tiles may be published slugs and/or inline declarative specs, that each tile has its own inputs, and that global AWW and date of accident are shared; however, it does not clarify the name parameter, global.caseName, tile id/name meaning, or the authoring enum's declarative/code distinction beyond noting code tiles are not auto-run.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: compose a whole Pro Workspace page rather than a single tile. It explicitly contrasts with one-tile tools and specifies that multiple tiles share a global AWW and date of accident in a saved layout.

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

Usage Guidelines4/5

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

It gives clear use context: build a whole page instead of one tile, and nothing publishes, so calculators should be created in the sandbox and submitted for review as usual. It does not explicitly name tile-level alternatives such as create_calculator or preview_calculator as the fallback for single-tile work, so it falls short of full when/when-not guidance.

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

All The Comp Desk Builder 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?