Skip to main content
Glama
Sign In
Mipiti MCP Server

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Behavioural Threats

get_behavioural_threats

Read the possible threats the behavioural analysis finds for each control objective of a model. Read-only: nothing is judged, written or paid for.

Instructions

Read the possible threats the behavioural analysis finds for each control objective of a model. Read-only: nothing is judged, written or paid for.

The analysis runs over the model with no controls applied. Per objective it returns its standing, each obligation's result, the threats (rule, obligation, elements), the default_questions whose answers would remove them, and the grounds the analysis rests on. Returns decides: false while the behavioural model is absent, asks an owner question, or has not been extracted.

A page at a time, in the model's order of objectives: offset and limit (default 25, at most 200), co_id one objective (404 unknown_objective for one the model does not hold live), standing only the objectives of that standing (possible_threat, undecided, ...). The answer carries total (the objectives matching), next_offset (where the next page starts, null at the end) and truncated (the page was cut short to stay under the size a client can take; read on from next_offset).

A possible threat is not a finding yet. RELAY IT TO THE PERSON with its default questions first: an answer that settles a default removes the threat, and only a threat the person confirms is worth a control. Answer with answer_behavioural_questions.

Input Schema

NameRequiredDescriptionDefault
co_idNoOne objective (e.g. "CO5"); empty for every one.
limitNoObjectives per page (default 25, at most 200).
offsetNoThe first objective of the page (default 0).
model_idYesID of the threat model.
standingNoOnly objectives of this standing; empty for every one.
server_versionYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.90.0
    • addedInput schema / properties / co_id
      Added value: +{
+  "default": "",
+  "description": "One objective (e.g. \"CO5\"); empty for every one.",
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 25,
+  "description": "Objectives per page (default 25, at most 200).",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "The first objective of the page (default 0).",
+  "type": "integer"
+}
    • addedInput schema / properties / standing
      Added value: +{
+  "default": "",
+  "description": "Only objectives of this standing; empty for every one.",
+  "type": "string"
+}
  2. Addedv0.87.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it declares read-only ('nothing is judged, written or paid for'), explains the analysis runs with no controls applied, enumerates the returned fields, and discloses that it returns decides:false when the behavioural model is absent, asks an owner question, or has not been extracted. It also flags the 404 unknown_objective case and the truncation/next_offset pagination contract.

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 a one-line purpose, then behavior, then pagination parameters, then the workflow warning — a sensible ordering with no filler. The pagination paragraph is dense and partly duplicates schema text, which is the main thing keeping it from a 5.

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?

For a read tool with six parameters and a rich output shape, the description covers what is returned (standing, result, threats, default_questions, grounds), the decides:false states, and the total/next_offset/truncated envelope, so an agent knows both what it gets and how to continue paging.

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 83%, so the baseline is 3; the description goes further by giving the error semantics for co_id ('404 unknown_objective for one the model does not hold live') and example standing values ('possible_threat', 'undecided', ...) that the schema leaves as a bare string. The page-size and offset details largely restate the schema, so it is not a full 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?

The opening sentence gives a specific verb and resource: 'Read the possible threats the behavioural analysis finds for each control objective of a model.' It is scoped distinctly from siblings like get_behavioural_model or get_findings_risks by naming 'possible threats' (not findings) and 'per control objective', so an agent can tell what it returns without opening the schema.

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?

Strong downstream routing: 'A possible threat is not a finding yet. RELAY IT TO THE PERSON with its default questions first' and 'Answer with answer_behavioural_questions' tell the agent exactly what to do after calling. It lacks an explicit negative case (when to prefer get_behavioural_model or query_threat_model instead), which keeps it just short of a 5.

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