brindley

Overview Schema Source Related Servers Discussions Admin

create_collection

Instructions

Mark a folder as a collection: adds brindley: 1 and the given details to its README.md front-matter, creating the folder and README if needed. Works on a folder that already holds numbered initiative files. The first collection in a repo also returns the agent-instructions snippet for AGENTS.md / CLAUDE.md.

Input Schema

Name	Required	Description
`docs`	No	Globs of project docs this collection usually affects
`link`	No	External ticket/epic URL
`name`	No	Name used in references (name#n); defaults to the folder name
`path`	Yes	Folder relative to the repo root, e.g. "docs/initiatives/LOCK-42/slot-booking"
`tags`	No	Tags (themes) with one-line descriptions
`agent`	No	Repo workflow agent file for this collection
`graph`	No	Dependency graph settings: direction, arrows, related, show, external, themes, enabled. null removes.
`owner`	No
`title`	No
`types`	No	Initiative types this collection uses; others are flagged
`ignore`	No	Paths or globs relative to the collection folder to ignore, e.g. ["code-review/", "completed/24-*-rationale.md"]
`aliases`	No	Short names for references, e.g. ["lgm"] for "lgm#22"
`columns`	No	README table columns: { active: [...], completed: [...] }. null removes.
`folders`	No	Opt in to status folders: status → folder name, e.g. { done: done }. Status changes then move files; run tidy for existing ones. null removes (files stay where they are).
`summary`	No
`statuses`	No	This collection's own status words mapped to core statuses
`dimensions`	No	Scoring dimensions: name → { values (first ranks first), required?, default? } or a list of values. null removes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv2.6.0Oct 13, 2026

addedInput schema / properties / aliases

Added value: +{
+  "description": "Short names for references, e.g. [\"lgm\"] for \"lgm#22\"",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / columns

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "README table columns: { active: [...], completed: [...] }. null removes."
+}

addedInput schema / properties / dimensions

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Scoring dimensions: name → { values (first ranks first), required?, default? } or a list of values. null removes."
+}

addedInput schema / properties / folders

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Opt in to status folders: status → folder name, e.g. { done: done }. Status changes then move files; run tidy for existing ones. null removes (files stay where they are)."
+}

addedInput schema / properties / graph

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Dependency graph settings: direction, arrows, related, show, external, themes, enabled. null removes."
+}

addedInput schema / properties / ignore

Added value: +{
+  "description": "Paths or globs relative to the collection folder to ignore, e.g. [\"code-review/\", \"completed/24-*-rationale.md\"]",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / name / description

Previous value: -"Short name used in references (name#n); defaults to the folder name"New value: +"Name used in references (name#n); defaults to the folder name"

addedInput schema / properties / statuses

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "This collection's own status words mapped to core statuses",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 6, 2026

TDQS

A3.6/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 load and does a good job: it discloses the mutation target (README.md front-matter), the creation side effect ('creating the folder and README if needed'), and a conditional output behavior (agent-instructions snippet on the first collection in a repo). It omits idempotency and what happens if the folder is already a collection, which is the main remaining gap.

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?

Three sentences, front-loaded with the core mutation and its target, then the precondition and the conditional return. Every sentence carries information; sizing is appropriate for the complexity.

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

Completeness3/5

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

For a 17-parameter, nested-object creation tool with no output schema and no annotations, the description covers the central write behavior and one noteworthy return case, but leaves error/idempotency behavior and the relationship to sibling tools like update_collection unaddressed.

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 coverage is 82%, so the schema already documents nearly all 17 parameters in detail. The description references 'the given details' generically and adds no per-parameter meaning beyond what the schema fields already state, which matches the baseline-3 case when structured data does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Mark a folder as a collection') and describes the exact mechanism: writing `brindley: 1` plus details into README.md front-matter. It is distinct from a generic 'create', though it never explicitly names which sibling to prefer for modification (e.g., update_collection) or for creating initiative files.

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

Usage Guidelines3/5

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

Provides one precondition -- 'Works on a folder that already holds numbered initiative files' -- which implies when the tool applies, but offers no explicit when-not guidance and does not point to alternatives like update_collection or rename_collection for an existing collection.

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

create_collection

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools