Add repository label management write tool (create_label) #15

Open
opened 2026-03-12 13:56:08 +00:00 by Bartender · 0 comments
Owner

Summary

Add support for creating repository labels through the MCP server by introducing a new write-mode tool: create_label.

This would allow ChatGPT/MCP workflows to create missing repository labels directly instead of requiring labels to be created manually in the Gitea UI before they can be applied to issues.

Problem

The current MCP server supports:

  • listing repository labels
  • adding existing labels to issues or pull requests

But it does not support creating repository labels themselves.

This creates workflow friction for issue management automation because:

  • labels must be pre-created manually in Gitea
  • MCP can only attach labels that already exist
  • infra/project setup flows are incomplete when repositories start without a label taxonomy

Why this is useful

Adding create_label would make the MCP write surface more complete for issue/project hygiene and setup tasks, especially for:

  • new repositories
  • infra/project bootstrapping
  • automating issue triage structures
  • setting up consistent label taxonomies from ChatGPT or other MCP clients

Proposed capability

Introduce a write-mode MCP tool:

  • create_label

Suggested arguments:

  • owner
  • repo
  • name
  • color
  • optional description

Proposed implementation areas

1. Gitea client

Add a new client method in src/aegis_gitea_mcp/gitea_client.py for repository label creation.

Suggested shape:

  • create_label(owner, repo, name, color, description=None)

2. Argument schema

Add a new validated argument model in src/aegis_gitea_mcp/tools/arguments.py.

Suggested schema:

  • CreateLabelArgs

Validation should include at least:

  • non-empty name
  • valid color format handling
  • optional description

3. Write tool

Add a new tool implementation in src/aegis_gitea_mcp/tools/write_tools.py.

Suggested shape:

  • create_label_tool(...)

4. Tool registration

Register the tool in the MCP tool surface so it appears in:

  • tool listing
  • write-mode availability
  • policy-controlled execution

5. Documentation

Update at minimum:

  • docs/api-reference.md
  • docs/write-mode.md

Security / policy requirements

This should remain a write-mode-only capability.

Recommended controls:

  • respect WRITE_MODE=true
  • respect repository allowlist / write policy restrictions
  • audit all invocations
  • reject unauthorized repos/users/tokens
  • avoid broadening write scope beyond repository metadata management

Operational considerations

Need to define expected behavior for:

  • duplicate label names
  • invalid color formats
  • empty descriptions
  • error handling when repo permissions are insufficient
  • whether descriptions are optional or normalized to empty string

Suggested response shape

Return something similar to:

  • label id
  • name
  • color
  • description
  • repo
  • URL if available

Nice follow-up work

Once create_label exists, likely next logical additions would be:

  • update_label
  • delete_label

Those do not need to be part of this issue, but are worth keeping in mind for future completeness.

Definition of done

  • create_label client method implemented
  • CreateLabelArgs validation added
  • create_label_tool implemented
  • tool registered in MCP server
  • write-mode and repo policy enforcement confirmed
  • audit logging confirmed
  • docs updated
  • manual test or automated test added for successful label creation
  • failure cases tested for permissions and invalid input
## Summary Add support for creating repository labels through the MCP server by introducing a new write-mode tool: `create_label`. This would allow ChatGPT/MCP workflows to create missing repository labels directly instead of requiring labels to be created manually in the Gitea UI before they can be applied to issues. ## Problem The current MCP server supports: - listing repository labels - adding existing labels to issues or pull requests But it does not support creating repository labels themselves. This creates workflow friction for issue management automation because: - labels must be pre-created manually in Gitea - MCP can only attach labels that already exist - infra/project setup flows are incomplete when repositories start without a label taxonomy ## Why this is useful Adding `create_label` would make the MCP write surface more complete for issue/project hygiene and setup tasks, especially for: - new repositories - infra/project bootstrapping - automating issue triage structures - setting up consistent label taxonomies from ChatGPT or other MCP clients ## Proposed capability Introduce a write-mode MCP tool: - `create_label` Suggested arguments: - `owner` - `repo` - `name` - `color` - optional `description` ## Proposed implementation areas ### 1. Gitea client Add a new client method in `src/aegis_gitea_mcp/gitea_client.py` for repository label creation. Suggested shape: - `create_label(owner, repo, name, color, description=None)` ### 2. Argument schema Add a new validated argument model in `src/aegis_gitea_mcp/tools/arguments.py`. Suggested schema: - `CreateLabelArgs` Validation should include at least: - non-empty name - valid color format handling - optional description ### 3. Write tool Add a new tool implementation in `src/aegis_gitea_mcp/tools/write_tools.py`. Suggested shape: - `create_label_tool(...)` ### 4. Tool registration Register the tool in the MCP tool surface so it appears in: - tool listing - write-mode availability - policy-controlled execution ### 5. Documentation Update at minimum: - `docs/api-reference.md` - `docs/write-mode.md` ## Security / policy requirements This should remain a write-mode-only capability. Recommended controls: - respect `WRITE_MODE=true` - respect repository allowlist / write policy restrictions - audit all invocations - reject unauthorized repos/users/tokens - avoid broadening write scope beyond repository metadata management ## Operational considerations Need to define expected behavior for: - duplicate label names - invalid color formats - empty descriptions - error handling when repo permissions are insufficient - whether descriptions are optional or normalized to empty string ## Suggested response shape Return something similar to: - label id - name - color - description - repo - URL if available ## Nice follow-up work Once `create_label` exists, likely next logical additions would be: - `update_label` - `delete_label` Those do not need to be part of this issue, but are worth keeping in mind for future completeness. ## Definition of done - `create_label` client method implemented - `CreateLabelArgs` validation added - `create_label_tool` implemented - tool registered in MCP server - write-mode and repo policy enforcement confirmed - audit logging confirmed - docs updated - manual test or automated test added for successful label creation - failure cases tested for permissions and invalid input
Sign in to join this conversation.