Slipbox MCP Server

Overview Schema Source Related Servers Discussions Admin

slipbox_get_cluster_report

Identify note clusters missing structure notes by score, using cached analysis or forcing refresh. Returns high-priority clusters for creating structure notes.

Instructions

Get pending cluster analysis for structure note creation.

Clusters are groups of notes sharing tags but lacking a structure note. High-scoring clusters are good candidates for new structure notes.

Uses cached analysis by default. Set refresh=true to regenerate. Cluster analysis runs automatically via cron if configured.

Scoring factors:

Note count (7-15 is ideal, >15 is overdue)
Orphan ratio (more orphans = more urgent)
Internal link density (fewer links = needs structure)
Recency (recent activity = active domain)

Args: min_score: Minimum cluster score 0.0-1.0 (default: 0.5) limit: Maximum clusters to return (default: 5) include_notes: Include full note list per cluster (default: false) refresh: Force regeneration of cluster analysis (default: false)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`refresh`	No
`min_score`	No
`include_notes`	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_get_cluster_reportOutput",
+  "type": "object"
+}

First observedv0.1.0Aug 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses caching (default) and refresh behavior, automatic cron execution, and the scoring factors that influence results. It does not explicitly state that the operation is read-only (aside from the word 'get'), nor does it mention any auth or rate-limit requirements. Still, the disclosure of caching, refresh side effects, and scoring logic goes well beyond the schema, so a 4 is appropriate.

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 description is well-structured: a one-sentence purpose, a brief explanation, a bulleted list of scoring factors, and a clear Args block. It is not bloated, but the scoring factors could arguably be moved to a separate section without harming clarity. It is front-loaded with the core purpose, so it earns a 4.

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 presence of an output schema (which covers return values) and the fact that all four parameters are fully explained in the description, the tool is complete. The description covers purpose, behavior, scoring, and parameter semantics. No critical missing pieces like error handling or timeouts are necessary because the output schema and the tool's simple nature make them non-essential.

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 description coverage is 0%, so the description must fully compensate. It does: the 'Args' section explains each parameter with meaning and range (min_score 0.0-1.0), behavior (limit max clusters), and implications (include_notes, refresh). This adds significant value beyond the bare schema types and defaults, making it clear how each parameter affects the result.

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 clear, specific statement: 'Get pending cluster analysis for structure note creation.' It then explains what clusters are and how they relate to structure notes, distinguishing this tool from siblings like slipbox_refresh_clusters and slipbox_create_structure_from_cluster. The verb 'get' and the resource 'cluster analysis' are unambiguous.

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?

The description provides strong contextual guidance: it explains that high-scoring clusters are candidates for structure notes, and mentions the caching behavior and automatic cron runs. However, it does not explicitly compare this tool to siblings like slipbox_refresh_clusters or slipbox_dismiss_cluster, nor does it state when to use an alternative. The guidance is implied rather than explicit, so it earns a 4 rather than a 5.

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