What can you do with this server?

This server is an MCP integration for SourceCraft, letting AI agents and IDEs manage repositories, issues, pull requests, CI/CD, releases, users, and organizations via natural language or tool calls. * Repositories: list, create, update, delete repos; list branches/tags; get file trees; list org repos. * Issues: list/filter, view, create, update, close, reopen issues; manage comments. * Pull Requests: list/filter, view, create, update, merge, publish/discard PRs; manage reviewers and review decisions. * CI/CD: list and inspect CI runs, workflows, cube logs, artifacts; trigger workflows. * Releases: list, view, create, update, publish, discard releases; get latest release. * Users & Organizations: get current/user info, list my issues, list user PRs, list orgs, org details, and org members.

How do I use SourceCraft MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SourceCraft MCP Server list my open pull requests" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SourceCraft MCP Server

by ramgml

Overview Schema Source Related Servers Discussions Admin

Python

Remote

SourceCraft MCP Server

MCP (Model Context Protocol) сервер для интеграции с платформой SourceCraft. Позволяет ИИ-агентам и IDE работать с репозиториями, issues, pull requests, CI/CD пайплайнами и релизами SourceCraft.

Пакет также включает CLI утилиту sourcecraft для работы с SourceCraft из терминала (см. CLI утилита).

Установка

Через pip

pip install sourcecraft-mcp

Через uv (рекомендуется)

uv pip install sourcecraft-mcp

Из исходников

git clone https://github.com/ramgml/sourcecraft-mcp.git
cd sourcecraft-mcp
uv pip install -e .

Установка без PyPI

1. Установка из Git репозитория

Добавьте в pyproject.toml другого проекта:

[tool.uv.sources]
sourcecraft-mcp = { git = "https://github.com/ramgml/sourcecraft-mcp.git" }

Или установите напрямую:

uv pip install "git+https://github.com/ramgml/sourcecraft-mcp.git"

2. Настройка MCP с использованием uv и git зависимостей

