briefd

Overview Schema Source Related Servers Discussions Admin

compile_bundle

Read-onlyIdempotent

Compile relevant team knowledge, conventions, and project context into a token-budgeted bundle before coding. Give a task sentence to get deduplicated, sourced sections within max_tokens.

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
`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.

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.7/5.0

Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations by disclosing deterministic caching, identical bundle_id for identical inputs, strict max_tokens enforcement, truncation with a marker, deduplication, section ordering, and source-line details. This is a model behavioral disclosure.

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 dense but every sentence earns its place: purpose, usage timing, section structure, caching behavior, budget handling, and follow-up reporting. The main action is front-loaded, with no filler or repetition.

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 and the description covers purpose, timing, parameter semantics, behavior, and lifecycle follow-up, an agent has everything needed to invoke this tool correctly. The only minor gap is not routing to search_context for raw retrieval, but that does not undermine completeness for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful operational guidance: default scopes, when to add a project scope, the sentence-not-keywords instruction for task_description, and budget behavior tied to max_tokens.

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: compiling what the team's knowledge base says about a task into a single context block. It clearly distinguishes this from simple retrieval tools by describing synthesis, section ordering, and source lines.

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 explicit timing guidance: call once at the start of a task, before code that rules/conventions could govern, and describe the task in a sentence. It also recommends using report_usage afterward. It does not explicitly name a sibling alternative like search_context for raw retrieval, so it stops short of a 5.

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

Deploy Server