Skip to main content
Glama
Sign In

Collide MCP

by com.collidemcp.api
OverviewDiscussionsAdmin

setup

Set up Cork on this machine, once for every repo on it. The answer has install.command: run it exactly as given, in a shell at the repo root. It installs Cork's hooks for Claude Code, Codex, Cursor and Hermes, links the machine to your account, and writes nothing into the repo; if the repo still has Cork's old per-repo setup (.collide/ hook files), it removes that and stages the removal for you to commit. Returns the command and what it installs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo_id": "<repo_id>"
    },
    "name": "setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoIgnored: kept for older callers. The machine's hooks always gate writes.
repo_idYesThe repository id, e.g. github.com/org/repo (its git origin).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"enforce (default: the pre-write gate is on), advisory (reporting only), or files (skip the command and return the files)."New value: +"Ignored: kept for older callers. The machine's hooks always gate writes."
    • 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 (its git origin)."
  2. Changed2 schema fields changed
    • addedInput schema / properties / mode / description
      Added value: +"enforce (default: the pre-write gate is on), advisory (reporting only), or files (skip the command and return the files)."
    • addedInput schema / properties / repo_id / description
      Added value: +"The repository id, e.g. github.com/org/repo (repo_id in .collide/config.json)."
  3. Added
  4. Removed
  5. Changed6 schema fields changed
    • removedInput schema / properties / mode / default
      Removed value: -"enforce"
    • removedInput schema / properties / mode / description
      Removed value: -"enforce (block the write on a certain collision) or advise (never block)."
    • removedInput schema / properties / mode / title
      Removed value: -"Mode"
    • 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: -"setupArguments"
  6. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare not readOnly, not destructive, closed-world, so the safety profile is already given; the description adds real behavior beyond that: it returns a command rather than performing the install, it links the machine to the user's account (an auth/identity side effect), it writes nothing into the repo, and it deletes legacy .collide/ hook files while leaving the removal staged for the user to commit. The non-destructive hint is compatible with that staged removal, so no contradiction. It does not say what happens if the repo id is unknown or setup has already run.

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?

Front-loads the action and the key instruction (run the returned command exactly as given, at the repo root) before the inventory of side effects. Dense but all sentences carry information; the side-effect list could be broken into a short list to be more scannable, and the closing 'Returns the command and what it installs' partly repeats the opening.

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?

For a two-parameter setup tool with no output schema, the description covers what the tool does, what the return contains, and every side effect including the legacy-migration behavior. Missing only failure modes and idempotency (what happens on a second run), which are modest gaps given how much is already disclosed.

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% and both parameters are documented there, so the baseline applies. The description restates the repo-root framing that matters for repo_id but adds no new semantics for either parameter; mode is 'ignored' only in the schema, not in the description.

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 (set up Cork on this machine, once per repo) and enumerates exactly what the setup does: installs hooks for four named agents, links the machine to the account, writes nothing into the repo, and migrates legacy .collide/ hooks. No sibling tool (claim, connect_agents, get_briefing) plausibly does this, and the migration sub-behavior is called out explicitly.

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?

Gives clear invocation context and constraints: run the returned command exactly as given, in a shell at the repo root, once per repo. It does not name an alternative tool or state when this should not be used (e.g. when Cork is already set up), but the per-repo scope and 'once for every repo' phrasing implies the call cadence.

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