Skip to main content
Glama

Generate safety analysis

generate_safety_analysis
Idempotent

Draft FHA failure conditions for a saved model's functions and FMEA failure modes for its parts under a chosen standard (ARP4761, DO-178C, ISO 26262, MIL-STD-882E or IEC 61508). Rows are written into a copy of the model as SysML, marked draft = true for an engineer to review; the saved model is not changed. With analysis "stpa" (no standard needed), drafts an STPA instead: losses, hazards, controllers with their process models, control actions and feedback as messages between parts, the unsafe control action table with all four types, and each safety constraint as a requirement; the result carries the compiler's STPA findings on the draft (missing UCA types, links to hazards and losses, unverified constraints, context variables no feedback updates). Paid. Call it directly: it charges what the job uses, never more than its estimated maximum or the max_spend_credits you set. request_id is optional; set one to make a retry safe. Returns job_id immediately. Poll get_job_status for later progress.

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": "generate_safety_analysis"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowsNoOnly for cost_mode "agent_authored" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}; with analysis "stpa": {losses:[{id,description}],hazards:[{id,description,losses}],controllers:[{target,processModel}],controlActions:[{from,to,name,ucas:[{id,type,context,contextVariables,hazards,constraint}|{type,notApplicable,rationale}]}],feedback:[{from,to,name,updates}],constraints:[{id,name,text}]}.
modelNo
studyNo
eventsNo
formatNo
promptNo
stop_sNo
analysisNoFor generate_safety_analysis: fha, fmea, both (default) or stpa. stpa needs no standard.
fidelityNo
model_idNoA model from a generation job (model_ id) or a saved studio model (m_ id); a saved model is read at the head of main.
providerNo
standardNo
cost_modeNomanaged
max_depthNoOnly for run_agent_swarm: levels of division, 1 to 3 (default 2). At 2 and 3, a subsystem the orchestrator judges too large for one agent is divided again inside its frozen boundary.
subsystemNoFor reprompt_agent: qualified name of the subsystem, e.g. "Rover::DriveUnit". For run_agent_swarm on a saved model: the subsystem to decompose one level further (its parts get the agents); leave it out to work on the whole system's subsystems.
request_idNo
scenario_idNo
simulationsNo
specificationNoOnly for cost_mode "agent_authored" on generate_system_model and build_full_system; see those tools for its schema.
simulation_typeNo
max_spend_creditsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / analysis / description
      Added value: +"For generate_safety_analysis: fha, fmea, both (default) or stpa. stpa needs no standard."
    • changedInput schema / properties / analysis / enum
      Previous value: -[
      -  "fha",
      -  "fmea",
      -  "both"
      -]New value: +[
      +  "fha",
      +  "fmea",
      +  "both",
      +  "stpa"
      +]
    • changedInput schema / properties / rows / description
      Previous value: -"Only for cost_mode \"agent_authored\" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}."New value: +"Only for cost_mode \"agent_authored\" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}; with analysis \"stpa\": {losses:[{id,description}],hazards:[{id,description,losses}],controllers:[{target,processModel}],controlActions:[{from,to,name,ucas:[{id,type,context,contextVariables,hazards,constraint}|{type,notApplicable,rationale}]}],feedback:[{from,to,name,updates}],constraints:[{id,name,text}]}."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: rows are written into a copy of the model marked draft = true, the saved model is untouched (reinforcing destructiveHint=false), the call is paid with a per-job cost ceiling and optional max_spend_credits, and request_id makes retries safe (consistent with idempotentHint=true). It also discloses the async contract — returns job_id immediately and progress comes from get_job_status — which the annotations cannot convey.

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 core action is front-loaded, but the STPA sentence is an overlong enumeration of losses, hazards, controllers, UCAs and constraints that is hard to parse, and the paragraph is one dense block. Much of the content earns its place, but the structure could be broken up for readability.

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?

With no output schema and 21 optional parameters, the description still covers the essentials an agent needs: what gets produced, that output is a draft copy, cost behavior, the async job/polling flow, and the STPA variant. The main omission is guidance on the remaining shared parameters (events, simulations, format), which keeps it short of complete.

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 description coverage is only 29% across 21 parameters, so the description must carry more weight; it does explain the standard enum values, the analysis modes including stpa, request_id, max_spend_credits, and that model_id can reference a saved studio model. However, many parameters (events, format, simulations, fidelity, provider, cost_mode, max_depth) get no mention, leaving a real gap for a tool this broad.

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: drafts FHA failure conditions and FMEA failure modes for a saved model's functions and parts under a named standard, plus an alternate STPA mode. The scope (drafts written into a copy, saved model unchanged) distinguishes it clearly from siblings such as verify_model or generate_system_model.

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?

Gives clear usage context: pick a standard for FHA/FMEA, or use analysis "stpa" with no standard, and it explicitly says to call the tool directly rather than pre-estimating, with the spend cap explained. It does not name a sibling to use instead when the user wants verification or a fresh model, so exclusions are implicit rather than stated.

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.

Resources