Skip to main content
Glama

get_briefing

Fetch one consolidated briefing with project context, relevant memories, and last session recap before editing code. Replaces multiple lookups and flags actions requiring confirmation.

Instructions

⭐ DEFAULT-FIRST for coding agents on any repo where hivelore init ran: call this BEFORE changing source or project config for the current goal (unless the developer explicitly opts out). One-shot onboarding: everything relevant in a single call under a token budget.

PROGRESSIVE DISCLOSURE — after this, drill down only if needed: mem_relevant_to / mem_search (compact lists) → mem_get (full body + anchors).

RETURNS (in order of priority): 0. action_required — ⚠️ HANDLE THIS FIRST if non-empty (see protocol below)

  1. last_session — recap of the previous session (goal, what was done, next steps)

  2. project_context — .ai/project-context.md (auto-generated from code-map if template)

  3. module_contexts — relevant .ai/modules//context.md based on files being edited

  4. memories — ranked team memories relevant to your task

  5. symbol_locations — file:line:kind for any requested symbols (no grep needed)

  6. setup_warnings — actionable warnings if setup is incomplete

  7. decay_warnings — memories not read in >90 days (consider reviewing)

⚠️ ACTION_REQUIRED PROTOCOL — MANDATORY: If action_required[] is non-empty, STOP and for each item:

  1. Show the developer the exact developer_message field verbatim

  2. Wait for explicit human confirmation ('yes', 'go ahead', 'oui', etc.)

  3. Only then proceed with any code changes NEVER act autonomously on cross-repo breaking changes, dep bumps, or contract diffs.

KEY PARAMETERS: task — what you are about to do (1–2 sentences) — ALWAYS provide this files — files you are about to edit — surfaces anchored memories symbols — symbol names to look up in the code-map (e.g. ['PaymentService']) format — 'full' (default) | 'compact' (1-line) | 'actions' (bullet-first excerpts) budget_preset — 'quick' | 'balanced' | 'deep' — scales max_tokens/memories/module contexts

EXAMPLE USAGE: get_briefing({ task: 'add a Stripe payment integration', files: ['src/payments/'], symbols: ['PaymentService'] })

CONFIDENCE LEVELS in memories: authoritative — validated + read 10+ times (highest trust) trusted — validated or proposed + read 3+ times low — proposed, few reads (take with caution) unverified — draft (unverified: true flag set)

Replaces 4–5 separate tool calls. Prefer this first; use mem_search / mem_get only for follow-up.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNoWhat you are about to do, in 1–2 sentences. Used to rank relevant memories semantically.
filesNoProject-relative file paths the agent is currently looking at or about to edit
trackNoIncrement read_count on returned memories
formatNoOutput format: 'full' returns memory bodies (honors token budget via truncation); 'compact' returns a 1-line summary per memory (call mem_get for detail); 'actions' squeezes bodies to actionable bullet lines — fewer tokens vs full.full
symbolsNoSymbol names to look up in the code-map (e.g. ['PaymentService', 'TenantFilter']). Returns the file(s) exporting each symbol so agents don't need to grep. Requires `hivelore index code` to have been run.
semanticNoUse semantic ranking when a task is provided (requires `hivelore embeddings index`).
max_tokensNoApproximate token budget for the entire briefing. Each section is allocated a share and truncated to fit.
max_memoriesNoCap on memories surfaced regardless of token budget
budget_presetNoShortcut token budget: 'quick' minimizes tokens/skip module CONTEXT slices; 'balanced' mirrors historical defaults; 'deep' uses a larger briefing. When set, overrides max_tokens, max_memories, and include_module_contexts.
deterministicNoIgnore machine-local usage/impact signals so repeated evaluations rank the shared corpus reproducibly.
include_staleNoInclude stale memories (excluded by default — they may be outdated)
memory_scopesNoRestrict the candidate corpus to selected scopes. Omit to include every scope.
min_semantic_scoreNoFloor for semantic-only memory hits (cosine). The default (0) is not 'keep everything': on a corpus large enough to characterize a distribution, an adaptive floor at the corpus mean+½σ is applied so the undifferentiated mass of weak hits is trimmed while the top hit is always kept. Set an explicit value to raise the bar further; it never lowers the adaptive one. Has no effect on memories matched via anchor/module/literal — those are always kept.
dedupe_project_contextNoToken saver (default ON): skip re-emitting the project-context body if an identical copy was already sent within the last few minutes this session (the agent still has it). Set false to always include it.
include_module_contextsNoInclude the `.ai/modules/<name>/context.md` slices inferred from `files` (default ON). Set false to keep the briefing to project context + memories. Overridden by `budget_preset` when that is set.
include_project_contextNoInclude the `.ai/project-context.md` body (default ON). Set false when the agent already has the project overview and you only want the module/memory layers — see `dedupe_project_context` for the automatic, session-aware version of the same saving.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.57.8
    • changedInput schema / properties / min_semantic_score / description
      Previous value: -"Drop semantic-only memory hits whose cosine score is below this threshold. Useful to avoid weakly-related noise when the task is short or the corpus is broad. Has no effect on memories matched via anchor/module/literal — those are always kept. Try 0.25–0.4 for stricter matching."New value: +"Floor for semantic-only memory hits (cosine). The default (0) is not 'keep everything': on a corpus large enough to characterize a distribution, an adaptive floor at the corpus mean+½σ is applied so the undifferentiated mass of weak hits is trimmed while the top hit is always kept. Set an explicit value to raise the bar further; it never lowers the adaptive one. Has no effect on memories matched via anchor/module/literal — those are always kept."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses the priority-ordered return sections, the mandatory STOP-and-wait action protocol, confidence levels, token-budget truncation behavior, and that memory read counts can be incremented via the track parameter. It also warns about cross-repo breaking changes and contract diffs.

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 long but well-structured with clear sections, priority numbering, and a front-loaded core directive. Some redundancy exists—'Replaces 4–5 separate tool calls' echoes the opening 'one-shot onboarding,' and 'KEY PARAMETERS' largely repeats schema fields—so not every sentence earns maximum credit, but the organization mitigates the length.

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 absence of an output schema, the description makes the return contract explicit by enumerating all result sections in priority order and explaining the action_required protocol. It also provides invocation guidance, parameter semantics, example usage, and confidence-level interpretation. Nothing essential for correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful usage nuance beyond the schema by explaining task should 'ALWAYS' be provided, files surface anchored memories, symbols eliminate grep, and budget_preset scales tokens/memories/module contexts. It does not cover every parameter in prose, but the schema already documents them thoroughly.

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 states a specific verb and resource: a one-shot onboarding/briefing tool to call before changing source or project config. It explicitly distinguishes itself from siblings by positioning mem_search/mem_get as follow-up tools and mem_relevant_to/mem_search as drill-down alternatives.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance ('call this BEFORE changing source or project config'), when-not-to-use guidance ('unless the developer explicitly opts out'), and names alternatives ('use mem_search / mem_get only for follow-up'). The mandatory action_required protocol also tells the agent exactly how to behave when the response demands it.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Doucs91/hivelore'

If you have feedback or need assistance with the MCP directory API, please join our Discord server