{
  "mcpServers": {
    "sourcecraft": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "git+https://github.com/ramgml/sourcecraft-mcp.git",
        "--with",
        "git+https://github.com/ramgml/pysourcecraft.git@v0.1.5",
        "python",
        "-m",
        "sourcecraft_mcp.server"
      ],
      "env": {
        "SOURCECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

3. Локальная разработка

Установите в режиме для разработки:

uv pip install -e /path/to/sourcecraft-mcp

Конфигурация MCP с PYTHONPATH:

{
  "mcpServers": {
    "sourcecraft": {
      "command": "python",
      "args": ["-m", "sourcecraft_mcp.server"],
      "env": {
        "SOURCECRAFT_API_TOKEN": "your-api-token",
        "PYTHONPATH": "/path/to/sourcecraft-mcp/src"
      }
    }
  }
}

4. Использование точки входа (после установки из git)

{
  "mcpServers": {
    "sourcecraft": {
      "command": "sourcecraft-mcp",
      "env": {
        "SOURCECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Related MCP server: GitHub Agent MCP Server

Настройка

Получение API токена

Войдите в SourceCraft
Перейдите в Settings → Access → Personal Access Tokens
Создайте новый токен с необходимыми правами

Настройка окружения

Установите переменную окружения:

export SOURCECRAFT_API_TOKEN="your-api-token-here"

Или добавьте в .env файл:

SOURCECRAFT_API_TOKEN=your-api-token-here
SOURCECRAFT_BASE_URL=https://api.sourcecraft.tech  # опционально

Настройка MCP клиента

Добавьте в конфигурацию MCP клиента (например, .vscode/mcp.json или claude_desktop_config.json):

{
  "mcpServers": {
    "sourcecraft": {
      "command": "uvx",
      "args": ["sourcecraft-mcp@latest"],
      "env": {
        "SOURCECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Или для локальной разработки:

{
  "mcpServers": {
    "sourcecraft": {
      "command": "python",
      "args": ["-m", "sourcecraft_mcp.server"],
      "env": {
        "SOURCECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Доступные инструменты

Repositories (8 инструментов)

Инструмент	Описание
`list_repositories`	Список репозиториев пользователя
`list_organization_repositories`	Список репозиториев организации
`get_repository`	Информация о репозитории
`create_repository`	Создать репозиторий
`update_repository`	Обновить репозиторий
`delete_repository`	Удалить репозиторий
`list_branches`	Список веток
`list_tags`	Список тегов
`get_file_tree`	Дерево файлов

Issues (10 инструментов)

Инструмент	Описание
`list_issues`	Список issues с фильтрами
`get_issue`	Информация об issue
`create_issue`	Создать issue
`update_issue`	Обновить issue
`close_issue`	Закрыть issue
`reopen_issue`	Переоткрыть issue
`list_issue_comments`	Список комментариев
`add_issue_comment`	Добавить комментарий

Pull Requests (10 инструментов)

Инструмент	Описание
`list_pull_requests`	Список PR с фильтрами
`get_pull_request`	Информация о PR
`create_pull_request`	Создать PR
`update_pull_request`	Обновить PR
`merge_pull_request`	Смержить PR
`publish_pull_request`	Опубликовать draft PR
`discard_pull_request`	Отклонить PR
`list_pr_reviewers`	Список ревьюеров
`add_pr_reviewer`	Добавить ревьюера
`set_review_decision`	Установить решение ревью

CI/CD (6 инструментов)

Инструмент	Описание
`list_ci_runs`	Список CI запусков
`get_ci_run`	Информация о CI запуске
`get_workflow`	Информация о workflow
`get_cube_logs`	Логи CI cube
`get_artifacts`	Артефакты CI
`trigger_workflows`	Запустить workflows

Releases (7 инструментов)

Инструмент	Описание
`list_releases`	Список релизов
`get_release`	Информация о релизе
`get_latest_release`	Последний релиз
`create_release`	Создать релиз
`update_release`	Обновить релиз
`publish_release`	Опубликовать релиз
`discard_release`	Отклонить релиз

Users & Organizations (7 инструментов)

Инструмент	Описание
`get_current_user`	Текущий пользователь
`get_user`	Информация о пользователе
`list_my_issues`	Мои issues
`list_user_pull_requests`	PR пользователя
`list_organizations`	Список организаций
`get_organization`	Информация об организации
`list_organization_members`	Члены организации

Примеры использования

Работа с репозиториями

> Покажи мне репозитории в организации myorg

Использую list_organization_repositories...

📦 frontend-app - Web application
📦 backend-api - API service
🔒 internal-tools - Internal utilities

Работа с issues

> Найди все открытые issues с приоритетом critical в репозитории myorg/backend-api

Использую list_issues с фильтрами status=open и priority=critical...

🟢 #42 ⚠️ Database connection timeout
   Status: open | Priority: critical | Assignee: @dev1

🟢 #38 ⚠️ Memory leak in worker processes
   Status: open | Priority: critical | Assignee: @dev2

Работа с Pull Requests

> Создай PR для ветки feature/new-auth в main в репозитории myorg/backend-api

Использую create_pull_request...

Pull request создан как draft!

#45: Implement new authentication flow
Branch: feature/new-auth → main
Author: @current-user

Мониторинг CI/CD

> Покажи статус последних CI запусков в myorg/backend-api

Использую list_ci_runs...

CI/CD runs in 'myorg/backend-api':

✅ Run #abc123 - success
   Event: push
   Created: 2024-01-15 10:30 UTC

❌ Run #abc122 - failed
   Event: pull_request
   Created: 2024-01-15 09:45 UTC

CLI утилита

Пакет включает CLI sourcecraft для работы с SourceCraft из терминала. Покрывает все домены API: репозитории, issues, pull requests, CI/CD, релизы, пользователи и организации.

Аутентификация

export SOURCECRAFT_API_TOKEN="your-api-token"
# опционально
export SOURCECRAFT_BASE_URL="https://api.sourcecraft.tech"

Токен также можно передать флагом --token.

Примеры команд

# Репозитории
sourcecraft repo list --org myorg
sourcecraft repo get myorg/backend-api
sourcecraft repo create my-service --visibility private
sourcecraft repo branches myorg/backend-api
sourcecraft repo tree myorg/backend-api --recursive

# Issues
sourcecraft issue list myorg/backend-api --status open
sourcecraft issue create myorg/backend-api --title "Bug" --body "Описание"
sourcecraft issue close myorg/backend-api 42

# Pull requests
sourcecraft pr list myorg/backend-api --status open
sourcecraft pr create myorg/backend-api --title "Fix" --source feature/x --target main --publish
sourcecraft pr merge myorg/backend-api 45 --squash
sourcecraft pr review myorg/backend-api 45 --decision approve

# CI/CD
sourcecraft ci runs myorg/backend-api
sourcecraft ci run myorg/backend-api <run-slug>
sourcecraft ci logs myorg/backend-api <run> <workflow> <task> <cube>
sourcecraft ci trigger myorg/backend-api build --branch main

# Релизы
sourcecraft release list myorg/backend-api
sourcecraft release create myorg/backend-api v1.0.0 --title "First release" --publish

# Пользователи и организации
sourcecraft user me
sourcecraft user prs username --role reviewer
sourcecraft org list
sourcecraft org members myorg

Формат вывода

По умолчанию вывод — читаемые таблицы (Rich). Глобальный флаг --json переключает вывод в JSON для скриптов:

sourcecraft --json repo list --org myorg | jq '.repositories[].slug'

Разработка

Установка зависимостей

uv sync

Запуск тестов

uv run pytest

Линтинг

uv run ruff check .
uv run ruff format .

Структура проекта

src/sourcecraft_mcp/
├── __init__.py
├── server.py          # Точка входа MCP сервера
├── cli/               # CLI утилита (команда `sourcecraft`)
│   ├── app.py         # Точка входа CLI, глобальные опции
│   ├── common.py      # Общие хелперы (клиент, вывод, ошибки)
│   ├── repos.py
│   ├── issues.py
│   ├── prs.py
│   ├── cicd.py
│   ├── releases.py
│   ├── users.py
│   └── orgs.py
├── tools/             # Инструменты по доменам
│   ├── repositories.py
│   ├── issues.py
│   ├── pull_requests.py
│   ├── cicd.py
│   ├── releases.py
│   ├── users.py
│   └── organizations.py
└── utils.py           # Утилиты

Agent Skill

В каталоге skill/ лежит opencode/claude-скилл sourcecraft-cli — инструкции для ИИ-агента по работе с CLI sourcecraft.

Установка скилла в систему

# opencode / claude (глобально)
git clone https://github.com/ramgml/sourcecraft-mcp.git
cp -r sourcecraft-mcp/skill/sourcecraft-cli ~/.agents/skills/
# или: cp -r ... ~/.claude/skills/  |  ~/.config/opencode/skills/

# для конкретного проекта
cp -r sourcecraft-mcp/skill/sourcecraft-cli /path/to/project/.opencode/skills/

Без клонирования, напрямую из репозитория:

mkdir -p ~/.agents/skills/sourcecraft-cli
curl -sSL "https://raw.githubusercontent.com/ramgml/sourcecraft-mcp/main/skill/sourcecraft-cli/SKILL.md" \
  -o ~/.agents/skills/sourcecraft-cli/SKILL.md

После установки перезапустите opencode/claude, чтобы скилл подхватился.

Лицензия

MIT License

Available Tools

48 tools

_add_issue_commentD

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes
`repo`	Yes
`owner`	Yes
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_add_pr_reviewerD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`user_id`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_close_issueD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_create_issueD

ParametersJSON Schema

Name	Required	Default
`repo`	Yes
`owner`	Yes
`title`	Yes
`priority`	No	normal
`assignee_id`	No
`description`	No
`label_slugs`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_create_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`title`	Yes
`publish`	No
`description`	No
`reviewer_ids`	No
`source_branch`	Yes
`target_branch`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_create_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`repo`	Yes
`owner`	Yes
`title`	Yes
`publish`	No
`release_notes`	No
`target_branch`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

create_repositoryA

Create a new repository for the authenticated user.

Args: name: Repository name description: Repository description visibility: Repository visibility (public, internal, private)

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`visibility`	No	private
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and scope, without mentioning side effects, permission requirements, error behavior, idempotency, or what happens on conflicts. It implies authentication via 'authenticated user' but does not disclose any consequences of the mutation. This is minimal disclosure for a create operation.

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 is concise and front-loaded, stating the purpose in the first sentence and then listing parameters in a clear, structured format. It wastes no words and is easy to parse, making it efficient for an agent.

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

Completeness3/5

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

Given the tool's simplicity (3 parameters, no enums, no nested objects) and the presence of an output schema, the description covers the basic intent but omits details like conflict behavior, rate limits, or authentication prerequisites beyond the phrase 'authenticated user'. It is adequate but not comprehensive for a mutation tool.

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

Parameters4/5

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

The schema has 0% description coverage, so the description must compensate. It lists all three parameters with brief descriptions and, crucially, enumerates the allowed values for visibility (public, internal, private), which is not present in the schema. This adds significant value beyond the schema. The other parameters are only lightly described but are straightforward.

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 explicitly states the verb 'create' and the resource 'repository', with the scope 'for the authenticated user'. This clearly distinguishes it from sibling operations like update_repository, delete_repository, and _get_repository. The purpose is unambiguous and specific.

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?

The description clearly implies its use for creating a new repository, which is self-evident given the action. It does not explicitly contrast with alternatives like update_repository or delete_repository, but the intent is clear. There is no explicit guidance on when not to use it, but the context makes it obvious.

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

delete_repositoryB

Delete a repository.

Args: owner: Repository owner repo: Repository name

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

There are no annotations, so the description carries the full behavioral disclosure burden. It only says 'Delete a repository' without noting that deletion is irreversible, may be restricted by permissions, or could cascade to dependent resources. The verb 'delete' implies mutation, but richer context is missing.

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 description is short and front-loaded with the core action. The Args section adds brief definitions without fluff. However, the parameter list partially duplicates the input schema, so it is not maximally efficient.

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

Completeness2/5

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

For a destructive, two-parameter operation with no annotations and no visible output schema description, the tool should disclose irreversibility, permission requirements, and any dependent effects. None of that is provided. The description is adequate only as a minimal statement of intent.

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 description coverage is 0%, and the description adds minimal semantics by identifying 'owner' as 'Repository owner' and 'repo' as 'Repository name'. This explains the parameters slightly beyond their schema titles, but does not provide formats, examples, or constraints.

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 and resource: 'Delete a repository'. This clearly distinguishes it from siblings like create_repository, update_repository, and _get_repository. The intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. It does not warn about destructive consequences, mention when deletion is appropriate or disallowed, or reference related tools like update_repository. The agent is left to infer usage context from the name alone.

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

_discard_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_discard_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_artifactsD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`run_slug`	Yes
`cube_slug`	Yes
`task_slug`	Yes
`workflow_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_ci_runD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`run_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_cube_logsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`owner`	Yes
`run_slug`	Yes
`cube_slug`	Yes
`task_slug`	Yes
`workflow_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_current_userD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_file_treeA

Get the file tree of a repository.

Args: owner: Repository owner repo: Repository name revision: Git reference (branch, tag, or commit SHA). Uses default branch if empty. path: Path within repository. Root if empty. recursive: Whether to retrieve recursively

ParametersJSON Schema

Name	Required	Description	Default
`path`	No
`repo`	Yes
`owner`	Yes
`revision`	No
`recursive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states 'Get' implying a read-only operation, but does not explicitly confirm safety, permissions, rate limits, or any side effects. It also fails to mention pagination, symlink handling, or response size limits. For a read operation with no annotation coverage, this is a significant gap, so a 2 is warranted.

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 description is concise and front-loaded with the purpose, then lists parameters in a structured block. However, it repeats the parameter names and types already present in the schema, adding redundancy. The extra explanation of defaults is valuable, so it is not wasteful, but it could be tightened by omitting the redundant arg listing and focusing on semantics. Still, it is efficient and earns its place.

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

Completeness3/5

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

The tool is relatively simple, and an output schema exists, so return format is covered. However, with no annotations, the description should provide more behavioral context such as confirming it's a read-only operation, potential performance implications of recursive=true, or any limitations (e.g., max depth). These are absent. While the parameter explanations are strong, the overall context is incomplete for an agent deciding whether and how to invoke it safely.

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?

Schema description coverage is 0%, so the description must fully explain parameters. It does so comprehensively: each of the five parameters is described with its meaning and default behavior (e.g., 'revision: Uses default branch if empty', 'path: Root if empty', 'recursive: Whether to retrieve recursively'). This adds significant meaning beyond the bare schema, fully compensating for the lack of schema descriptions.

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 clearly states 'Get the file tree of a repository' with a specific verb and resource. This distinguishes it from sibling tools like list_branches, list_tags, and _get_repository, as it targets the file tree structure rather than refs or metadata. No ambiguity exists about what the tool does.

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?

The description provides clear context that the tool is for retrieving the file tree, which implicitly tells the agent when to use it over siblings. However, it does not explicitly state when not to use it or mention alternatives. Since the purpose is self-evident and distinct from siblings, a 4 is appropriate—clear context but no explicit exclusions.

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

_get_issueD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_latest_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_organizationD

ParametersJSON Schema

Name	Required	Description	Default
`org`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_repositoryC

Get detailed information about a repository.

Args: owner: Repository owner repo: Repository name

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

There are no annotations, so the description carries the burden of disclosing behavior. 'Get' implies a read operation, but the description does not explicitly state read-only semantics, authentication requirements, or any side effects; it also leaves 'detailed information' unspecified. This is a minimal level of transparency.

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 description is short and front-loaded, with the main action in the first sentence. The Args section is somewhat redundant with the schema but adds a small clarification; overall it is appropriately sized.

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

Completeness3/5

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

The tool is simple and an output schema exists, so return values do not need to be documented. Still, the description omits usage context (when to choose this over listing/searching repositories) and any behavioral caveats, leaving an agent to infer those from the name and siblings.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. However, 'owner: Repository owner' and 'repo: Repository name' merely restate the parameter names and add almost no functional detail about format, scope, or constraints. The description fails to fully compensate for the missing schema descriptions.

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 clear verb ('Get') and resource ('detailed information about a repository'), so an agent can identify the operation. However, it does not differentiate from sibling read tools such as _list_repositories or _get_organization beyond the resource name, which is fairly self-evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided for when to use this tool instead of a sibling such as _list_repositories, _get_organization, or update_repository. There are no prerequisites or exclusion criteria; usage is only implied by the generic 'get repository' phrasing.

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

_get_userD

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_get_workflowD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`run_slug`	Yes
`workflow_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

list_branchesC

List branches in a repository.

Args: owner: Repository owner repo: Repository name page: Page number per_page: Items per page

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`owner`	Yes
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'List branches in a repository.' It does not disclose pagination behavior, that it returns a page of results by default, or any details about ordering or rate limits. The behavior is implied to be a read operation, but no additional transparency is provided.

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 description is concise and front-loaded with the purpose, followed by an Args list. There is no fluff or irrelevant content. The structure is clean and easy to scan, though the parameter descriptions are redundant with the schema's property names.

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

Completeness2/5

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

For a simple list tool with an output schema and no annotations, the description is sparser than expected. It does not explain pagination semantics, default values from the schema, or provide any guidance on when to choose this tool over siblings. The return value is presumably covered by the output schema, but the lack of usage and behavioral context leaves the description incomplete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It lists each parameter with a minimal gloss ('owner: Repository owner', etc.), which adds a little beyond the schema's bare titles. However, it does not explain semantic details like page indexing, per_page limits, or that owner/repo are required, leaving the agent with only minimal information.

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 clearly states the verb and resource: 'List branches in a repository.' It is unambiguous about what the tool does, and the owner/repo parameters make the target resource clear. However, it does not explicitly differentiate itself from sibling tools like list_tags or _list_releases, which are similar list operations on the same repository.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for listing branches specifically (though implied by the name), nor does it give any conditions, exclusions, or context for selection. There is no discussion of pagination, default behavior, or when another tool might be more appropriate.

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

_list_ci_runsD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`page_size`	No
`page_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_issue_commentsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`owner`	Yes
`per_page`	No
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_issuesD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`label`	No
`owner`	Yes
`status`	No
`assignee`	No
`per_page`	No
`priority`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_my_issuesD

ParametersJSON Schema

Name	Required	Description	Default
`page_size`	No
`page_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_organization_membersD

ParametersJSON Schema

Name	Required	Description	Default
`org`	Yes
`page`	No
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_organization_repositoriesD

ParametersJSON Schema

Name	Required	Description	Default
`org`	Yes
`page`	No
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

list_organization_repositoriesB

List repositories in an organization.

Args: org: Organization name page: Page number per_page: Items per page

ParametersJSON Schema

Name	Required	Description	Default
`org`	Yes
`page`	No
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior on its own. It does not mention pagination limits, authentication requirements, or the return format. It does list the pagination parameters (page, per_page) which hint at paging behavior, but it doesn't describe what happens on missing permissions or invalid org names. The description is minimal and does not add context beyond the obvious.

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 description is highly concise, with a one-sentence purpose and a list of parameters. It is front-loaded with the main purpose, but it omits critical usage context like when to use it. While concise, completeness is sacrificed.

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

Completeness2/5

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

The output schema is present, which helps agents understand the return structure, and the pagination parameters suggest a paginated API. However, given the lack of annotations and 0% schema description coverage, the description is too sparse. It does not clarify authentication requirements, error handling, or how results are ordered. For a list operation, an agent would benefit from knowing whether it returns a full list or paginated results and any rate limits.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the absence of parameter details. However, it only lists parameter names without explaining their purpose or constraints. The schema provides titles and defaults, but no descriptions, so the agent must infer that 'page' and 'per_page' control pagination. The description does not articulate the expected format or limits for these parameters.

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 clearly states the action ('List') and the resource ('repositories in an organization'), which is specific and distinct from similar tools like _list_repositories (which presumably lists user's repositories) or _get_repository (which fetches a single repository). The tool name already differentiates it, but the description reinforces the organizational scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by specifying the 'org' parameter, but it does not explicitly state when to use this tool over alternatives like _list_repositories or _get_repository. Given the sibling tools, an agent might need additional guidance on distinguishing organizational repositories from personal ones, though the context may be inferred from the 'org' parameter.

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

_list_organizationsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_pr_reviewersD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_pull_requestsD

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`owner`	Yes
`author`	No
`status`	No
`per_page`	No
`source_branch`	No
`target_branch`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_releasesD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`page_size`	No
`page_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_list_repositoriesC

List repositories for a user or the authenticated user.

Args: username: Username to list repos for (None for authenticated user) page: Page number per_page: Items per page

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`per_page`	No
`username`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only listing and the user-scoping behavior, but it does not mention authentication requirements, pagination behavior, error cases, or whether private and forked repositories are included.

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 opening sentence gives the core purpose, and the args list is compact. The parameter explanations are minimal and not bloated, though they are somewhat redundant with the input schema.

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

Completeness3/5

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

For a simple list operation with all-optional parameters and an output schema, the description is adequate but not complete. It does not clarify authentication expectations, pagination edge cases, or how this tool relates to the organization-repo sibling tools.

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 description coverage is 0%, so the description must compensate. It adds useful meaning for username ('None for authenticated user'), but page and per_page are only restated by name, relying on the schema's defaults and types. Partial compensation, not complete.

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 clear verb ('List'), resource ('repositories'), and scope ('for a user or the authenticated user'). It is specific enough to distinguish from organization-repository siblings, though it does not explicitly name the alternative organization-scoped tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like _list_organization_repositories or list_organization_repositories, and no exclusions or conditions are stated. The only usage hint is that username can be None for the authenticated user, but this does not help choose among sibling tools.

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

list_tagsB

List tags in a repository.

Args: owner: Repository owner repo: Repository name page: Page number per_page: Items per page

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`repo`	Yes
`owner`	Yes
`per_page`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List tags in a repository' and documents parameters; it does not mention pagination behavior, ordering, authentication requirements, or other side effects beyond the obvious read-only nature implied by 'List'.

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 is concise, front-loaded with the core purpose, and followed by a clean argument breakdown. Every element earns its place and there is no unnecessary filler.

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

Completeness3/5

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

For a simple paginated list operation with an output schema, the description covers the basic call and parameters. However, it lacks usage guidance and behavioral details, making it minimally viable rather than fully complete for an agent navigating many sibling tools.

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 description coverage is 0%, so the description must compensate. It provides a one-line definition for each parameter (owner, repo, page, per_page), which adds some meaning, but the explanations are mostly tautological and lack constraints such as pagination bounds or format expectations.

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 clear action and resource: 'List tags in a repository.' This distinguishes it from sibling list tools like list_branches and _list_releases by resource type, though it does not explicitly name or contrast those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives such as list_branches or _list_releases. The description simply states the operation and lists arguments, leaving the agent to infer the appropriate context.

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

_list_user_pull_requestsD

ParametersJSON Schema

Name	Required	Default
`role`	No	any
`username`	Yes
`page_size`	No
`page_token`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_merge_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`squash`	No
`pull_number`	Yes
`commit_title`	No
`delete_branch`	No
`commit_message`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_publish_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_publish_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_reopen_issueD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_set_review_decisionD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`decision`	Yes
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_trigger_workflowsD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`repo`	Yes
`owner`	Yes
`branch`	No
`commit`	No
`workflows`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_update_issueD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`title`	No
`priority`	No
`assignee_id`	No
`description`	No
`status_slug`	No
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_update_pull_requestD

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`title`	No
`description`	No
`pull_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

_update_releaseD

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`repo`	Yes
`owner`	Yes
`title`	No
`release_notes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

update_repositoryC

Update repository settings.

Args: owner: Repository owner repo: Repository name description: New description (optional) default_branch: New default branch (optional) visibility: New visibility (optional)

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`visibility`	No
`description`	No
`default_branch`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update repository settings' and lists fields. It does not mention permissions required, whether changes are reversible, how omitted settings are affected, or what the response contains.

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 description is appropriately short and front-loaded with the purpose, followed by a compact Args list. Each line is functional, though several parameter glosses are near-tautological and could be enriched without bloating the description.

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

Completeness2/5

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

For a mutating tool with no annotations and several optional parameters, the description is too thin. It omits prerequisites, alternative routing, effect on unmentioned settings, and accepted input values. The existence of an output schema covers return values, but the broader behavioral context is still incomplete.

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 description coverage is 0%, so the description must compensate. It provides a one-line gloss for every parameter and marks optional fields, which adds some meaning beyond the bare schema. However, it does not specify accepted values for visibility, branch-name constraints, or how the optional values interact with existing settings, leaving significant semantic gaps.

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 action and resource: 'Update repository settings.' This clearly separates it from create/delete operations on the same resource and from update operations on releases, issues, and pull requests. However, it does not explicitly contrast itself with any sibling tool, so a small differentiation gap remains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as create_repository or delete_repository. The description relies entirely on the verb 'update' to imply intent, with no explicit prerequisites, exclusions, or 'when-not-to-use' information.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

48 tool updatesv0.1.0Sep 16, 2026
- First observed_add_issue_comment
- First observed_add_pr_reviewer
- First observed_close_issue
- First observed_create_issue
- First observed_create_pull_request
- First observed_create_release
- First observed_discard_pull_request
- First observed_discard_release
- First observed_get_artifacts
- First observed_get_ci_run
- First observed_get_cube_logs
- First observed_get_current_user
- First observed_get_issue
- First observed_get_latest_release
- First observed_get_organization
- First observed_get_pull_request
- First observed_get_release
- First observed_get_repository
- First observed_get_user
- First observed_get_workflow
- First observed_list_ci_runs
- First observed_list_issue_comments
- First observed_list_issues
- First observed_list_my_issues
- First observed_list_organization_members
- First observed_list_organization_repositories
- First observed_list_organizations
- First observed_list_pr_reviewers
- First observed_list_pull_requests
- First observed_list_releases
- First observed_list_repositories
- First observed_list_user_pull_requests
- First observed_merge_pull_request
- First observed_publish_pull_request
- First observed_publish_release
- First observed_reopen_issue
- First observed_set_review_decision
- First observed_trigger_workflows
- First observed_update_issue
- First observed_update_pull_request
- First observed_update_release
- First observedcreate_repository
- First observeddelete_repository
- First observedget_file_tree
- First observedlist_branches
- First observedlist_organization_repositories
- First observedlist_tags
- First observedupdate_repository

Deploy Server

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

TDQS

D1.5/5.0

Scored 2026-09-16 12:55 across 48 tools

Disambiguation2/5

There are duplicate tools (`_list_organization_repositories` and `list_organization_repositories`) and several similar lifecycle actions (`_create_release` vs `_publish_release`, `_update_pull_request` vs `_publish_pull_request`) that are hard to tell apart. Vague names like `_trigger_workflows` and `_get_cube_logs` further obscure their exact purpose relative to other CI tools.

Naming Consistency2/5

Most tools follow a snake_case verb_noun pattern, but the leading underscore prefix is applied inconsistently: some tools like `create_repository`, `list_branches`, and `get_file_tree` have no underscore. The duplicate `_list_organization_repositories` / `list_organization_repositories` pair and odd names like `_get_cube_logs` also break the naming pattern.

Tool Count2/5

48 tools is a very large surface for a source-management server, especially when several tools appear duplicative or could be consolidated (`_publish_release` vs `_discard_release`, `_trigger_workflows` vs `_get_workflow`). The scope spans users, orgs, repos, issues, PRs, releases, and CI, which feels heavy rather than focused.

Completeness3/5

Major workflows for repositories, issues, pull requests, releases, and CI are covered with CRUD/lifecycle actions in most areas. However, there are notable gaps for a source-management tool: no commit listing/inspection, no branch or tag creation/deletion, and no repository search or org member management beyond listing.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1233,210
Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
632
salesforce-devopsOAuth
cloud.serpent
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
CI/CD & DevOps Version Control CRM
2
iKanbanOAuth
com.i-kanban
Tasks, sprints, releases and docs for engineering teams with AI coding agents.
Project Management Developer Tools
1

Related MCP Servers

GitHub MCP Server
Version Control CI/CD & DevOps Developer Tools
chayan-1906
A
license
Not graded
quality
C
maintenance
Enables AI agents to manage GitHub repositories, branches, issues, pull requests, releases, and actions through natural language.
Updated 3 months ago (2026-06-30 19:01 UTC)
80 npm
5
MIT
GitHub Agent MCP Server
Version Control Developer Tools
Rubiodms
F
license
Not graded
quality
D
maintenance
Enables AI agents to interact with GitHub via natural language, supporting repository management, issue tracking, file commits, and more.
Updated 3 months ago (2026-06-24 12:22 UTC)
-
AutomateHub
Xesderte
A
license
Not graded
quality
B
maintenance
Enables AI agents to automate GitHub repository management, issue tracking, and commits using natural language.
Updated 2 months ago (2026-07-23 17:49 UTC)
3 npm
Apache 2.0
Smart Git MCP Server & CLI
Version Control Developer Tools Code Analysis
rafim-dev
A
license
A
quality
A
maintenance
Enables AI assistants to perform Git workflows with semantic commit messages, pre-PR secret audits, conflict resolution, and release changelog generation.
Updated 18 days ago (2026-09-10 02:20 UTC)
5
MIT