secobserve-mcp

Update SecObserve Record

secobserve_update

Idempotent

Update a SecObserve resource record by changing specified fields. PATCH merges changed fields; PUT replaces and blanks omitted fields for full control.

Instructions

Change fields of an existing SecObserve record.

Defaults to PATCH so omitted fields keep their values; set replace=True only when you intend PUT semantics, which blanks anything you leave out.

To change an observation's severity, status or priority, do NOT use this tool -- use secobserve_assess_observation, which writes an observation log, honours the approval workflow and keeps the audit trail intact.

Args: resource (str): Resource name supporting update. id (int): Primary key of the record. data (dict): Fields to change. replace (bool): False = PATCH (default), True = PUT. response_format (ResponseFormat): "markdown" or "json".

Returns: str: The updated record as markdown or JSON.

Examples: - Use when: "disable general rule 4" -> resource="general_rules", id=4, data={"enabled": False} - Use when: "point product 12 at license policy 3" -> resource="products", id=12, data={"license_policy": 3} - Don't use when: assessing an observation (use secobserve_assess_observation).

Error Handling: Refused when the resource has no update operation or the server is read-only. 400 responses carry the API's field-level validation detail.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Numeric primary key of the record to update.
`data`	Yes	Fields to change.
`replace`	No	False sends PATCH (merge, the safe default). True sends PUT and blanks omitted fields.
`resource`	Yes	Resource name that supports update.
`response_format`	No	'markdown' for reading, 'json' for further processing.	markdown

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 / UpdateInput

Removed value: -{
-  "additionalProperties": false,
-  "description": "Input model for updating a record.",
-  "properties": {
-    "data": {
-      "additionalProperties": true,
-      "description": "Fields to change.",
-      "title": "Data",
-      "type": "object"
-    },
-    "id": {
-      "description": "Numeric primary key of the record to update.",
-      "minimum": 1,
-      "title": "Id",
-      "type": "integer"
-    },
-    "replace": {
-      "default": false,
-      "description": "False sends PATCH (merge, the safe default). True sends PUT and blanks omitted fields.",
-      "title": "Replace",
-      "type": "boolean"
-    },
-    "resource": {
-      "description": "Resource name that supports update.",
-      "title": "Resource",
-      "type": "string"
-    },
-    "response_format": {
-      "$ref": "#/$defs/ResponseFormat",
-      "default": "markdown",
-      "description": "Output format."
-    }
-  },
-  "required": [
-    "resource",
-    "id",
-    "data"
-  ],
-  "title": "UpdateInput",
-  "type": "object"
-}

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

addedInput schema / properties / data

Added value: +{
+  "additionalProperties": true,
+  "description": "Fields to change.",
+  "title": "Data",
+  "type": "object"
+}

addedInput schema / properties / id

Added value: +{
+  "description": "Numeric primary key of the record to update.",
+  "minimum": 1,
+  "title": "Id",
+  "type": "integer"
+}

removedInput schema / properties / params

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

addedInput schema / properties / replace

Added value: +{
+  "default": false,
+  "description": "False sends PATCH (merge, the safe default). True sends PUT and blanks omitted fields.",
+  "title": "Replace",
+  "type": "boolean"
+}

addedInput schema / properties / resource

Added value: +{
+  "description": "Resource name that supports update.",
+  "title": "Resource",
+  "type": "string"
+}

addedInput schema / properties / response_format

Added value: +{
+  "$ref": "#/$defs/ResponseFormat",
+  "default": "markdown",
+  "description": "'markdown' for reading, 'json' for further processing."
+}

changedInput schema / required

Previous value: -[
-  "params"
-]New value: +[
+  "resource",
+  "id",
+  "data"
+]

First observedv0.1.2Sep 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Explains the default PATCH semantics, the data-blanking risk of replace=True, refusal on read-only servers/resources without update support, and 400 validation behavior. These go well beyond the annotations and make runtime behavior predictable.

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?

Well-structured with Args, Returns, Examples, and Error Handling sections, and key behavioral guidance is front-loaded. Slight redundancy between the 'do NOT use' paragraph and the Don't use example keeps it from a perfect 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 generic update tool with a free-form data dict, it covers the essential call flow: required args, PATCH/PUT choice, response format, error cases, and sibling routing. The output schema handles return details, so nothing critical is missing.

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 description coverage is 100%, and the Args block largely restates the schema. It adds only stylistic consolidation (PATCH vs PUT and markdown/json intent), not meaning beyond the schema, so baseline 3 is appropriate.

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+object ('Change fields of an existing SecObserve record'), immediately distinguishing update from create/delete. The later note that observation severity/status changes belong to secobserve_assess_observation further sharpens scope against a key sibling.

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?

Explicitly states when not to use the tool ('do NOT use this tool -- use secobserve_assess_observation') and gives concrete Use when / Don't use when examples with exact resource/id/data arguments. This leaves no ambiguity about the intended call context.

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

Deploy Server