Collide MCP

get_briefing

Read-only

Only when no Cork briefing is in your context (Cork'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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_briefing"
  }
}

Input Schema

Name	Required	Description
`days`	No	How far back to look, in days (default 7).
`path`	No	Optional file to also compute the blast radius for.
`depth`	No	Hops of dependents to include with path (default 3).
`symbol`	No	Optional symbol in path to narrow that blast radius.
`repo_id`	No	The repository id, e.g. github.com/org/repo (the Cork briefing names it). Omit it to use the repo your session works in.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / repo_id / description

Previous 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."New value: +"The repository id, e.g. github.com/org/repo (the Cork briefing names it). Omit it to use the repo your session works in."

Changed2 schema fields changedOct 18, 2026

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: +[]

Changed5 schema fields changedSep 27, 2026

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

Changed3 schema fields changedSep 18, 2026
- addedInput schema / properties / depth
```
Added value: +{
+  "type": "integer"
+}
```
- addedInput schema / properties / path
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / symbol
```
Added value: +{
+  "type": "string"
+}
```
Changed6 schema fields changedSep 18, 2026
- 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"
```
First observedSep 17, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context beyond them: the hook-based delivery model, what data classes are returned (summary lines, modules with exact signatures, anchored notes, live agents), and a default 7-day lookback implied by the schema. It does not discuss cost, staleness, or limits of the live-agents data.

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 gating condition is front-loaded in the first clause, which is the right ordering for an agent deciding whether to call. Sentences are dense but each carries information; the return-value enumeration could be trimmed slightly.

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

Completeness4/5

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

No output schema exists, and the description compensates by enumerating what comes back. Combined with the clear call gate and the optional blast-radius path, an agent has enough to invoke it correctly; only edge cases like empty history or missing repo context are 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 100%, so all five parameters are already documented in the schema. The description adds only relational meaning — that path and symbol together drive a blast radius, and that repo_id may be omitted when a briefing names the repo — which is helpful but incremental. Baseline 3 applies.

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?

The description states a specific deliverable: recent repo history (who changed what, renames, hotspots, abandoned work, active agents), optionally extended with blast radius for a path. It is concrete and distinguishable from most siblings, though the mention of blast radius overlaps conceptually with the sibling 'blast_radius' without clarifying the relationship.

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 gate: call only when no Cork briefing is in context because hooks are not installed, and explicitly says not to call it again when the hooks already delivered the briefing. It also describes the optional escalation (pass path/symbol) rather than a separate tool call.

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

All Collide MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?