Skip to main content
Glama

Review the remediation plan

review_plan
Read-only

View the latest scan's remediation plan. Use for "what should I fix?". For the next batch of work with implementation instructions, use get_next_remediation_task_set instead.

The plan includes resolved controls. Implement controls whose
remediation_category is 'automatable'. Controls are ordered must_implement,
then legacy nice_to_have, then covered, each by priority_rank. Show
severity to the user.

analysis_job_id reads the plan of an earlier analysis; without it, the
latest. scan_id in the reply names the scan the plan comes from. analysis_in_progress=true
means a scan other than this plan's is running and this plan is from the
last complete scan; tell the user.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "review_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idNoProject ID (provide either project_id or project_name)
project_nameNoProject name (provide either project_id or project_name)
analysis_job_idNoAnalysis job id whose plan to review. Defaults to the latest completed analysis.

Output Schema

NameRequiredDescriptionDefault
errorNoTrue when the call itself failed. False for successful calls, including a scan still running, an already approved plan, or a repository classified as non-agentic. The reason field describes these workflow states.
reasonNoA stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
messageNoExactly one sentence written for the user. Never raw exception text or a backend error string, which may expose private details.
scan_idNoThe scan whose analysis produced this plan. Null when Trent does not name one: a legacy analysis, or a Trent version that does not send it.
controlsNoAll remediation controls sorted must_implement first, with control_status. When the Trent workspace files tickets, a control on a ticket carries 'ticket' (key, url, trent_state).
metadataNoCaller metadata, such as 'expiration_warning'. Substantive results have their own fields. Never includes exception or backend error text, which may expose private details.
next_stepsNoRecommended next actions, in order.
controls_fromNoWhich report the control_status values come from: scan_id, and report_is_stale / report_stale_reason when a newer scan exists than that report.
analysis_job_idNoAnalysis job identifier for the plan.
retry_after_secondsNoWith reason rate_limited, how many seconds Trent asks the caller to wait.
analysis_in_progressNoTrue when a scan other than this plan's is running, so this plan is from the last complete scan and may change when that scan finishes; say so. False while the plan's own scan settles. Null when Trent does not say.
classification_breakdownNoCounts every control in the plan by classification, including completed and covered ones: the set get_security_posture's control_total counts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / retry_after_seconds
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "With reason rate_limited, how many seconds Trent asks the caller to wait.",
      +  "title": "Retry After Seconds"
      +}
  2. Changed3 schema fields changed
    • changedOutput schema / $defs / ControlsFrom / properties / report_stale_reason / description
      Previous value: -"Present when report_is_stale is true. scan_in_progress: a newer scan is running. latest_scan_failed: the latest scan did not complete."New value: +"Present when report_is_stale is true. scan_in_progress: a newer scan is running. latest_scan_failed: the latest scan did not complete. requested_scan_failed: the scan asked for failed, so the last good scan's statuses are shown. requested_scan_did_not_produce: the scan asked for produced no plan."
    • addedOutput schema / $defs / ControlsFrom / properties / requested_scan_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The scan the read asked for, present when it differs from scan_id: another scan's report answered for it. Name both scans when you report the statuses.",
      +  "title": "Requested Scan Id"
      +}
    • changedOutput schema / properties / analysis_in_progress / description
      Previous value: -"True when a newer scan is running, so this plan is from the last complete scan and may change when that scan finishes; say so. Null when Trent does not say."New value: +"True when a scan other than this plan's is running, so this plan is from the last complete scan and may change when that scan finishes; say so. False while the plan's own scan settles. Null when Trent does not say."
  3. Changed5 schema fields changed
    • addedOutput schema / $defs
      Added value: +{
      +  "ControlsFrom": {
      +    "additionalProperties": true,
      +    "properties": {
      +      "report_is_stale": {
      +        "anyOf": [
      +          {
      +            "type": "boolean"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "default": null,
      +        "description": "True when a newer scan exists than that report, so the statuses are from the earlier scan named by scan_id; say so. False when that report is the latest. Null when this tool cannot tell: its read is pinned to one job, and Trent does not judge staleness for a pinned read.",
      +        "title": "Report Is Stale"
      +      },
      +      "report_stale_reason": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "default": null,
      +        "description": "Present when report_is_stale is true. scan_in_progress: a newer scan is running. latest_scan_failed: the latest scan did not complete.",
      +        "title": "Report Stale Reason"
      +      },
      +      "scan_id": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "default": null,
      +        "description": "The scan whose report the control statuses come from. Null when the read names none: a legacy scan, or a Trent version that does not send it.",
      +        "title": "Scan Id"
      +      }
      +    },
      +    "title": "ControlsFrom",
      +    "type": "object"
      +  }
      +}
    • addedOutput schema / properties / analysis_in_progress
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "True when a newer scan is running, so this plan is from the last complete scan and may change when that scan finishes; say so. Null when Trent does not say.",
      +  "title": "Analysis In Progress"
      +}
    • changedOutput schema / properties / classification_breakdown / description
      Previous value: -"Counts of controls by classification."New value: +"Counts every control in the plan by classification, including completed and covered ones: the set get_security_posture's control_total counts."
    • addedOutput schema / properties / controls_from
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/ControlsFrom"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Which report the control_status values come from: scan_id, and report_is_stale / report_stale_reason when a newer scan exists than that report."
      +}
    • addedOutput schema / properties / scan_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The scan whose analysis produced this plan. Null when Trent does not name one: a legacy analysis, or a Trent version that does not send it.",
      +  "title": "Scan Id"
      +}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the read-only/closed-world annotations, it discloses non-obvious behavior: the plan can include resolved controls, items are ordered must_implement then nice_to_have then covered, and analysis_in_progress=true means the plan is from the last complete scan and the agent must surface that staleness to the user. It does not discuss size/pagination or cost, keeping it short of a 5.

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?

Front-loaded with purpose, then routing, then behavioral detail; the ordering and remediation_category instructions are dense but earn their place. Slightly sprawling across three paragraphs with some redundancy around return values that the output schema already covers.

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?

With an output schema present, the description needn't enumerate return fields, yet it still flags the two fields that change agent behavior (scan_id provenance and analysis_in_progress). Combined with complete param coverage and read-only annotations, an agent has everything needed to call and interpret the result correctly.

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?

Schema coverage is 100% and the description mostly restates it: "analysis_job_id reads the plan of an earlier analysis; without it, the latest" mirrors the schema's "Defaults to the latest completed analysis." It adds no guidance on project_id vs project_name beyond what the schema already documents.

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?

States a specific verb and resource ("View the latest scan's remediation plan") and immediately names the sibling it is not suitable for (get_next_remediation_task_set), so an agent can disambiguate without opening either schema.

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?

Gives an explicit selection cue ("Use for 'what should I fix?'") plus a named alternative and the condition that selects it ("For the next batch of work with implementation instructions..."). Both when-to-use and when-not-to-use are present.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.