Skip to main content
Glama

Collide MCP

by com.collidemcp.api
OverviewDiscussionsAdmin

get_briefing

Read-only

Only when no Collide briefing is in your context (Collide's hooks are not installed): the recent history of this repo — who changed what, renames to adapt to, hotspots, abandoned work and who is working right now. Where the hooks run, the same briefing already arrived with your prompt; do not call this again for it. Pass path (and symbol) to also get the blast radius of what you are about to change. Read-only. Returns summary lines, changed modules with exact signatures, anchored notes and live agents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far back to look, in days (default 7).
pathNoOptional file to also compute the blast radius for.
depthNoHops of dependents to include with path (default 3).
symbolNoOptional symbol in path to narrow that blast radius.
repo_idNoThe repository id, e.g. github.com/org/repo (the Collide briefing names it). Omit it to use the repo your session works in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / repo_id / description
      Previous value: -"The repository id, e.g. github.com/org/repo (repo_id in .collide/config.json)."New value: +"The repository id, e.g. github.com/org/repo (the Collide briefing names it). Omit it to use the repo your session works in."
    • changedInput schema / required
      Previous value: -[
-  "repo_id"
-]New value: +[]
  2. Changed5 schema fields changed
    • addedInput schema / properties / days / description
      Added value: +"How far back to look, in days (default 7)."
    • addedInput schema / properties / depth / description
      Added value: +"Hops of dependents to include with path (default 3)."
    • addedInput schema / properties / path / description
      Added value: +"Optional file to also compute the blast radius for."
    • addedInput schema / properties / repo_id / description
      Added value: +"The repository id, e.g. github.com/org/repo (repo_id in .collide/config.json)."
    • addedInput schema / properties / symbol / description
      Added value: +"Optional symbol in path to narrow that blast radius."
  3. Changed3 schema fields changed
    • addedInput schema / properties / depth
      Added value: +{
+  "type": "integer"
+}
    • addedInput schema / properties / path
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / symbol
      Added value: +{
+  "type": "string"
+}
  4. Changed6 schema fields changed
    • removedInput schema / properties / days / default
      Removed value: -7
    • removedInput schema / properties / days / description
      Removed value: -"How many days of history to include."
    • removedInput schema / properties / days / title
      Removed value: -"Days"
    • removedInput schema / properties / repo_id / description
      Removed value: -"Repository id — the git remote (e.g. github.com/acme/api) or a bare folder name; a #branch suffix scopes to that branch."
    • removedInput schema / properties / repo_id / title
      Removed value: -"Repo Id"
    • removedInput schema / title
      Removed value: -"get_briefingArguments"
  5. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already carry readOnlyHint/destructiveHint, so the explicit 'Read-only' is largely redundant, but the description adds genuine behavioral context: the hook-deduplication rule, what the response contains, and the fact that supplying path/symbol expands the result into a blast-radius computation.

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 conditional constraint is front-loaded and every sentence carries information, but the description is dense and the trailing return-value list is slightly listy where a shorter clause would do. No wasted filler, though.

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?

With no output schema, the description compensates by naming the return contents (summary lines, changed modules with exact signatures, anchored notes, live agents), and it covers usage gating, parameter behavior, and safety in one place. An agent has everything needed to call it correctly.

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 baseline is 3; the description goes beyond it by explaining the path+symbol combination semantics (symbol narrows the blast radius within path) and the purpose of repo_id's omission default, which the schema only partially conveys.

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?

States a specific verb+resource (get the briefing = recent repo history) and enumerates its contents (who changed what, renames, hotspots, abandoned work, live agents). It is clearly distinguishable from siblings like recap/recall and even notes its overlap with blast_radius.

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?

Gives an explicit gating condition ('Only when no Collide briefing is in your context') plus an explicit when-not ('Where the hooks run... do not call this again for it'), and points to the path/symbol route for blast-radius work instead. Nothing about when to invoke is left to inference.

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

All Collide MCP toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources