secobserve-mcp

Approve SecObserve Assessments

secobserve_approve_observation_log

Approve or reject pending observation assessments in the four-eyes workflow, clearing the 'Needs approval' queue. Rejections require a remark for the submitter.

Instructions

Approve or reject assessments waiting in 'Needs approval' (the four-eyes workflow).

Only an approver other than the submitter can clear a pending assessment, and until it is cleared the observation accepts no further assessment. Rejection requires a remark, which is what the submitter sees.

Args: observation_log_ids (List[int]): 1-250 pending observation log ids. assessment_status (ApprovalStatus): "Approved", "Approved with edits" or "Rejected". rejection_remark (Optional[str]): Required when rejecting. observation_log_comment (Optional[str]): Replacement comment, only with "Approved with edits". observation_log_vex_justification (Optional[VexJustification]): Replacement justification, only with "Approved with edits" and one id.

Returns: str: A confirmation naming the verdict and how many logs it was applied to. Single-id calls use the per-log endpoint, several ids the bulk endpoint.

Examples: - Use when: "approve the pending assessment on log 991" -> observation_log_ids=[991], assessment_status="Approved" - Use when: "reject 991, the justification does not match the evidence" -> assessment_status="Rejected", rejection_remark="..." - Use when: clearing a review queue -> list observation_logs filtered by assessment_status="Needs approval", then pass the ids here. - Don't use when: making the assessment itself (use secobserve_assess_observation).

Error Handling: 403 means the token may not approve, or is the submitter's own -- SecObserve refuses self-approval. 400 means the log is not in 'Needs approval' any more.

Input Schema

TableJSON Schema

Name	Required	Description
`rejection_remark`	No	Why the assessment was rejected. Required when assessment_status is 'Rejected'.
`assessment_status`	Yes	'Approved' accepts the assessment as submitted, 'Approved with edits' accepts it with the observation_log_* overrides below, 'Rejected' discards it.
`observation_log_ids`	Yes	Observation log ids awaiting approval, 1 to 250. Find them with secobserve_list(resource='observation_logs', filters={'assessment_status': 'Needs approval'}).
`observation_log_comment`	No	Replacement comment, only with 'Approved with edits'.
`observation_log_vex_justification`	No	Replacement VEX justification, only with 'Approved with edits' and a single id.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.3.0Sep 20, 2026

removedInput schema / $defs / ApproveInput

Removed value: -{
-  "additionalProperties": false,
-  "description": "Input model for approving or rejecting pending assessments.",
-  "properties": {
-    "assessment_status": {
-      "$ref": "#/$defs/ApprovalStatus",
-      "description": "'Approved' accepts the assessment as submitted, 'Approved with edits' accepts it with the observation_log_* overrides below, 'Rejected' discards it."
-    },
-    "observation_log_comment": {
-      "anyOf": [
-        {
-          "maxLength": 4096,
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Replacement comment, only with 'Approved with edits'.",
-      "title": "Observation Log Comment"
-    },
-    "observation_log_ids": {
-      "description": "Observation log ids awaiting approval, 1 to 250. Find them with secobserve_list(resource='observation_logs', filters={'assessment_status': 'Needs approval'}).",
-      "items": {
-        "type": "integer"
-      },
-      "maxItems": 250,
-      "minItems": 1,
-      "title": "Observation Log Ids",
-      "type": "array"
-    },
-    "observation_log_vex_justification": {
-      "anyOf": [
-        {
-          "$ref": "#/$defs/VexJustification"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Replacement VEX justification, only with 'Approved with edits' and a single id."
-    },
-    "rejection_remark": {
-      "anyOf": [
-        {
-          "maxLength": 255,
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Why the assessment was rejected. Required when assessment_status is 'Rejected'.",
-      "title": "Rejection Remark"
-    }
-  },
-  "required": [
-    "observation_log_ids",
-    "assessment_status"
-  ],
-  "title": "ApproveInput",
-  "type": "object"
-}

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / assessment_status

Added value: +{
+  "$ref": "#/$defs/ApprovalStatus",
+  "description": "'Approved' accepts the assessment as submitted, 'Approved with edits' accepts it with the observation_log_* overrides below, 'Rejected' discards it."
+}

addedInput schema / properties / observation_log_comment

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 4096,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Replacement comment, only with 'Approved with edits'.",
+  "title": "Observation Log Comment"
+}

addedInput schema / properties / observation_log_ids

Added value: +{
+  "description": "Observation log ids awaiting approval, 1 to 250. Find them with secobserve_list(resource='observation_logs', filters={'assessment_status': 'Needs approval'}).",
+  "items": {
+    "type": "integer"
+  },
+  "maxItems": 250,
+  "minItems": 1,
+  "title": "Observation Log Ids",
+  "type": "array"
+}

addedInput schema / properties / observation_log_vex_justification

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/VexJustification"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Replacement VEX justification, only with 'Approved with edits' and a single id."
+}

removedInput schema / properties / params

Removed value: -{
-  "$ref": "#/$defs/ApproveInput"
-}

addedInput schema / properties / rejection_remark

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 255,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Why the assessment was rejected. Required when assessment_status is 'Rejected'.",
+  "title": "Rejection Remark"
+}

changedInput schema / required

Previous value: -[
-  "params"
-]New value: +[
+  "observation_log_ids",
+  "assessment_status"
+]

First observedv0.1.2Sep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond the annotations by explaining self-approval refusal, the requirement of a rejection remark, the fact that a pending assessment accepts no further assessment until cleared, and the single-id vs bulk endpoint behavior. Error handling for 403 and 400 is also disclosed, which is valuable operational context.

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 well-structured with clear sections for behavior, args, returns, examples, and error handling. It is detailed but every section earns its place by providing actionable guidance rather than filler.

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 tool with five parameters, conditional logic, and workflow constraints, the description covers everything needed to invoke it correctly: verdict semantics, conditional parameter requirements, return format, endpoint selection, and failure modes. The output schema and annotations are also present, making the overall context complete.

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 coverage is 100% and the schema descriptions already capture the conditional rules, such as rejection_remark being required only for 'Rejected' and the one-id limitation for observation_log_vex_justification. The description's Args section adds little beyond what the input schema already states, so it does not significantly improve parameter understanding.

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 description opens with a specific verb and resource: 'Approve or reject assessments waiting in Needs approval' in the four-eyes workflow. It clearly distinguishes this tool from secobserve_assess_observation by the explicit 'Don't use when' note, leaving no ambiguity about its role.

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?

The description provides explicit when-to-use guidance, including several concrete natural-language examples and a 'Don't use when' instruction routing to secobserve_assess_observation. It also states the operational prerequisite that only an approver other than the submitter can clear a pending assessment.

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

Deploy Server