Codemagic CI/CD REST API를 Claude에서 호출 가능한 도구로 노출하는 로컬 Python MCP 서버입니다. 채팅을 나갈 필요 없이 Claude Code나 Claude Desktop에서 바로 빌드를 트리거하고, 앱을 관리하고, 아티팩트를 다운로드하고, 캐시를 삭제할 수 있습니다.
도구 | 설명 |
| Codemagic 계정의 모든 애플리케이션 나열 |
| 특정 애플리케이션의 세부 정보 가져오기 |
| 공개 저장소를 Codemagic에 추가 |
| SSH 키를 사용하여 비공개 저장소 추가 |
| Codemagic에서 애플리케이션 삭제 |
도구 | 설명 |
| 빌드 나열 (앱별 필터링 가능) |
| 단계 수 요약이 포함된 빌드 세부 정보 가져오기; 전체 단계 목록을 보려면 |
| 애플리케이션에 대한 새 빌드 트리거 |
| 실행 중인 빌드 취소 |
| 빌드의 단계별 상태 요약 가져오기 (상태별 필터링 가능) |
| 특정 빌드 단계에 대한 원시 로그를 인라인으로 가져오거나 관리되는 임시 파일 생성/업데이트 |
| 특정 빌드 단계에 대해 관리되는 로컬 단계 로그 아티팩트가 여전히 존재하는지 확인 |
| 빌드에서 생성된 모든 아티팩트 나열 |
도구 | 설명 |
| 빌드 아티팩트의 다운로드 URL 가져오기 |
| 아티팩트에 대한 시간 제한 공개 URL 생성 |
도구 | 설명 |
| 애플리케이션의 모든 빌드 캐시 나열 |
| 특정 빌드 캐시 삭제 |
| 애플리케이션의 모든 빌드 캐시 삭제 |
도구 | 설명 |
| 애플리케이션의 모든 환경 변수 나열 |
| 애플리케이션에 환경 변수 추가 |
| 기존 환경 변수 업데이트 |
| 환경 변수 삭제 |
도구 | 설명 |
| 애플리케이션의 모든 웹훅 나열 |
| 애플리케이션에 웹훅 추가 |
| 웹훅 삭제 |
⚠️ 이 도구들은 파괴적인 작업으로 표시되어 있으며 실행 전 확인을 요청합니다.
Related MCP server: claudecode-mcp
Claude Code를 빠르게 시작하는 방법입니다. 별도의 설치 단계가 필요하지 않습니다:
# 1. Add the server (uses uvx to run it on-demand)
claude mcp add codemagic -e CODEMAGIC_API_KEY=your-api-key-here -- uvx codemagic-mcp
# 2. Restart Claude Code — tools will appear in /tools끝입니다. CODEMAGIC_DEFAULT_APP_ID와 같은 선택적 설정은 구성을 참조하세요.
요구 사항: Python 3.11+
uvx codemagic-mcppip install codemagic-mcpgit clone https://github.com/AgiMaulana/CodemagicMcp.git
cd CodemagicMcp
python3 -m venv .venv
.venv/bin/pip install -e .Codemagic 사용자 설정 → 통합 → Codemagic API에서 API 토큰을 받으세요.
설정은 환경 변수나 .env 파일을 통해 제공할 수 있습니다:
# .env
CODEMAGIC_API_KEY=your-api-key-here
# Optional: set a default app so you don't have to specify it every time
CODEMAGIC_DEFAULT_APP_ID=your-app-id-here
# Optional: customize managed temp log storage for get_step_logs(..., delivery="file")
CODEMAGIC_LOG_TEMP_DIR=/tmp/codemagic-mcp
CODEMAGIC_LOG_TTL_SECONDS=3600
CODEMAGIC_LOG_CLEANUP_INTERVAL_SECONDS=300
CODEMAGIC_LOG_MAX_TOTAL_BYTES=524288000
CODEMAGIC_LOG_MAX_FILE_COUNT=200CODEMAGIC_DEFAULT_APP_ID는 선택 사항이지만 주로 하나의 앱으로 작업하는 경우 권장됩니다. 설정하면 도구에서 app_id가 필요하고 지정되지 않았을 때 AI가 자동으로 이를 사용합니다. 설정되지 않은 경우 AI는 다음과 같이 동작합니다:
list_apps를 호출하여 사용 가능한 앱을 찾습니다.
앱이 하나만 존재하면 자동으로 사용합니다.
여러 앱이 발견되면 목록을 제시하고 선택을 요청합니다.
get_step_logs는 두 가지 전달 모드를 지원합니다:
delivery="file"은 기본값이며 로그를 관리되는 로컬 임시 파일에 쓰고 artifact_id, file_path, bytes, line_count, expires_at과 같은 메타데이터를 반환합니다.
delivery="inline"은 원시 단계 로그 텍스트를 직접 반환합니다.
로컬 파일 모드는 단계 로그가 너무 커서 인라인으로 반환하기 어려울 때 유용합니다. 관리되는 로그 파일은 CODEMAGIC_LOG_TEMP_DIR 아래에 저장되며 만료된 파일은 새 로그 파일이 작성될 때마다 기회주의적으로 정리됩니다. 기본 보존 기간은 CODEMAGIC_LOG_TTL_SECONDS에 의해 제어되며 기본값은 3600초입니다.
서버는 시작 시 정리 작업과 주기적인 백그라운드 정리 루프도 실행합니다. 루프 간격은 CODEMAGIC_LOG_CLEANUP_INTERVAL_SECONDS에 의해 제어되며 기본값은 300초입니다. 추가적인 안전 장치로 관리되는 임시 디렉토리는 CODEMAGIC_LOG_MAX_TOTAL_BYTES 및 CODEMAGIC_LOG_MAX_FILE_COUNT에 의해 제한됩니다. 제한을 초과하면 가장 오래된 파일부터 삭제됩니다.
get_step_log_artifact(build_id, step_id)는 Codemagic을 다시 호출하거나 파일 내용을 반환하지 않고 해당 관리되는 아티팩트가 여전히 존재하는지 확인합니다. 아티팩트 메타데이터에는 다음과 같은 형식의 결정론적 artifact_id가 포함됩니다:
artifact_<build_id>_<step_id>아티팩트가 없으면 서버는 status="missing"과 이유 not_generated_or_expired를 반환합니다. 이는 파일이 생성되지 않았거나 만료되어 삭제되었음을 의미합니다.
다음 명령어를 실행하여 서버를 추가하세요:
claude mcp add codemagic -- codemagic-mcp그런 다음 MCP 환경 설정에 API 키를 설정하거나, Claude Code를 시작하기 전에 셸에서 내보내세요:
export CODEMAGIC_API_KEY=your-api-key-here또는 ~/.claude.json에 수동으로 추가하세요:
{
"mcpServers": {
"codemagic": {
"command": "codemagic-mcp",
"env": {
"CODEMAGIC_API_KEY": "your-api-key-here",
"CODEMAGIC_DEFAULT_APP_ID": "your-app-id-here"
}
}
}
}{
"mcpServers": {
"codemagic": {
"command": "uvx",
"args": ["codemagic-mcp"],
"env": {
"CODEMAGIC_API_KEY": "your-api-key-here",
"CODEMAGIC_DEFAULT_APP_ID": "your-app-id-here"
}
}
}
}Claude Code를 다시 시작하면 /tools에 도구가 나타납니다.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 또는 %APPDATA%\Claude\claude_desktop_config.json (Windows)에 추가하세요:
{
"mcpServers": {
"codemagic": {
"command": "codemagic-mcp",
"env": {
"CODEMAGIC_API_KEY": "your-api-key-here",
"CODEMAGIC_DEFAULT_APP_ID": "your-app-id-here"
}
}
}
}변경 사항을 적용하려면 Claude Desktop을 다시 시작하세요.
codemagic_mcp/
├── config.py # pydantic-settings config (validates API key at startup)
├── client.py # httpx async client, one method per endpoint
├── server.py # FastMCP instance
└── tools/
├── apps.py
├── builds.py
├── artifacts.py
├── caches.py
├── variables.py
└── webhooks.pyclient.py에 메서드 추가
관련 tools/*.py 파일에 도구 함수 추가
끝입니다 — server.py는 변경할 필요가 없습니다
Add a new public repository to Codemagic.
Args: repository_url: The HTTPS URL of the public Git repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repository_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as duplicate handling, authentication needs, or side effects. The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a clear structure (description followed by Args). No unnecessary words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral details and usage context. It does not explain return values or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, but the Arg block adds context: 'The HTTPS URL of the public Git repository.' This provides meaning beyond the schema's title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the specific resource ('a new public repository to Codemagic'), distinguishing it from the sibling 'add_private_app' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'add_private_app'), nor any prerequisites or exclusions. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new private repository to Codemagic using an SSH key.
Args: repository_url: The SSH URL of the private Git repository. ssh_key_data: Base64-encoded SSH private key. ssh_passphrase: Optional passphrase for the SSH key. project_type: Optional project type (e.g. "flutter-app", "react-native"). team_id: Optional team ID to add the app to.
| Name | Required | Description | Default |
|---|---|---|---|
| repository_url | Yes | ||
| ssh_key_data | Yes | ||
| ssh_passphrase | No | ||
| project_type | No | ||
| team_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose side effects or requirements. It fails to mention authentication needs, validation of SSH key, or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence followed by a compact ARGS list. No redundant information, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description adequately covers basic usage but omits details on validation, error handling, and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief explanations for each parameter, such as noting ssh_key_data is base64-encoded. However, it lacks format specifications (e.g., SSH URL pattern) and valid project type values, partially compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a private repository via SSH key, distinguishing it from sibling 'add_app' which likely handles public repos or other methods. However, it does not explicitly contrast the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The purpose is implied but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an environment variable to a Codemagic application.
Args: app_id: The Codemagic application ID. key: The variable name. value: The variable value. group: The variable group name. secure: Whether the variable should be encrypted (e.g. for secrets/tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| key | Yes | ||
| value | Yes | ||
| group | Yes | ||
| secure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the secure parameter's encryption behavior but lacks details on idempotency, error handling if variable already exists, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single introductory sentence followed by a bullet list of parameters. It is well-structured and front-loaded, though the 'Args:' marker is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters but is missing information about return values (no output schema) and error conditions. For a non-trivial tool with 5 parameters, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (generic titles only). The description adds clear semantic meaning for all 5 parameters, e.g., 'group: The variable group name' and 'secure: Whether the variable should be encrypted'. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add an environment variable to a Codemagic application.' This is a specific verb and resource, clearly distinguishing it from sibling tools like update_variable and delete_variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but no explicit guidance on when to use this tool versus alternatives like update_variable. It is implied for new variables, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a webhook to a Codemagic application.
Args: app_id: The Codemagic application ID. url: The URL to send webhook payloads to. events: List of events to subscribe to (e.g. ["build.finished", "build.started"]).
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| url | Yes | ||
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details about side effects (e.g., duplicate handling), authentication requirements, or any behavioral traits beyond the basic operation. With no annotations, the description does not disclose enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear one-line purpose followed by a structured arg list. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is too sparse. It does not explain return values, error handling, or resource limits for the created webhook.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to each parameter, such as 'The Codemagic application ID' and an example for 'events', which goes beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a webhook' and specifies the resource 'Codemagic application', which directly distinguishes it from sibling tools like delete_webhook and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running Codemagic build.
Args: build_id: The build ID to cancel.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true. The description adds that it cancels a 'running' build, which is helpful, but does not disclose side effects (e.g., whether artifacts are lost, if it is reversible, or authorization needs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Every part earns its place, including the argument description. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-param destructive tool, the description covers the core action and parameter. However, it omits return value or confirmation, and doesn't mention constraints like 'build must be running' which is given but not elaborated. Acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds 'The build ID to cancel' for the only parameter. This is basic but sufficient for a single string parameter with a clear name. It does not elaborate on format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair: 'Cancel a running Codemagic build.' It uniquely identifies the tool's function, and among siblings there is no other cancel-like tool, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., waiting for build to complete, or other build management actions). There is no mention of prerequisites or conditions for cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a time-limited public URL for a build artifact.
Args: secure_filename: The secure filename of the artifact (from build results). expires_at: Expiry time as a UNIX timestamp (seconds since epoch).
| Name | Required | Description | Default |
|---|---|---|---|
| secure_filename | Yes | ||
| expires_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the time-limited nature and the parameters but fails to disclose side effects (e.g., whether it overwrites previous URLs), required permissions, error conditions, or rate limits. With no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear purpose statement followed by parameter explanations. Every sentence adds value, and the format is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return value (e.g., the generated URL) or any side effects. It also lacks context on authentication, expiration behavior, and prerequisites. The minimal information leaves the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described: secure_filename as 'from build results' and expires_at as 'UNIX timestamp (seconds since epoch).' This adds meaning beyond the schema (which only provides titles). For 0% schema coverage, this is helpful, though more detail on how to obtain secure_filename would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a time-limited public URL for a build artifact,' specifying the verb, resource, and key attribute (time-limited). This distinguishes it from sibling tools like get_artifact_url (which retrieves existing URLs) and other artifact-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or limitations. For example, it does not mention that the artifact must exist first or that this complements get_artifact_url for retrieving an existing URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all build caches for a Codemagic application.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint already signals the destructive nature, and the description adds that it deletes 'all' caches, which is additional context. However, it does not disclose behavioral details such as irreversibility, scope (e.g., all apps or one app), or async behavior, leaving gaps beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences that front-load the purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive and has no output schema, the description lacks critical information such as return value, synchronization, or warnings beyond the annotation. It feels incomplete for a potentially impactful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only restates the schema property name ('The Codemagic application ID') without adding meaning like how to obtain the ID or format constraints, providing minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'all build caches' for a specific application. It distinguishes from the sibling tool 'delete_cache' by emphasizing 'all', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like delete_cache, nor does it mention prerequisites or context for the operation. Users must infer usage 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.
Delete an application from Codemagic.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, and the description says 'Delete,' which aligns. No additional behavioral context beyond what the annotation provides, such as irreversibility or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences covering purpose and parameter. No wasted words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, destructive annotation present), the description is largely complete. Could mention that the action is irreversible, but the annotation already implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning: 'app_id: The Codemagic application ID.' This explains what the parameter is, making it clear despite the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete an application from Codemagic.' The verb 'delete' and resource 'application' are specific, and the tool is well-distinguished from siblings like add_app or list_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There is no mention of when not to use it or any prerequisites. The purpose is implied but explicit usage direction is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific build cache for a Codemagic application.
Args: app_id: The Codemagic application ID. cache_id: The cache ID to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| cache_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint, and the description adds that it deletes a specific cache. However, it does not disclose irreversibility, permission requirements, or error handling beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and parameter listing, front-loading the main action. However, it could be slightly more structured with clearer formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with no output schema, the description omits important details like irreversibility, expected response, or error scenarios. Adequate for basics but incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description repeats parameter names and adds minimal context (e.g., 'Codemagic application ID'), but lacks format, examples, or constraints. Provides little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'specific build cache for a Codemagic application', distinguishing it from sibling 'delete_all_caches' by specifying a single cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to delete a cache versus alternatives like clearing all caches or other operations. No context on prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an environment variable from a Codemagic application.
Args: app_id: The Codemagic application ID. variable_id: The variable ID to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| variable_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint': true indicates destruction, and the description uses 'Delete,' which aligns. However, no additional behavioral traits (e.g., irreversibility, permissions) are disclosed. With annotations covering the destructive nature, the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. The 'Args' section is somewhat redundant with the schema but not overly verbose. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and low schema coverage, the description provides the essential delete action and required parameters. However, it omits return behavior or side effects, leaving gaps for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description's argument list provides only trivial context ('The Codemagic application ID,' 'The variable ID to delete'), barely adding meaning beyond the schema. It repeats parameter names with minimal elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an environment variable from a Codemagic application,' using a specific verb and resource. It distinguishes from sibling tools like 'add_variable' and 'update_variable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, such as prerequisites or conditions. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook from a Codemagic application.
Args: app_id: The Codemagic application ID. webhook_id: The webhook ID to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| webhook_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, so the description adds minimal behavioral context beyond the verb 'Delete'. No additional caveats about irreversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, front-loaded with purpose, and uses a clear structured format with Args. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description is mostly complete. However, it could mention that the webhook must exist or that deletion is permanent. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains both parameters ('Codemagic application ID' and 'webhook ID to delete'), adding significant meaning beyond schema property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'webhook from a Codemagic application', distinguishing it from siblings like add_webhook and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when webhook is needed vs not) or preconditions. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific application by its ID.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It states 'Get details' (read operation) but doesn't confirm idempotency, error handling (e.g., invalid ID), or permission requirements. Minimal transparency beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence defining the purpose plus an Args line for the parameter. Every word adds value, with no redundant repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers the core purpose and parameter meaning. It lacks details about the response structure, but the context of sibling tools and the tool name compensate somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the lone parameter 'app_id' as 'the Codemagic application ID', adding meaning beyond the schema's title and type. With 0% schema coverage, this is valuable context. However, it doesn't specify format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a specific application by ID. The verb 'Get' and resource 'application' are specific and distinct from sibling tools like list_apps or delete_app. However, it doesn't define what 'details' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need details of a known app, but provides no explicit guidance on when to use alternatives (e.g., list_apps) or prerequisites like authentication. Adequate for a simple retrieval but lacks context for complex decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the download URL for a build artifact.
Args: secure_filename: The secure filename of the artifact (from build results).
| Name | Required | Description | Default |
|---|---|---|---|
| secure_filename | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'gets' a URL, implying a read operation. No details on error behavior, authentication needs, or whether the action is safe, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence and a single parameter bullet point. No redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not specify the return format or possible errors. While the core purpose is clear, completeness is minimal for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'secure_filename' by stating it comes 'from build results', which is not in the schema (0% coverage). This helps the agent locate the parameter value, though more detail (e.g., format) would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('download URL for a build artifact'), effectively distinguishing it from siblings like create_artifact_public_url and list_build_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a download URL but offers no explicit guidance on when to use this tool versus alternatives (e.g., create_artifact_public_url for public URLs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details and status of a specific Codemagic build.
Always includes a step summary (total, success, failed, skipped counts). Set include_steps=True to also get the full list of steps with their IDs, which can then be used with get_step_logs.
Args: build_id: The Codemagic build ID. include_steps: If True, include full step list with IDs. Default False.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| include_steps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool always includes a step summary and can optionally return full step lists with IDs. It implies read-only behavior via 'Get details and status', but does not explicitly state it has no side effects. For a read operation without annotations, this is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose in the first sentence. It then adds a specific behavioral note on step summary and optional steps, followed by a clean parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately describes the return value (details, status, step summary, optionally steps). It also contextualizes the steps output by linking to get_step_logs, completing the agent's understanding of how this tool fits into workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully explains both parameters: build_id as the Codemagic build ID and include_steps as a boolean defaulting to false, and details the consequence of setting include_steps to true (full step list with IDs for use with get_step_logs). This adds significant meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details and status of a specific Codemagic build, distinguishing it from sibling tools like list_builds (which lists builds) and cancel_build (which cancels builds). It also mentions the optional inclusion of step details, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use include_steps=True (to get step IDs for use with get_step_logs), offering clear guidance on parameter usage. However, it does not explicitly state when to use this tool versus other sibling tools like get_build_logs or trigger_build, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a step-by-step status summary of a Codemagic build.
Returns each build step with its name, ID, and status (✅ success, ❌ failed, ⏭ skipped).
Args: build_id: The Codemagic build ID. statuses: Optional list of statuses to filter by. Valid values: "success", "failed", "skipped", "canceled". If omitted, all steps are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| statuses | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format (each step with name, ID, status emoji) and optional filtering, but does not disclose idempotency, authentication needs, or error handling. No annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose sentence, output description, then parameter listings. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides adequate context for a simple retrieval tool: purpose, output, and parameter details. Minor gap in not addressing error scenarios or output schema, but not critical given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Build_id description is minimal but sufficient; statuses description adds valid enum values and default behavior, compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a step-by-step status summary of a Codemagic build, distinguishing it from sibling tools like get_build (full build info) and get_step_logs (raw logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; does not mention when not to use or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a managed step log artifact exists for a build step.
This tool only inspects the local managed artifact created by get_step_logs(..., delivery="file"). It does not fetch from Codemagic, recreate missing files, or return log contents inline.
The returned artifact metadata includes a deterministic artifact_id: artifact__
Args: build_id: The Codemagic build ID. step_id: The step ID (from get_build_logs output).
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| step_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: only inspects local artifact, no fetches, no recreation, no inline contents. It also describes the deterministic artifact_id format, adding valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear header, limitations list, and parameter details. Every sentence adds value, with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers all necessary aspects: purpose, usage, parameter meanings, behavioral traits, and return value (metadata with artifact_id). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section explains both parameters: build_id as 'Codemagic build ID' and step_id as 'step ID from get_build_logs output'. This adds meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check whether a managed step log artifact exists for a build step.' It specifies the action (check existence), resource (managed step log artifact), and context, distinguishing it from siblings like get_step_logs and get_build_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to inspect the local managed artifact created by get_step_logs(delivery='file'). It also clarifies limitations: does not fetch from Codemagic, recreate missing files, or return log contents inline, providing clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw logs for a specific build step.
Use get_build_logs first to see all step IDs, then call this to drill into a specific step.
Args: build_id: The Codemagic build ID. step_id: The step ID (from get_build_logs output). delivery: Defaults to "file" to create/update a managed temp file and return artifact metadata. Use "inline" to return log text directly.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| step_id | Yes | ||
| delivery | No | file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explains the delivery parameter behavior: default 'file' creates/manages a temp file and returns artifact metadata, while 'inline' returns text directly. This provides useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-sentence purpose, a usage guideline sentence, and a parameter explanation paragraph. No superfluous content, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description adequately covers purpose, usage, and parameters. It could mention the return format for inline delivery, but overall it provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: build_id and step_id are identified, step_id referenced to get_build_logs output, and delivery has clear enum explanation with defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'raw logs for a specific build step', distinguishing it from siblings like get_build_logs which lists all step IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use get_build_logs first to obtain step IDs, then call this tool, providing clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all applications in your Codemagic account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'list' but does not disclose if authentication is needed, rate limits, or any side effects. For a read operation, it should at least imply safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, fitting the simple nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal. Given no output schema, it does not explain what fields are returned or if pagination exists. A list tool often needs more detail for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. Description adds no param info, but the baseline for 0 params is 4. It does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all applications' using a specific verb and resource. It distinguishes from sibling tools like add_app (create) and get_app (single app).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool. Usage is implied by its simplicity, but there is no mention of alternatives or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all artifacts produced by a Codemagic build.
Args: build_id: The Codemagic build ID.
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic operation (list all artifacts) but does not disclose behavioral traits such as whether the list is paginated, whether it includes metadata, or what happens with invalid build_id. For a tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. Every sentence is relevant. It could be more informative without losing conciseness, but as a single-line description it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter, no output schema, no annotations, and sibling tools that offer related functionality, the description is incomplete. It does not mention return format, error states, or relationship to other artifact tools. A more complete description would clarify these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no description for build_id). The description adds 'build_id: The Codemagic build ID.', which provides basic meaning but lacks details like expected format, examples, or constraints. With only one parameter and minimal schema, the description should offer more context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'List all artifacts produced by a Codemagic build.' It uses a specific verb and resource, distinguishing from other tools like get_artifact_url that retrieve a single artifact. However, it does not explicitly differentiate from siblings like list_builds, but the resource type is unique enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings such as get_artifact_url or create_artifact_public_url exist, but the description does not mention when to prefer listing all artifacts over individual retrieval. No usage context or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Codemagic builds, optionally filtered by app, branch, and/or tag.
Args: app_id: Optional app ID to filter builds. If omitted, returns builds across all apps. branch: Optional branch name to filter builds (e.g. "main"). tag: Optional tag name to filter builds (e.g. "release_v5.57.2"). limit: Number of builds per page (default 10). page: Page number to retrieve, starting from 1 (default 1).
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | No | ||
| branch | No | ||
| tag | No | ||
| limit | No | ||
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently describes the listing behavior, optional filters, and pagination parameters with defaults. It does not mention read-only nature or side effects, but for a list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence followed by a parameter list. It is front-loaded and each sentence adds value, though the parameter descriptions could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema, the description covers filtering and pagination adequately. It could mention response structure or error cases, but for a list tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for all 5 parameters, including examples for branch and tag. This adds significant value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Codemagic builds' with optional filters, specifying the verb and resource. It distinguishes from siblings like list_apps or get_build by focusing on builds and mentioning filtering by app, branch, tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains optional filters and pagination but does not provide explicit guidance on when to use this tool versus alternatives like get_build for a single build or list_build_artifacts. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all build caches for a Codemagic application.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('List'), which aligns with the name. However, with no annotations provided, the description does not disclose any behavioral traits such as rate limits, pagination, or safety. It relies solely on the word 'List', which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus parameter list), which is appropriate for a simple one-parameter tool. It is front-loaded with the purpose. However, it could afford to add a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description is adequate but not fully complete. It lacks details about what the returned list contains (e.g., cache names, sizes) and whether there is any pagination or filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'app_id' is described as 'The Codemagic application ID', which adds slight clarification. However, the schema already has a title 'App Id', and the coverage is 0% in the schema description. The description does not provide additional format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all build caches') and the resource ('for a Codemagic application'). It is specific to listing caches, but does not explicitly differentiate from sibling tools like 'delete_cache' or 'delete_all_caches'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'delete_cache' or 'delete_all_caches'. There is no mention of prerequisites, context, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all environment variables for a Codemagic application.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only list operation but does not disclose potential side effects, permissions needed, pagination, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two sentences plus an argument list. It is not wordy but could be slightly improved by integrating the argument description more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description does not fully inform the agent about the return structure (e.g., list of variable names and values) or error conditions, leaving gaps for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds 'The Codemagic application ID' for app_id, which provides basic meaning beyond the schema title. However, it lacks details like format or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all environment variables for a Codemagic application.' It distinguishes from sibling tools like add_variable, delete_variable, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the required argument app_id but does not provide guidance on when to use this tool versus alternatives like get_app or list_apps, nor does it specify any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhooks configured for a Codemagic application.
Args: app_id: The Codemagic application ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits beyond the basic operation. It only states 'list all webhooks' without mentioning read-only nature, side effects, or permissions. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two sentences and a parameter list. No wasted words; essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation, the description lacks information about the return value structure, pagination, or limits. With no output schema, this gap leaves the agent uninformed about what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameter by stating it is 'The Codemagic application ID,' which goes beyond the schema's title 'App Id'. Schema coverage is 0%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('webhooks'), and the scope ('for a Codemagic application'), distinguishing it from sibling tools like add_webhook and delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools exist (add_webhook, delete_webhook) but no when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a new build for a Codemagic application.
Args: app_id: The Codemagic application ID. workflow_id: The workflow ID to run. branch: Git branch to build (mutually exclusive with tag). tag: Git tag to build (mutually exclusive with branch). environment: Optional environment variables to override, e.g. {"variables": {"KEY": "value"}}. instance_type: Optional machine instance type to use for the build.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| workflow_id | Yes | ||
| branch | No | ||
| tag | No | ||
| environment | No | ||
| instance_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions mutual exclusivity and optionality but omits key details: what the tool returns, effect on existing builds, rate limits, or authorization requirements. The agent lacks behavioral context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a one-line summary followed by a structured parameter list. It avoids redundancy and is easy to scan. Minor length could be trimmed, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers parameters well but lacks information on return values, side effects, prerequisites, and how it fits with sibling tools like cancel_build. More completeness would be needed for agent confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 provides useful semantics for each parameter: explains mutual exclusivity of branch/tag, format of environment, and optional parameters. This adds significant value beyond the schema's bare names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Trigger a new build for a Codemagic application,' clearly identifying the verb (trigger), resource (build), and context (Codemagic application). This distinguishes it from sibling tools like cancel_build and list_builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While it implies usage for initiating builds, it lacks when-not-to-use scenarios or mentions of related tools (e.g., cancel_build). The mutual exclusivity of branch and tag is noted in the args, but no broader usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing environment variable for a Codemagic application.
Args: app_id: The Codemagic application ID. variable_id: The variable ID to update. key: The variable name. value: The new variable value. group: The variable group name. secure: Whether the variable should be encrypted.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| variable_id | Yes | ||
| key | Yes | ||
| value | Yes | ||
| group | Yes | ||
| secure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks behavioral details such as idempotency, error handling (e.g., if variable doesn't exist), authorization needs, or side effects beyond the basic update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and lists parameters in a clean bullet-style format with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters and no output schema or annotations, the description only covers basic purpose and parameter meanings, omitting details like update semantics (partial vs full) and success/failure scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief one-line explanations for each parameter, compensating for the 0% schema description coverage, but lacks constraints, examples, or additional context beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing environment variable for a Codemagic application, distinguishing it from sibling tools like add_variable and delete_variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'update' but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.7.1get_step_log_artifactget_step_logs1 field changedInput schema / properties / deliveryAdded value: +{
+ "default": "file",
+ "enum": [
+ "inline",
+ "file"
+ ],
+ "title": "Delivery",
+ "type": "string"
+}v0.6.0add_appadd_private_appadd_variableadd_webhookcancel_buildcreate_artifact_public_urldelete_all_cachesdelete_appdelete_cachedelete_variabledelete_webhookget_appget_artifact_urlget_buildget_build_logsget_step_logslist_appslist_build_artifactslist_buildslist_cacheslist_variableslist_webhookstrigger_buildupdate_variableScored across 25 tools
All tools have clearly distinct purposes, with no overlap. Even similar tools like add_app and add_private_app are distinguished by public vs private repos. Descriptions and parameters further clarify their roles.
Tool names consistently follow a verb_noun pattern in snake_case. Examples: add_app, get_build, list_apps, delete_variable. No mixing of casing or style.
25 tools is on the higher end but appropriate for a full CI/CD API covering apps, builds, artifacts, caches, variables, and webhooks. Each tool serves a distinct purpose without redundancy.
Covers most core workflows: app management (add, get, delete), build lifecycle (trigger, cancel, get, list, logs), artifact handling, caches, variables, and webhooks. Missing update_app, but that is a minor gap.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
