Skip to main content
Glama
Sign In

The Comp Desk Builder

by com.thecompdesk
OverviewDiscussionsAdmin

NY SLU % from range of motion

calculate_slu_percent_from_rom
Read-onlyIdempotent

A schedule loss of use percentage range from measured range of motion, scored by the app's SLU range-of-motion engine (2018 NY Impairment Guidelines): each joint's deficit by severity band with proportional adjustment, the paired-motion rule (both_motions), the ankylosis cap for the body part, an optional special consideration (added or stand-alone, as the engine marks it), an optional contralateral baseline, and the shoulder muscle-atrophy finding. Joints per body part: Thumb IP/MCP/CMC (CMC is the opposition grade 1–3), Finger DIP/PIP/MCP, Wrist Palmar Flex/Dorsi Flex/Pron/Sup, Elbow Extension/Flexion, Shoulder Forward Flexion/Abduction/Int Rotation/Ext Rotation/Adduction/Post Extension, Hip Abduction/Adduction/Int Rotation/Ext Rotation/Flexion/Post Extension, Knee Flexion/Extension, Ankle/Foot Plantar Flex/Dorsi Flex/Inversion/Eversion, Great Toe IP/MTP Flex/MTP Ext, Smaller Toes DIP/PIP/MTP. Returns a percentage, not an award: pass the percentage to calculate_slu_award. New York State only. Computes with The Comp Desk calc-core, the same engine as the app and the Pro Workspace; it never estimates. A missing input returns status "missing" and nothing is calculated. Returns the figures, the steps with the rule and engine function behind each, and the not-legal-advice notice. Needs your builder key. Same engine the Pro Workspace tiles call through CD.Calc, so a figure here matches the app to the cent.

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": {
      "body_part": "<body_part>",
      "measurements": "<measurements>"
    },
    "name": "calculate_slu_percent_from_rom"
  }
}

Input Schema

NameRequiredDescriptionDefault
body_partYes
both_motionsNoOptional: joints whose paired motion (extension, supination) is also deficient, so the higher figure applies.
measurementsYesJoint name → measured degrees (Thumb CMC: opposition grade 1, 2 or 3). Joint names exactly as listed in the description.
contralateralNoOptional: joint name → the uninjured side's degrees, used as the baseline.
special_considerationNoOptional: a special consideration label exactly as the engine lists it for this body part (an invalid label returns the allowed list).
shoulder_muscle_atrophyNoOptional, shoulder: a muscle-atrophy finding (gates the marked-rotation add).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world) it discloses that computation is deterministic ('never estimates'), that a missing input returns status 'missing' and computes nothing, that a builder key is required, and that the response includes figures, steps, and a not-legal-advice notice. These are real operational facts an agent needs. It loses a point for repeated marketing phrasing ('same engine as the app', 'matches the app to the cent') that adds words but no new behavior.

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

Conciseness3/5

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

The opening sentence is an unusually long run-on that crams every rule and joint list into one clause chain, and the engine-provenance claim is stated twice ('the same engine as the app and the Pro Workspace' / 'Same engine the Pro Workspace tiles call through CD.Calc'). The routing and constraint information is valuable, but the structure is dense and repetitive rather than front-loaded and trimmed.

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 six-parameter, nested-object tool with no output schema, the description covers the required inputs, the error path, the key requirement, the scope, and what the return contains (figures, steps with rule/function attribution, disclaimer). That is close to sufficient; only input-domain details such as accepted degree ranges are left unstated.

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?

With 83% schema coverage the baseline would be 3, but the description adds genuine meaning: the per-body-part joint lists that tell the agent which keys belong in the measurements map, the note that Thumb CMC is an opposition grade of 1–3 rather than degrees, and the semantics of both_motions, special_consideration, contralateral, and shoulder_muscle_atrophy. It does not, however, specify degree ranges or normalization for the numeric inputs.

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 — scoring a schedule loss of use percentage from measured range of motion — and names the exact sibling it feeds into (calculate_slu_award) as well as the governing standard (2018 NY Impairment Guidelines). An agent can distinguish it from calculate_slu_award and the other calculate_* siblings without opening a schema.

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 an explicit routing rule — 'Returns a percentage, not an award: pass the percentage to calculate_slu_award' — and a hard scope constraint, 'New York State only'. It does not say when a different SLU tool (e.g. joint replacement) would be the better choice, so the when-not guidance is partial rather than complete.

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 toolsInspect
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