secobserve-mcp

Assess SecObserve Observation

secobserve_assess_observation

Triage a single security observation by recording a human assessment: change severity, status, priority, or VEX justification with a mandatory comment and audit trail.

Instructions

Record a human assessment on one observation: change its severity, status, priority or VEX justification.

This is how triage is done. It writes an observation log, so the change is attributable and reversible, and it is what later VEX documents are generated from. Never edit an observation's severity or status with secobserve_update -- that bypasses the log and the approval workflow.

Two rules the API enforces: a comment is mandatory, and a new assessment is refused while the previous one is still in 'Needs approval'.

Args: params (AssessObservationInput): Validated input containing: - observation_id (int): Observation to assess. - severity (Optional[Severity]): Unknown/None/Low/Medium/High/Critical. - status (Optional[Status]): Open/Affected/Resolved/Duplicate/False positive/ In review/Not affected/Not security/Risk accepted. - priority (Optional[int]): 1-99, or null to clear. - vex_justification (Optional[VexJustification]): Machine-readable reason, expected with 'Not affected' and 'False positive'. - risk_acceptance_expiry_date (Optional[str]): YYYY-MM-DD, for 'Risk accepted'. - comment (str): Mandatory rationale, 1-4096 characters.

Returns: str: A confirmation line naming the observation and the fields changed, plus a note when the instance's four-eyes setting leaves the assessment in 'Needs approval' (the API returns an empty body on success).

Examples: - Use when: "mark 8123 as not affected, the vulnerable function is never called" -> observation_id=8123, status="Not affected", vex_justification="vulnerable_code_not_in_execute_path", comment="..." - Use when: "accept the risk on 8123 until the end of the quarter" -> status="Risk accepted", risk_acceptance_expiry_date="2026-12-31", comment="..." - Don't use when: assessing many findings the same way (use secobserve_bulk_assess_observations). - Don't use when: approving someone else's assessment (use secobserve_approve_observation_log).

Error Handling: 400 "Cannot create new assessment while last assessment still needs approval" means the previous assessment must be approved or rejected first. 403 means the token lacks Observation_Assessment on that product. The schema refuses a call that would change nothing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Sep 17, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description goes far beyond: it discloses that the tool writes an observation log, changes are attributable and reversible, a comment is mandatory, a new assessment is refused while the previous one is in 'Needs approval,' and the API returns an empty body on success. It also explains 400 and 403 error semantics, which are not available in annotations.

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 relatively long but tightly organized into purpose, rules, args, returns, examples, and error handling. The first sentence delivers the core purpose, and every subsequent section earns its place by providing operational detail that an agent needs to invoke the tool correctly. No filler or tautology is present.

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?

Given the tool's complexity—many optional fields, approval workflow, permission requirements, and multiple sibling tools—the description is complete. It covers return behavior (including the empty-body caveat), error cases, prerequisites, and alternative tools. The output schema exists, so the description appropriately explains what the returned string contains rather than duplicating a full return contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already contains per-property descriptions, the tool description reinforces and extends them. It explains what each parameter is for, lists expected values, and adds conditional logic: vex_justification is expected with 'Not affected' and 'False positive,' risk_acceptance_expiry_date is for 'Risk accepted,' and priority can be null to clear. The examples translate natural-language requests into concrete parameter values.

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: 'Record a human assessment on one observation: change its severity, status, priority or VEX justification.' It also distinguishes itself from siblings by explicitly naming secobserve_update, secobserve_bulk_assess_observations, and secobserve_approve_observation_log, so an agent can tell exactly which tool to pick.

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?

Usage guidance is explicit and actionable. It states 'This is how triage is done,' warns never to use secobserve_update because it bypasses the log and approval workflow, and provides 'Don't use when' directives for bulk assessment and approval. Examples show concrete 'Use when' scenarios, making the selection criteria unambiguous.

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

Deploy Server