secobserve-mcp

List SecObserve Resources

secobserve_list_resources

Read-onlyIdempotent

List all SecObserve resources this server can reach, with their operations and named actions. Use this static catalogue as the starting point to choose the right resource for any SecObserve task.

Instructions

List every SecObserve resource this server can reach, with its verbs and named actions.

Start here. The output is the vocabulary for secobserve_list / get / create / update / delete / call_action. It is served from a static catalogue and makes no API call, so it is free to call first.

Args: contains (Optional[str]): Substring filter on resource name and summary.

Returns: str: Markdown, one section per resource: "## " then the API path, supported operations (list/get/create/update/delete), a one-line summary, the default list projection, and each named action with its verb and detail level.

Examples: - Use when: starting any SecObserve task and you need the resource names. - Use when: "what can I do with license policies?" -> contains="license" - Don't use when: you need exact filter names or field types (use secobserve_describe_resource, which reads the live schema).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`contains`	No	Only list resources whose name or summary contains this text (e.g. 'license', 'vex').

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.0Sep 20, 2026

removedInput schema / $defs

Removed value: -{
-  "ListResourcesInput": {
-    "additionalProperties": false,
-    "description": "Input model for browsing the resource catalogue.",
-    "properties": {
-      "contains": {
-        "anyOf": [
-          {
-            "maxLength": 100,
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Only list resources whose name or summary contains this text (e.g. 'license', 'vex').",
-        "title": "Contains"
-      }
-    },
-    "title": "ListResourcesInput",
-    "type": "object"
-  }
-}

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

addedInput schema / properties / contains

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only list resources whose name or summary contains this text (e.g. 'license', 'vex').",
+  "title": "Contains"
+}

removedInput schema / properties / params

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

removedInput schema / required
```
Removed value: -[
-  "params"
-]
```

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 reveals an important behavioral trait beyond the annotations: 'It is served from a static catalogue and makes no API call, so it is free to call first.' This adds guaranteed-no-side-effect context beyond the readOnlyHint and idempotentHint annotations. It also fully describes the return format as Markdown sections, which is useful behavioral detail. No contradiction with annotations exists.

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: purpose, start-here guidance, args, returns, and examples. The key statement is front-loaded, and every sentence adds useful information about when and how to use the tool. There is no filler or redundant marketing text.

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 single-parameter, metadata-discovery tool, the description is complete. It explains what the tool returns, how to filter, when to use it, when not to use it, which alternative to choose instead, and that it makes no API call. The presence of an output schema further reduces the need to document return structure, yet the description still provides an overview of it.

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?

The input schema already documents 'contains' with a description and examples, so schema coverage is 100%. The description mostly restates the parameter as 'Substring filter on resource name and summary' and includes an example ('contains="license"'), but it does not add substantial semantics beyond the schema. This meets the baseline, but no more.

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 states a specific action: 'List every SecObserve resource this server can reach, with its verbs and named actions.' It clearly names the resource (SecObserve resources), the scope (every resource the server can reach), and what is included (verbs and named actions). It also distinguishes itself from secobserve_describe_resource in the examples, so an agent can tell them apart.

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 practical. It says 'Start here' and 'free to call first', gives concrete 'Use when' examples, and states 'Don't use when: you need exact filter names or field types' while directing to secobserve_describe_resource. This fully routes an agent to the correct tool for each situation.

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

Deploy Server