Slipbox MCP Server

Overview Schema Source Related Servers Discussions Admin

slipbox_create_structure_from_cluster

Generate a structure note for a detected cluster, organizing all member notes with bidirectional links to create a navigable overview.

Instructions

Create a structure note from a detected cluster.

Generates a structure note organizing all notes in the cluster, with bidirectional links to each member note.

Run slipbox_get_cluster_report first to see available clusters and their IDs.

Args: cluster_id: ID from cluster report (e.g. "jackson-mac-low-chance-operations") title: Override the suggested title (optional) create_links: Create bidirectional links to member notes (default: true)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`title`	No
`cluster_id`	Yes
`create_links`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.5.4Sep 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "slipbox_create_structure_from_clusterOutput",
+  "type": "object"
+}

First observedv0.1.0Aug 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations exist, so the description carries the behavioral burden. It discloses that the tool generates a structure note, organizes all member notes, and creates bidirectional links, and it notes the default create_links behavior in Args. It does not discuss failure modes or side effects on the cluster state, but for a creation operation the core behavior is transparent enough.

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?

The purpose is front-loaded, the prerequisite is in a short sentence, and the Args section is scannable. There is minor redundancy between the opening sentence and 'Generates a structure note...', but the added detail about bidirectional links earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the agent does not need the description to explain return values. The description covers the prerequisite, the behavior, and all parameters, which is sufficient for a 3-parameter creation tool with no nested objects. It does not address potential errors like invalid cluster IDs, but that is a minor gap.

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?

Schema coverage is 0%, so the description must explain all parameters. It does: cluster_id is defined as an ID from the cluster report with a concrete example, title is an optional override of the suggested title, and create_links is explained with its default true. This fully compensates for the empty schema descriptions.

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: 'Create a structure note from a detected cluster.' It further clarifies that it organizes all notes in the cluster and creates bidirectional links, which distinguishes it from generic slipbox_create_note and from cluster-management siblings like slipbox_dismiss_cluster.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete prerequisite: 'Run slipbox_get_cluster_report first to see available clusters and their IDs.' This tells an agent when in the workflow to call the tool. It does not explicitly state when not to use it or name alternatives, so it falls short of full routing guidance.

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