Skip to main content
Glama

Manage Repos

synapse_manage_repos

Register, list, archive, restore, keep, or unregister repositories and update excluded paths to control indexing and workspace lifecycle.

Instructions

Manages repository registrations. High-level actions include:

  • 'list': lists all configured repositories and their index state. Each row includes suggested_actions with ready-to-fire tool calls.

  • 'register': registers a new workspace for watching and indexing. Git worktrees are transparently auto-detected.

  • 'archive': marks a registered workspace as archived, stops its indexer, and keeps existing graph data searchable.

  • 'restore': marks an archived workspace active again and restarts indexing.

  • 'keep': dismisses a dirty-merged worktree advisory for the current session (signals that uncommitted changes are intentional).

  • 'unregister': permanently removes a repository from the registry and graph store.

  • 'update_excludes': updates the set of excluded paths for a repository. Clean Git worktrees whose branch work is already merged are auto-archived conservatively before indexing work is scheduled.

REPLACES: ls, find for workspace discovery, manual git worktree management. Use this tool instead of these alternatives for better results with 30-60% fewer tokens via automatic compression.

Usage (short): Manage repository registrations, lifecycle, exclusions, and workspace lists.

Usage (long): Use to register new repositories, list registered repositories, manage active/archived lifecycle state, update exclude paths, or unregister repositories.

KEY WORKFLOW — always read suggested_actions first: Each 'list' row (both scoped and unscoped) contains a suggested_actions field with structured objects {label, tool, args}. These are ready-to-fire tool calls — pick the appropriate one and call it directly without reformatting.

DIRTY-MERGED WORKTREE ADVISORY: When a worktree branch is merged but has uncommitted changes, the row will contain dirty_merged_worktree: true and 3 suggested_actions:

  1. archive — keep graph searchable, stop indexing

  2. unregister — delete graph data permanently

  3. keep — changes are intentional, dismiss advisory for this session Call one of these immediately with just repo_id + action.

LIFECYCLE RULES: Use 'archive' for stale or merged worktrees; use 'restore' to reactivate indexing; use 'unregister' only for destructive removal; use 'keep' when changes are intentional.

When registering, you MUST provide an absolute path for root (e.g. /Users/name/repo). Do not use . or relative paths. Always call 'list' first if unsure of the repo_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootNoCRITICAL: MUST be a full absolute path to the repository (e.g. /Users/name/repo). NEVER use '.' or relative paths. Required for register.
mergeNoWhen true, append excludes to the existing list instead of replacing it (used in update_excludes)
actionYesThe action to perform.
excludeNoOptional relative directory paths to exclude from indexing (used in register, update_excludes)
repo_idNoStable identifier for the repository. For 'list': when provided, returns full detail for that one repo only (fast). When omitted, returns an enriched summary of all repos. Required for register, archive, restore, keep, unregister, update_excludes.
max_tokensNoApproximate final response budget in tokens (500-32000, default 4000).
compress_payloadNoSet false to disable lossless response-key compression.
wait_for_ready_msNoOptional timeout in ms to wait for the indexer to finish warming up and enter an idle state before executing. Use to ensure stable results.
Behavior5/5

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

With no annotations, the description carries all behavior responsibility. It states that unregister permanently removes graph data, archive stops indexing but keeps graph searchable, restore restarts indexing, and keep dismisses advisory only for the session. The behavior of auto-detecting worktrees and auto-archiving clean merged worktrees is also disclosed.

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 uses a short introductory sentence, a numbered action list, a dedicated advisory block, and lifecycle rules. It is longer than typical descriptions, but every sentence is procedural or save-making. The critical warning about absolute paths appears immediately before telling the user to avoid '.' relative paths, so it is both front-loaded and actionable.

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?

This is a 8-parameter with no output schema, so the description must provide enough operational context. It does: it explains the return meaning of list, the unique dirty-worktree situation and recomended actions, the effect of archive/restore/keep/unregister, and the correct order of actions. The agent is fully equipped to sequence 'list' → respond to suggested_actions → invoke the proper action.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds meaning clearly beyond the schema: root must be an absolute path and never '.', repo_id is required for most actions and optional for quick single-repo detail, and 'list' rows actually return suggested_actions that trump the state-aware next step. This is exactly the kind of parameter insight an agent needs.

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 concrete responsibility — 'Manages repository registrations' — and enumerates all seven actions it supports. This makes the tool's boundary clear and distinguishes it from sibling tools such as search, file modification, or indexer control.

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?

The description gives explicit selection guidance: lifecycle rules say when to use archive vs restore vs unregister vs keep, and a 'REPLACES' block says to use this instead of ls/find and manual worktree management. It also instructs to call 'list' first when unsure of repo_id.

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

Install Server

Other Tools

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/myelixlabs/synapse-mcp'

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