Skip to main content
Glama
Mipiti
by Mipiti

Assess Model

assess_model

Evaluate a threat model's control objectives deterministically and read-only, returning mitigated, at-risk, and unassessed counts plus defined, implemented, and verified metrics.

Instructions

Run the deterministic assurance assessment over a threat model. Read-only — no LLM calls, no mutation.

Evaluates each control objective from its controls' implementation status and returns summary counts (mitigated / at_risk / unassessed) plus progressive metrics (defined / implemented / verified). For LLM-based reasoning about which COs are under-covered and what controls to add, use check_control_gaps instead.

Use summary_only=True to get just the counts without per-CO assessments.

Paging: a read with limit that leaves pages beyond its own names a snapshot of the whole assessment, with snapshot_expires_at. Pass it back with each later page: the pages are then served from that one evaluation, as of its evaluated_at, so they agree with each other and nothing is evaluated again. A snapshot is kept for 10 minutes, and only the 5 newest of a model, so other paged reads of the model can replace it sooner. One not found comes back as {http_status: 410, code: "snapshot_not_found", message}: read again without it, from the first page.

Input Schema

NameRequiredDescriptionDefault
limitNoMax control objectives to return (0 = all).
offsetNoSkip the first N control objectives.
statusNoOptional filter — "mitigated", "at_risk", or "unassessed".
model_idYesID of the threat model to assess.
snapshotNoThe ``snapshot`` an earlier page named; empty (default) evaluates the model now.
summary_onlyNoIf True, return only summary counts (no per-CO details).
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.94.0
    • addedInput schema / properties / snapshot
      Added value: +{
      +  "default": "",
      +  "description": "The ``snapshot`` an earlier page named; empty (default)\nevaluates the model now.",
      +  "type": "string"
      +}
  2. Changed4 schema fields changedv0.66.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max to return (0=all)."New value: +"Max control objectives to return (0 = all)."
    • changedInput schema / properties / offset / description
      Previous value: -"Skip first N."New value: +"Skip the first N control objectives."
    • changedInput schema / properties / status / description
      Previous value: -"Filter: \"mitigated\", \"at_risk\", \"unassessed\"."New value: +"Optional filter — \"mitigated\", \"at_risk\", or \"unassessed\"."
    • changedInput schema / properties / summary_only / description
      Previous value: -"If True, returns only summary counts (no per-CO details)."New value: +"If True, return only summary counts (no per-CO details)."
  3. Addedv0.62.2
  4. Removedv0.62.1
  5. First observedv0.57.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: read-only, no LLM calls, no mutation, and a detailed disclosure of snapshot paging behavior including the 10-minute retention, the 5-newest-per-model eviction, and the exact 410 snapshot_not_found recovery path. This is behavior an agent cannot infer from the schema.

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 and the sibling distinction, then output shape, then paging. The snapshot paragraph is long and uses dense inline code formatting, but every clause (expiry, eviction, error code, recovery instruction) is operationally necessary for correct paging.

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 only needs to orient the agent, and it does so fully: read-only guarantees, the shape of the returned counts and metrics, the summary_only shortcut, and the complete stateful paging protocol including failure recovery.

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 86%, so the baseline is 3; the description adds real meaning on top by explaining how limit interacts with snapshot creation, how snapshot is threaded across pages, and what summary_only changes about the response. The status filter's allowed values live only in the schema and are not reinforced, which keeps this just below a 5.

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 ('Run the deterministic assurance assessment over a threat model') and immediately characterizes the inputs and outputs (control implementation status → mitigated/at_risk/unassessed counts plus defined/implemented/verified metrics). It also explicitly separates itself from the nearest sibling, check_control_gaps.

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 routing rule: use this for deterministic assessment, use check_control_gaps when the agent wants LLM reasoning about which COs are under-covered. It also names a usage variant (summary_only=True for counts only) so the agent knows when to narrow the call.

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

Deploy Server

Other Tools