The Codemagic MCP Server exposes the Codemagic CI/CD REST API as callable tools, allowing you to manage your entire Codemagic workflow directly from Claude.
App Management
List all applications, get details for a specific app
Add public repositories (HTTPS URL) or private repositories (SSH keys, with optional passphrase, project type, and team ID)
Delete applications ⚠️
Build Operations
List builds filtered by app, branch, or tag (with pagination)
Get build details including step count summary or full step list
Trigger new builds with a specific workflow, branch/tag, environment variables, and instance type
Cancel running builds ⚠️
Get build logs as a step-by-step status summary (filterable by status) or raw logs for a specific build step
List all artifacts produced by a build
Artifact Handling
Get direct download URLs for build artifacts
Create time-limited public URLs for sharing artifacts
Cache Control
List all build caches for an application
Delete a specific cache or all caches for an application ⚠️
Environment Variables
List, add (with support for secure/encrypted values and groups), update, and delete environment variables ⚠️
Webhook Configuration
List, add (with custom URLs and event subscriptions such as build.finished, build.started), and delete webhooks ⚠️
⚠️ Destructive operations (delete/cancel) are explicitly marked and prompt for confirmation before executing.
Exposes the Codemagic CI/CD REST API as tools to manage applications, trigger and monitor builds, handle artifacts, manage environment variables, and configure webhooks.
A local Python MCP server that exposes the Codemagic CI/CD REST API as Claude-callable tools. Trigger builds, manage apps, download artifacts, and clear caches — all from Claude Code or Claude Desktop without leaving the chat.
Tool | Description |
| List all applications in your Codemagic account |
| Get details of a specific application |
| Add a public repository to Codemagic |
| Add a private repository using an SSH key |
| Delete an application from Codemagic |
Tool | Description |
| List builds, optionally filtered by app |
| Get build details with step count summary; pass |
| Trigger a new build for an application |
| Cancel a running build |
| Get a step-by-step status summary of a build (filterable by status) |
| Get raw logs inline or create/update a managed temp file for a specific build step |
| Check whether a managed local step-log artifact still exists for a specific build step |
| List all artifacts produced by a build |
Tool | Description |
| Get the download URL for a build artifact |
| Create a time-limited public URL for an artifact |
Tool | Description |
| List all build caches for an application |
| Delete a specific build cache |
| Delete all build caches for an application |
Tool | Description |
| List all environment variables for an application |
| Add an environment variable to an application |
| Update an existing environment variable |
| Delete an environment variable |
Tool | Description |
| List all webhooks for an application |
| Add a webhook to an application |
| Delete a webhook |
⚠️ These tools are marked as destructive and will prompt for confirmation before executing.
Related MCP server: claudecode-mcp
The fastest way to get running with Claude Code — no separate install step needed:
# 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 /toolsThat's it. See Configuration for optional settings like CODEMAGIC_DEFAULT_APP_ID.
Requirements: 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 .Get your API token from Codemagic User Settings → Integrations → Codemagic API.
You can provide settings as environment variables or via a .env file:
# .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 is optional but recommended if you work primarily with one app. When set, the AI will use it automatically whenever a tool requires an app_id and none was specified. If it is not set, the AI will:
Call list_apps to discover available apps.
Use the app automatically if only one exists.
Present the list and ask you to choose if multiple apps are found.
get_step_logs supports two delivery modes:
delivery="file" is the default and writes the log to a managed local temp file, returning metadata such as artifact_id, file_path, bytes, line_count, and expires_at.
delivery="inline" returns the raw step log text directly.
The local file mode is useful when a step log is too large to comfortably return inline. Managed log files are stored under CODEMAGIC_LOG_TEMP_DIR and expired files are cleaned up opportunistically whenever a new log file is written. The default retention window is controlled by CODEMAGIC_LOG_TTL_SECONDS and defaults to 3600 seconds.
The server also runs a startup cleanup pass and a periodic background cleanup loop. The loop interval is controlled by CODEMAGIC_LOG_CLEANUP_INTERVAL_SECONDS and defaults to 300 seconds. As an additional safety backstop, the managed temp directory is capped by CODEMAGIC_LOG_MAX_TOTAL_BYTES and CODEMAGIC_LOG_MAX_FILE_COUNT; when either cap is exceeded, the oldest files are evicted first.
get_step_log_artifact(build_id, step_id) checks whether that managed artifact still exists without calling Codemagic again or returning the file contents. The artifact metadata includes a deterministic artifact_id in this format:
artifact_<build_id>_<step_id>If the artifact is missing, the server returns status="missing" with reason not_generated_or_expired, which means the file was either never generated or it expired and was deleted.
Run the following command to add the server:
claude mcp add codemagic -- codemagic-mcpThen set your API key in the MCP env config, or export it in your shell before starting Claude Code:
export CODEMAGIC_API_KEY=your-api-key-hereAlternatively, add it manually to ~/.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"
}
}
}
}Restart Claude Code — the tools will appear in /tools.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %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"
}
}
}
}Restart Claude Desktop to pick up the changes.
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.pyAdd a method to client.py
Add the tool function to the relevant tools/*.py file
That's it — server.py never needs to change
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. Dates show when Glama detected each change.
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_variableAll 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AgiMaulana/CodemagicMcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
