Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

List Threat Models

list_threat_models

List threat models in the workspace, filterable by source, to discover model IDs for other tools or review the portfolio. Include assessment summaries to identify at-risk models.

Instructions

List saved threat models in the current workspace.

Read-only; no side effects. Returns {items: [{id, title, version, created_at, ...}], count}. Use this to discover model IDs to pass to other tools, or for a portfolio overview.

Input Schema

NameRequiredDescriptionDefault
sourceNoFilter by the system that created each model. One of "web", "mcp", "jira", "api". Omit (default "") to list all models regardless of source.
server_versionYes
include_assessment_summaryNoIf True, include an `assessment_summary` object per model (counts of mitigated / at_risk / unassessed control objectives plus a human-readable `message`). Use for aggregate posture queries across the workspace in a single call (e.g. "which of my models are at risk?") instead of calling `assess_model` once per model. Adds roughly 100 bytes per model. Default False.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.66.0
    • changedInput schema / properties / include_assessment_summary / description
      Previous value: -"If True, include an `assessment_summary`\nobject with each model (counts of mitigated / at_risk /\nunassessed COs plus a human-readable `message`). Useful for\naggregate posture queries across the workspace in a single\ncall — e.g. \"which of my models are at risk?\" — instead of\ncalling `assess_model` once per model (N+1 at the agent layer).\nAdds ~100 bytes per model to the response."New value: +"If True, include an `assessment_summary` object per model (counts of mitigated / at_risk / unassessed control objectives plus a human-readable `message`). Use for aggregate posture queries across the workspace in a single call (e.g. \"which of my models are at risk?\") instead of calling `assess_model` once per model. Adds roughly 100 bytes per model. Default False."
    • changedInput schema / properties / source / description
      Previous value: -"Filter by source system. One of \"web\", \"mcp\", \"jira\", \"api\".\nOmit to list all models regardless of source."New value: +"Filter by the system that created each model. One of \"web\", \"mcp\", \"jira\", \"api\". Omit (default \"\") to list all models regardless of source."
  2. First observedv0.57.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations present, the description must carry the burden of behavioral disclosure. It explicitly states 'Read-only; no side effects' and describes the return shape as {items: [{id, title, version, created_at, ...}], count}. This is strong transparency for a list operation, though it does not mention pagination, authentication, or rate limits.

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

Conciseness5/5

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

The description is two sentences with no wasted words. It front-loads the action and resource, then states side-effect behavior, return shape, and intended use in a compact, scannable way.

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?

The description is largely complete for a read-only list tool: it covers purpose, side-effect profile, return shape, and primary use cases. The main missing context is an explicit note about the required server_version parameter and guidance distinguishing this from get_threat_model for detailed model retrieval.

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 67%, covering source and include_assessment_summary, but the required server_version parameter has no description. The main description adds no extra parameter-level meaning beyond the schema, so the undocumented required parameter remains a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists saved threat models in the current workspace, with a specific verb and resource. It does not explicitly differentiate itself from related siblings like get_threat_model or query_threat_model, but the term 'list' plus the focus on model IDs and portfolio overview make the core purpose unambiguous.

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 gives concrete use cases: discovering model IDs to pass to other tools and portfolio overview. It does not explicitly say when to prefer alternatives such as get_threat_model or query_threat_model, but the use cases are helpful enough to orient an agent.

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