secobserve-mcp

Create SecObserve Record

secobserve_create

Create SecObserve records such as products, branches, services, rules, policies, or members. Describe the resource first to learn required fields, then submit the data for the new record.

Instructions

Create a record in SecObserve (product, branch, service, rule, policy, member, ...).

Call secobserve_describe_resource for the resource first: SecObserve's serializers reject unknown fields and enforce enums, and its 400 bodies name the offending field.

Args: params (CreateInput): Validated input containing: - resource (str): Resource name supporting create. - data (dict): Request body. - response_format (ResponseFormat): "markdown" or "json".

Returns: str: The created record, including its new "id", as markdown or JSON.

Examples: - Use when: "add branch 'release-2.1' to product 12" -> resource="branches", data={"product": 12, "name": "release-2.1"} - Use when: "give user 7 the Writer role on product 12" -> resource="product_members", data={"product": 12, "user": 7, "role": "Writer"} - Don't use when: importing scanner findings (use secobserve_import_scan_file or secobserve_api_import -- creating observations by hand bypasses deduplication and rules).

Error Handling: Refused with a clear message when the resource has no create operation, or when SECOBSERVE_READ_ONLY is set. 400 responses are returned with the field-level detail from the API.

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

A4.8/5.0

Behavior5/5

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

Beyond annotations, it discloses that invalid create requests will be rejected with 400 bodies naming the offending field, that unsupported resources or SECOBSERVE_READ_ONLY will cause refusal, and that creating observations by hand bypasses deduplication and rules. It does not contradict annotations; readOnlyHint=false is consistent with a creation operation.

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?

Structured into purpose, prerequisite, args, returns, examples, and error handling, with major facts front-loaded. The Args section partly restates the schema, but the examples and 'Don't use when' section earn their length.

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 create tool covering many resource types, it is complete: it names prerequisites, return shape, error behavior, and when not to use it, and the output schema covers response structure. The instruction to call describe_resource fills the otherwise open-ended data-field requirement.

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?

The description explains the meaning of resource, data, and response_format with examples and emphasizes validating via describe_resource first, compensating for the low schema coverage. The schema's own descriptions are thin, so the examples and error-handling note add genuine value, though the complete set of valid resource names is still left to discovery.

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?

States it creates a record in SecObserve and lists the resource categories, with concrete examples for branches and product_members. The 'Don't use when' clause clearly differentiates it from import siblings, so an agent can distinguish it from secobserve_update/get/delete/import tools.

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 instructions to call secobserve_describe_resource first, because serializers reject unknown fields and enforce enums. It provides positive use examples and a negative example routing scanner-finding imports to secobserve_import_scan_file or secobserve_api_import, so alternatives are named.

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

Deploy Server