Skip to main content
Glama
Sign In
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Dismiss Proposed Attacker

dismiss_proposed_attacker

Dismiss a proposed attacker for a credential set with a reason, optionally scoped to specific zones, and create a model version recording the dismissal.

Instructions

Dismiss the attacker the attacker closure proposes for a credential set, with why, or some zones of a part of the zones nobody stands at. Mutating; creates a model version.

The dismissal is kept on the model: the proposal is no longer offered while it stands. zones names zones of a part (its kind is grouped) that no attacker reaches: those alone are dismissed, and the part stands for the rest; zone names the part where two proposals hold the same classes. Refused with 409 not_proposed (no attacker is proposed for exactly that set now), 409 ambiguous_proposal (name a zone), 409 dismissed_already, 409 closure_not_offered, 422 unknown_class, 422 unknown_zone (a zone the part does not offer now), 422 zones_of_own (zones of a class proposed on its own).

A program's dismissal is a judgment. Unless the workspace's delegation policy admits it, it is refused with 403 and an escalation_id and parked for a person. Do not retry: report the escalation_id and poll list_proposals.

Returns {model_id, model_version, applies, credential_classes, counts, dismissed_set, dismissed_zones_now?}: how many proposals, dismissals and questions the closure now holds, and what was dismissed.

Input Schema

NameRequiredDescriptionDefault
zoneNoA zone of the part, where two proposals hold the same classes; empty otherwise.
zonesNoComma-separated zones of the part to dismiss alone; empty dismisses the proposal whole.
reasonYesWhy the attacker does not apply (required).
model_idYesID of the threat model.
server_versionYes
credential_classesNoComma-separated class ids of the proposal; empty for the one holding none.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.94.0
    • addedInput schema / properties / zone
      Added value: +{
+  "default": "",
+  "description": "A zone of the part, where two proposals hold the same classes;\nempty otherwise.",
+  "type": "string"
+}
    • changedInput schema / properties / zones / description
      Previous value: -"Comma-separated zones of the grouped proposal to dismiss\nalone; empty dismisses the proposal whole."New value: +"Comma-separated zones of the part to dismiss alone; empty\ndismisses the proposal whole."
  2. Changed1 schema field changedv0.91.0
    • addedInput schema / properties / zones
      Added value: +{
+  "default": "",
+  "description": "Comma-separated zones of the grouped proposal to dismiss\nalone; empty dismisses the proposal whole.",
+  "type": "string"
+}
  3. Addedv0.90.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the operation is mutating, creates a model version, persists the dismissal, and stops the proposal from being offered. It also documents refusal codes, escalation behavior with 403 and escalation_id, and tells the caller not to retry but to poll list_proposals.

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 action is front-loaded in the first sentence, and the remaining detail is operationally relevant. The prose is dense and somewhat awkward in places, but most sentences earn their place by covering side effects, refusal conditions, and escalation flow.

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 complex mutating tool with six parameters and an output schema, the description is complete enough: it covers side effects, parameter selection, failure modes, escalation handling, and post-failure guidance. It does not need to explain return values because an output schema exists.

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 high at 83%, so the schema already explains most parameters. The description adds useful meaning for zone and zones, including that zones dismiss only named zones where no attacker reaches, while zone names a part where two proposals hold the same classes.

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?

States a specific mutating action: dismiss the attacker proposed for a credential set, optionally for zones. The resource and action are clear, though the phrasing is jargon-heavy and it does not explicitly differentiate itself from siblings like keep_attacker_whole or split_grouped_attacker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operational conditions for using zone versus zones and explains refusal cases, but it does not explicitly say when to choose this over sibling tools such as keep_attacker_whole or split_grouped_attacker. Usage is implied through parameter behavior and error handling rather than stated as decision guidance.

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