# Plugin tools reference.

This page is reference documentation for the plugin’s 42 tools across 8 modules — local tools, exposed in your Claude Code session as native `mcp__plugin_team-management_tm__*` tools. They run _inside your session_; there is nothing to connect to and no hosted API behind them. The one hosted MCP server on this domain is separate: the read-only docs MCP at `https://team.management/mcp/docs`.

## Two different MCP servers

Do not confuse them. The 42 tools documented below belong to the **plugin** MCP: they run locally in your Claude Code session and drive the engine — there is no server on the internet serving them. Separately, team.management runs one **hosted** MCP server, and it serves documentation only:

| Endpoint                           | Transport                                    | Tools                                                                        | Auth |
| ---------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------- | ---- |
| `https://team.management/mcp/docs` | MCP Streamable HTTP (JSON-RPC 2.0 over POST) | `search_docs`, `list_pages`, `get_page` — plus every page as an MCP resource | None |

Point any MCP client at that URL to read these docs. It is read-only. The server card is at `/.well-known/mcp/server-card.json` and the OpenAPI description at `/openapi.json`. For natural-language search, POST a query to `https://team.management/ask`. And to be precise about what _this_ page is: a document. Its markdown twin (`/docs/mcp.md`) is reference text an agent can read — not an endpoint an agent can call. The one MCP server on this domain answers at `https://team.management/mcp/docs`; `/mcp` and `/.well-known/mcp` are discovery aliases of that same server, and no other URL speaks the protocol.

## The 8 modules

| Module              | Tools  | What it covers                                                                     |
| ------------------- | ------ | ---------------------------------------------------------------------------------- |
| `issue_tracking.py` | 14     | Import, create, sync, and comment on issues across GitLab / Jira / GitHub / Gitea. |
| `protocol.py`       | 11     | Drive the JSON protocol engine — start, advance, branch, and customize workflows.  |
| `code_review.py`    | 4      | Automated review runs, plus reading and commenting on MR / PR reviews.             |
| `git_operations.py` | 4      | Commit, push, and open merge / pull requests linked to the task.                   |
| `daic.py`           | 3      | Switch DAIC mode manually (the protocol engine does this per step automatically).  |
| `notifications.py`  | 3      | Reach the user out-of-band when a step blocks on their input.                      |
| `config.py`         | 2      | Read and write non-secret settings through the guided config flow.                 |
| `release.py`        | 1      | Cut a release.                                                                     |
| **total**           | **42** | across 8 modules                                                                   |

## Complete tool reference

Every tool, by module. In a Claude session each is prefixed `mcp__plugin_team-management_tm__` — e.g. `mcp__plugin_team-management_tm__protocol_start`.

| issue_tracking.py               | Purpose                                                              |
| -------------------------------- | -------------------------------------------------------------------- |
| `issue_status`                   | Show the active provider, linked task count, and per-task issue IDs. |
| `config_issue_tracking_status`   | Read the issue-tracking section of config.json.                      |
| `config_code_review_enforcement` | Read the code-review warning-enforcement mode (strict / relaxed).    |
| `issue_read`                     | Import an issue by ID or URL and write it as a task file.            |
| `issue_create`                   | Create a provider issue from an existing task.                       |
| `issue_update`                   | Update title, description, status, or labels on a linked issue.      |
| `issue_sync`                     | Push the current task status to the linked issue.                    |
| `issue_push`                     | Push task file content to the linked issue description.              |
| `issue_link`                     | Attach an existing issue ID to a task.                               |
| `issue_unlink`                   | Remove the issue link from a task.                                   |
| `issue_comment`                  | Post a comment on the linked issue.                                  |
| `issue_set_status`               | Transition the issue to a new status, with an optional comment.      |
| `issue_api`                      | Make a raw authenticated API call to the active provider.            |
| `issue_dependency`               | Declare a blocking / blocked-by relationship between issues.         |

| protocol.py                | Purpose                                                                            |
| -------------------------- | ---------------------------------------------------------------------------------- |
| `protocol_list`            | List all available protocols with their step structures.                           |
| `protocol_start`           | Start a named protocol — the first step then drives task-file and branch creation. |
| `protocol_current`         | Read the active protocol name, current step, and DAIC mode.                        |
| `protocol_advance`         | Complete the current step with an evidence summary and move forward.               |
| `protocol_goto`            | Jump back to a named step — the re-planning anchor.                                |
| `protocol_log`             | Read the protocol audit log for the current or a named task.                       |
| `protocol_abort`           | Abort the active protocol with a reason.                                           |
| `protocol_save_note`       | Append a note to the protocol audit log.                                           |
| `protocol_available_funcs` | List the engine functions usable in pre_funcs / post_funcs.                      |
| `protocol_customize`       | Fork a system protocol into custom/ for editing.                                   |
| `protocol_check_drift`     | Compare custom protocols against the post-upgrade system copies.                   |

| code_review\.py        | Purpose                                                                                  |
| ----------------------- | ---------------------------------------------------------------------------------------- |
| `code_review`           | Run an automated review of the diff and post the results to the MR / PR when one exists. |
| `fetch_mr_review`       | Fetch an existing GitLab MR review by URL or IID.                                        |
| `merge_request_comment` | Post a comment on a GitLab merge request.                                                |
| `pull_request_comment`  | Post a comment on a GitHub / Gitea pull request.                                         |

| git_operations.py     | Purpose                                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| `git_commit`           | Stage and commit the working tree with a message.                                                |
| `git_push`             | Push the current branch to origin.                                                               |
| `merge_request_create` | Create a GitLab MR linked to the task's issue (GitHub / Gitea PRs open via the completion flow). |
| `merge_request_update` | Update a GitLab MR's title or description, or close / reopen it.                                 |

| daic.py                           | Purpose                                                 |
| --------------------------------- | ------------------------------------------------------- |
| `daic_mode_switch_discussion`     | Switch to discussion mode — blocks edit tools.          |
| `daic_mode_switch_implementation` | Switch to implementation mode — unlocks edit tools.     |
| `daic_mode_switch_documentation`  | Switch to documentation mode — docs-only edits allowed. |

| notifications.py                       | Purpose                                                     |
| -------------------------------------- | ----------------------------------------------------------- |
| `notify_user`                          | Send an out-of-band notification (e.g. Telegram).           |
| `notification_status`                  | Check whether notifications are configured and enabled.     |
| `notification_discover_telegram_chats` | List the chats the Telegram bot can see, to pick a chat ID. |

| config.py       | Purpose                                                                                    |
| --------------- | ------------------------------------------------------------------------------------------ |
| `config_get`    | Read a masked config snapshot plus the schema of every settable key.                       |
| `config_update` | Schema-validated write of non-secret settings — gated to the /team-management:config flow. |

| release.py       | Purpose                                                                                                        |
| ---------------- | -------------------------------------------------------------------------------------------------------------- |
| `release_create` | Create a versioned release on GitLab and/or GitHub — whichever are enabled, independent of the issue provider. |

## Why MCP, and why stateless

The tools exist so workflow operations are first-class typed tools with structured errors and guaranteed discoverability — not shell commands the agent must remember to format. Claude agents reliably discover MCP tools in the tool list but often miss slash commands — so exposing the workflow this way makes it dependable. The server is stateless: every tool delegates to the provider utilities and protocol engine in team.management’s `hooks/` directory, so the MCP server and the hooks always run byte-identical code — no version skew.

One tool was deliberately not exposed: there’s no way for Claude to disable its own DAIC enforcement. Turning off the framework is a user-only operation.