Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

create_security_disposition

Record a disposition for a finding. For a cluster vulnerability: acknowledge it (security.triage) or accept the risk (security.manage), scoped to the add-on the occurrence is attributed to, with a reason, an optional review deadline and whether it lapses when a fix ships. Every occurrence the selector matches is dispositioned at once - run preview_security_disposition first and put its match count in the proposal. Needs an active occurrence with high-confidence add-on attribution; one without is refused. For a Semgrep or Checkov finding that blocks the Ankra Pipelines image gate (scope repository_code, security.manage): record it as false_positive or accepted_risk (accepted_risk needs expires_at within a year), with a reason; the gate stops blocking on that rule in that file and names the disposition on every run it lets through, and the finding stays scanned and recorded. Use this for a reviewed false positive instead of adding an inline nosemgrep. A CRITICAL finding is refused. Reversible: revoke_security_disposition reopens the findings.

Input Schema

NameRequiredDescriptionDefault
pathNoWith scope repository_code: the file the finding is in, as get_application_code_security reports it (file_path).
toolNoWith scope repository_code: semgrep or checkov, the scanner that reported the finding (get_application_code_security).
scopeNoWhat the disposition is pinned to. For a cluster vulnerability, with occurrence_id: organisation_addon (the default) pins the add-on the occurrence is attributed to across the organisation and needs a high-confidence add-on attribution; workload pins the one workload (cluster, kind, namespace, name); image pins the image digest wherever it runs. Use workload or image when the occurrence has no add-on attribution (operator-managed pods, plain manifests, control-plane pods, charts outside the catalogue). repository_code is a Semgrep or Checkov finding of a pipeline repository: pass application_id or repository_id, tool, rule_id and path instead of occurrence_id, and the Ankra Pipelines image gate stops blocking on that rule in that file while the disposition is active. Never for a CRITICAL finding.
reasonNoWhy. Recorded on the audit trail and shown on every matched finding.
rule_idNoWith scope repository_code: the finding's rule id, as get_application_code_security reports it.
expires_atNoReview deadline as an RFC 3339 timestamp; the policy reads as expiring / expired around it.
dispositionYesacknowledged (we know, working on it) or accepted_risk (we will live with it, needs security.manage). With scope repository_code: false_positive (the rule does not apply to this code) or accepted_risk.
occurrence_idNoOccurrence id (UUID) from get_security_finding or list_security_finding_occurrences - the anchor the policy's selector is derived from. Required unless scope is repository_code.
repository_idNoWith scope repository_code: the pipeline repository (UUID). Exactly one of application_id or repository_id.
application_idNoWith scope repository_code: the application (UUID) whose pipeline repository the finding belongs to. Exactly one of application_id or repository_id.
allow_unmatchedNoCreate the policy even when it currently matches no eligible occurrence (default false).
expire_when_fix_availableNoLapse automatically once a fixed version exists (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / application_id
      Added value: +{
+  "description": "With scope repository_code: the application (UUID) whose pipeline repository the finding belongs to. Exactly one of application_id or repository_id.",
+  "type": "string"
+}
    • changedInput schema / properties / disposition / description
      Previous value: -"acknowledged (we know, working on it) or accepted_risk (we will live with it, needs security.manage)."New value: +"acknowledged (we know, working on it) or accepted_risk (we will live with it, needs security.manage). With scope repository_code: false_positive (the rule does not apply to this code) or accepted_risk."
    • changedInput schema / properties / occurrence_id / description
      Previous value: -"Occurrence id (UUID) from get_security_finding or list_security_finding_occurrences - the anchor the policy's selector is derived from."New value: +"Occurrence id (UUID) from get_security_finding or list_security_finding_occurrences - the anchor the policy's selector is derived from. Required unless scope is repository_code."
    • addedInput schema / properties / path
      Added value: +{
+  "description": "With scope repository_code: the file the finding is in, as get_application_code_security reports it (file_path).",
+  "type": "string"
+}
    • addedInput schema / properties / repository_id
      Added value: +{
+  "description": "With scope repository_code: the pipeline repository (UUID). Exactly one of application_id or repository_id.",
+  "type": "string"
+}
    • addedInput schema / properties / rule_id
      Added value: +{
+  "description": "With scope repository_code: the finding's rule id, as get_application_code_security reports it.",
+  "type": "string"
+}
    • changedInput schema / properties / scope / description
      Previous value: -"What the policy is pinned to, with occurrence_id: organisation_addon (the default) pins the add-on the occurrence is attributed to across the organisation and needs a high-confidence add-on attribution; workload pins the one workload (cluster, kind, namespace, name); image pins the image digest wherever it runs. Use workload or image when the occurrence has no add-on attribution (operator-managed pods, plain manifests, control-plane pods, charts outside the catalogue)."New value: +"What the disposition is pinned to. For a cluster vulnerability, with occurrence_id: organisation_addon (the default) pins the add-on the occurrence is attributed to across the organisation and needs a high-confidence add-on attribution; workload pins the one workload (cluster, kind, namespace, name); image pins the image digest wherever it runs. Use workload or image when the occurrence has no add-on attribution (operator-managed pods, plain manifests, control-plane pods, charts outside the catalogue). repository_code is a Semgrep or Checkov finding of a pipeline repository: pass application_id or repository_id, tool, rule_id and path instead of occurrence_id, and the Ankra Pipelines image gate stops blocking on that rule in that file while the disposition is active. Never for a CRITICAL finding."
    • addedInput schema / properties / tool
      Added value: +{
+  "description": "With scope repository_code: semgrep or checkov, the scanner that reported the finding (get_application_code_security).",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "occurrence_id",
-  "disposition"
-]New value: +[
+  "disposition"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false. The description adds far more: refusal conditions (CRITICAL, unmatched, no add-on attribution), the side effect on the pipeline image gate ('the gate stops blocking on that rule in that file'), that the finding 'stays scanned and recorded', audit-trail recording, and reversibility via revoke_security_disposition. This is consistent with destructiveHint=false and adds real behavioral context.

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 the core action, then scenario detail; every sentence carries distinct information (prerequisites, refusals, gate effect, reversal). It is dense and long for a single paragraph, but nothing is filler given the tool's dual-mode complexity.

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 12-parameter mutation with no output schema and no output documentation, the description covers prerequisites, per-scope parameter routing, permission requirements, refusal rules, side effects, and undo. An agent has everything needed to invoke it correctly.

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 100%, so the baseline is 3, and the schema already documents most parameters. The description still adds constraint-level meaning beyond the schema: accepted_risk for repository_code 'needs expires_at within a year', the security.triage vs security.manage permission split, and the 'exactly one of application_id or repository_id' pairing.

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?

Opens with a specific verb+resource: 'Record a disposition for a finding,' then branches into the two concrete modes (cluster vulnerability vs repository_code gate). It names and distinguishes its siblings (preview_security_disposition, revoke_security_disposition) so an agent can route without opening any schema.

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 explicit when-to-use per scope, prerequisites ('run preview_security_disposition first and put its match count in the proposal'), required conditions ('Needs an active occurrence with high-confidence add-on attribution; one without is refused'), and an alternative ('Use this for a reviewed false positive instead of adding an inline nosemgrep'). Exclusions are stated (CRITICAL refused).

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources