briefd

Overview Schema Source Related Servers Discussions Admin

compile_bundle

Read-onlyIdempotent

Compile team knowledge, conventions, and past decisions into a token-budgeted context block before coding; describe the task in a sentence to get deduplicated, sourced sections.

Instructions

Compile what the team's knowledge base says about a task into one context block within a token budget. Call it once at the start of a task, before code that rules, conventions or past decisions could govern; describe the task in a sentence, not keywords. Sections are deduplicated, ordered domain → conventions → project, each with a source line (path, heading, last-updated date, and a note when the code it governs changed later). Read-only, deterministic, cached: same task, scopes and budget give the same bundle_id and content. Never exceeds max_tokens; a too-small budget truncates the top section with a marker. Afterwards, report which sections helped via report_usage.

Input Schema

TableJSON Schema

Name	Required	Description
`paths`	No	Repository-relative code paths the task touches (e.g. ["services/payment/refund.go"]). Rules whose refs cover them come first in the bundle.
`scopes`	No	Knowledge scopes to draw from, e.g. ["domain","conventions","projects/ledger-service"]. Default: domain and conventions. Add the project scope when working inside a project.
`max_tokens`	No	Token budget for the whole bundle including its header and source lines (default 2000, must be positive). Never exceeded.
`task_description`	Yes	What you are about to do, in one or two sentences, in any language (e.g. 'add partial refunds to the merchant portal'). Required; a sentence retrieves better than keywords.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`budget`	Yes
`cached`	Yes
`scopes`	Yes
`tokens`	Yes
`content`	Yes
`sections`	Yes
`bundle_id`	Yes
`truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.0Sep 23, 2026

addedInput schema / properties / paths

Added value: +{
+  "description": "Repository-relative code paths the task touches (e.g. [\"services/payment/refund.go\"]). Rules whose refs cover them come first in the bundle.",
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

Changed3 schema fields changedv0.5.0Sep 22, 2026

changedInput schema / properties / max_tokens / description

Previous value: -"Token budget for the whole bundle (default 2000). Never exceeded."New value: +"Token budget for the whole bundle including its header and source lines (default 2000, must be positive). Never exceeded."

changedInput schema / properties / scopes / description

Previous value: -"Knowledge scopes to draw from. Default: domain and conventions."New value: +"Knowledge scopes to draw from, e.g. [\"domain\",\"conventions\",\"projects/ledger-service\"]. Default: domain and conventions. Add the project scope when working inside a project."

changedInput schema / properties / task_description / description

Previous value: -"What you are about to do, in one or two sentences (e.g. 'add partial refunds to the merchant portal')"New value: +"What you are about to do, in one or two sentences, in any language (e.g. 'add partial refunds to the merchant portal'). Required; a sentence retrieves better than keywords."

First observedv0.4.0Sep 21, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, it discloses deterministic caching (same inputs yield same bundle_id/content), never exceeding max_tokens, truncation with a marker, deduplication, and section ordering (domain → conventions → project) with source line details. These are not captured in annotations, adding substantial behavioral context.

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 about 100 words but every sentence earns its place: purpose, usage timing, section structure, determinism/caching, budget behavior, and follow-up. It is front-loaded with the core purpose and usage, then covers behavioral details efficiently without redundancy.

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 output schema exists, the description appropriately omits return structure details. It covers usage timing, ordering, dedup, budget constraints, truncation behavior, and follow-up via report_usage, making it complete for an agent to call correctly in a variety of task scenarios.

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 description coverage is 100% for all four parameters, so the schema already documents each. The description adds only a minor note that task_description should be a sentence rather than keywords, which slightly enhances the schema's generic description but does not add meaning for paths, scopes, or max_tokens beyond what is already present.

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 clearly states a specific verb ('Compile') and resource ('what the team's knowledge base says about a task') with a concrete output ('one context block within a token budget'). It distinguishes itself from siblings by its one-time, compilation role at task start, rather than a search or retrieval function.

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 explicitly instructs to call once at the start of a task, before code that rules/conventions could govern, and to describe the task in a sentence. It also directs follow-up via report_usage. It does not explicitly name alternative tools like search_context, but the timing and purpose are clear enough to infer when to use it.

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

Deploy Server