Skip to main content
Glama
latent-defense

Latent Defense MCP Server

Official

create_remediation_ticket

Create a remediation ticket for a detected attack path, initiating immediate upstream ticket creation and a background remediation loop.

Instructions

Create a remediation ticket for an attack path and start two-step remediation.

Creates the upstream ticket on the active provider immediately (~seconds), then runs the LLM+JEPA remediation loop in the background and updates the ticket. Poll get_ticket_steps for per-iteration progress. Provider-agnostic: the ticket lands on whichever provider is currently active (see get_ticket_provider).

Args: path_id: Attack path ID (from triage / validation tools). repository_id: InfraDB repository ID the path belongs to. branch_id: InfraDB branch ID. entry_node: Path entry node ID. target_node: Path target node ID. steps: JSON array of path-step objects (source_node/target_node/...). step_count: Number of steps in the path. risk_score: Path risk score (0.0-1.0). mitre_techniques: JSON array of MITRE ATT&CK technique IDs. difficulty: Path difficulty ("low"/"medium"/"high"). source: Optional origin tag for the ticket. validation_verdict: Optional JSON object with the validation verdict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
path_idYes
repository_idYes
branch_idYes
entry_nodeYes
target_nodeYes
stepsNo[]
step_countNo
risk_scoreNo
mitre_techniquesNo[]
difficultyNomedium
sourceNo
validation_verdictNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses the two-step remediation: immediate ticket creation then background LLM+JEPA loop. It also mentions polling for progress and provider-agnosticism. This gives the agent clear expectations.

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?

The description is well-organized with a summary, then step details, then parameter list. It is informative but slightly verbose; could be more concise for such a parameter-heavy tool.

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?

Given 12 parameters, no annotations, and no output schema description (but output schema exists), the description covers behavior, parameter semantics, and workflow (polling get_ticket_steps). It is fully complete for an agent to use correctly.

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?

The description provides detailed explanations for all 12 parameters, including source (path_id from triage), constraints (risk_score 0.0-1.0, difficulty low/medium/high), and default values. Since schema description coverage is 0%, this adds critical meaning beyond the schema.

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 clearly states the tool creates a remediation ticket and starts two-step remediation. It specifies the resource (remediation ticket) and action (create), distinguishing it from sibling tools like get_ticket or update_ticket_status.

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?

The description indicates use after triage/validation tools, suggests polling get_ticket_steps for progress, and notes provider-agnostic behavior. However, it does not explicitly state when not to use the tool or mention alternatives among siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/latent-defense/mcp-server-public'

If you have feedback or need assistance with the MCP directory API, please join our Discord server