Provides tools for interacting with Codemagic CI/CD APIs, enabling AI agents to manage applications, builds, artifacts, caches, and team members programmatically.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Codemagic MCP Server list my applications on Codemagic"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A lightweight, community-maintained Model Context Protocol (MCP) server that provides seamless access to Codemagic CI/CD APIs. Built for agents, AI-native workflows, and for use of MCP-compatible clients.
You: What applications do I have on Codemagic?
Assistant: calls get_all_applications() and displays the list.
You: Start a new build for my Flutter app
Assistant: calls start_build() with appropriate parameters
You: Can you get the artifacts from my last build?
Assistant: calls get_builds() to find the latest build and then get_artifact() to download the files
You: Show me the cache usage for my app
Assistant: calls get_app_caches() and displays storage information
Related MCP server: codemagic_mcp
git clone https://github.com/stefanoamorelli/codemagic-mcp.git
cd codemagic-mcpFollow the official documentation.
For example, for Claude Desktop:
{
"mcpServers": {
"Codemagic MCP Server": {
"command": "uv",
"args": [
"run",
"--with",
"mcp[cli]",
"--with",
"requests",
"mcp",
"run",
"<global_path_to_the_cloned_repo>/codemagic_mcp/server.py"
],
"env": {
"PYTHONPATH": "<global_path_to_the_cloned_repo>/",
"CODEMAGIC_API_KEY": "your-api-key-here"
}
},
}Interact with Codemagic CI/CD using natural language.
API Category | Tools |
Applications API |
|
Artifacts API |
|
Builds API |
|
Caches API |
|
Teams API |
|
Run the server locally for testing:
mcp dev codemagic_mcp/server.pyMIT License © 2025 Stefano Amorelli
Add a new application to Codemagic.
Args: repository_url: SSH or HTTPS URL for cloning the repository team_id: Optional team ID to add the app directly to a team (must be admin)
Returns: Dictionary containing the created application details
| Name | Required | Description | Default |
|---|---|---|---|
| repository_url | Yes | ||
| team_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses required parameters and admin requirement for team_id, but lacks details on side effects or error conditions (e.g., duplicate repository).
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: one-line purpose, clean Args/Returns sections, no superfluous text.
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?
Covers parameters and return value; could mention error scenarios or prerequisites, but sufficient 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?
Description adds meaningful context to parameters: repository_url is for 'SSH or HTTPS URL for cloning' and team_id is 'optional...must be admin', which is beyond the schema's type-only info.
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 'add' and resource 'application to Codemagic', but does not differentiate from sibling tool 'add_application_private'.
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?
Provides some usage context (team_id requires admin), but no explicit guidance on when to use this vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new application from a private repository to Codemagic.
Args: repository_url: SSH or HTTPS URL for cloning the repository ssh_key_data: base64-encoded private key file ssh_key_passphrase: SSH key passphrase or None if the SSH key is without a passphrase project_type: Set to "flutter-app" when adding Flutter application team_id: Optional team ID to add the app directly to a team (must be admin)
Returns: Dictionary containing the created application details
| Name | Required | Description | Default |
|---|---|---|---|
| repository_url | Yes | ||
| ssh_key_data | Yes | ||
| ssh_key_passphrase | No | ||
| project_type | No | ||
| team_id | No |
| Name | Required | Description |
|---|---|---|
| result | 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 describes parameters but does not disclose behavioral traits such as mutation side effects, authentication requirements, or error handling. The return value is briefly mentioned but lacks detail on potential failure modes.
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, using a clear docstring format with a one-line summary followed by Args and Returns sections. Every sentence adds value without redundancy or verbosity.
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 complexity (5 parameters, no annotations, and an output schema), the description covers the primary inputs and what is returned. However, it could mention prerequisites like authentication or error scenarios. The output schema reduces the need for return value details, making it mostly 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%, so the description adds meaningful context by explaining each parameter: repository URL format, base64-encoded key, passphrase handling, project type hint for Flutter, and optional team ID with admin requirement. This goes beyond the schema's type-only information.
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 adds a new application from a private repository to Codemagic, specifying the action, resource, and target. It distinguishes from sibling 'add_application' which likely handles public repos, making the purpose specific and 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 does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions. It implicitly suggests private repo usage via the tool name, but lacks explicit guidance on when not to use or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running build on Codemagic.
Args: build_id: The build identifier
Returns: Response from the API (empty if successful)
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions cancelling a running build but does not specify side effects, error conditions (e.g., if build already completed), or permission requirements. The return value description 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 notably short and structured with argument and return sections. However, the 'Args' and 'Returns' sections add little value given the schema and output schema, so it is efficient but not exceptional.
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 one-parameter tool, the description is complete in terms of operation identification but lacks context about when cancellation is possible, effects on builds, or error scenarios. The output schema exists, so return details are not required, but usage scenario guidance is missing.
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 only restates the parameter name ('The build identifier') without adding any meaning beyond the input schema. With 0% schema description coverage, this is a significant gap.
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 ('Cancel a running build') and the platform ('Codemagic'). It uses a specific verb-resource pair, and the purpose is distinct from sibling tools like start_build or get_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?
No guidance is provided on when to use this tool versus alternatives, such as when a build might be uncancellable or prerequisites. The description only states what it does, not the context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a public download URL for a build artifact.
Args: secure_filename: The secure filename of the artifact (from Builds API or Codemagic UI) Format: uuid1/uuid2/filename.ext expires_at: URL expiration UNIX timestamp in seconds
Returns: Dictionary containing the public artifact URL and expiration timestamp
| Name | Required | Description | Default |
|---|---|---|---|
| secure_filename | Yes | ||
| expires_at | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the URL is public and expires, and provides return format. However, it omits potential side effects, authentication requirements, or rate 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?
Two sentences plus structured Args/Returns sections. Every sentence is necessary; no wasted words. Front-loaded with the primary 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?
For a simple two-parameter tool with an output schema, the description covers the essentials: action, parameter details, and return. Lacks usage comparison but is adequate given complexity.
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%, but description details both parameters: secure_filename format (uuid1/uuid2/filename.ext) and expires_at meaning (UNIX timestamp). This adds significant context beyond the raw 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 the tool creates a public download URL for a build artifact, with specific verb and resource. It distinguishes from sibling tools like get_artifact which retrieves the file itself.
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. Sibling tools like get_artifact or cancel_build exist, but description doesn't explain when creation is needed or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all stored caches for an application.
Args: app_id: The application identifier
Returns: Dictionary with the list of cache IDs that will be deleted and a message
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full responsibility. It states that it deletes 'all stored caches', which is destructive, but does not mention irreversibility, required permissions, or side effects. The return value is described, but behavioral implications are missing.
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 (two lines for args and returns), but at the cost of missing important usage and behavioral context. It is not wordy, but could better balance brevity with completeness. The structure is clear but minimal.
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 that an output schema exists (implied by description mentioning return value), the description explains the return format (list of cache IDs and a message). However, for a destructive tool with a sibling, the description lacks context about when to use it, potential impact, and alternatives. It is adequate but not comprehensive.
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 single parameter 'app_id' is described as 'The application identifier' in the description, which adds basic meaning beyond the schema's title 'App Id'. However, the description does not elaborate on format, validation, or examples. Given 0% schema description coverage, the description provides minimal but acceptable clarification.
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 action ('Delete all caches') and resource ('for an application'). However, it does not differentiate from the sibling tool 'delete_app_cache', which likely deletes a single cache. The description could clarify that this deletes all caches vs. a specific one.
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. Since it deletes all caches, it should warn about destructive consequences or mention when it is appropriate. The sibling 'delete_app_cache' suggests a more targeted alternative, but the description doesn't address this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific cache from an application.
Args: app_id: The application identifier cache_id: The cache identifier to delete
Returns: Dictionary with the deleted cache ID and a message
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| cache_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a destructive action and mentions the return value, but does not disclose behavior for nonexistent caches, reversibility, 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?
The description is concise with a clear one-line summary, followed by structured Args and Returns sections. 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 simplicity of the operation (2 parameters, no nested objects) and the presence of an output schema, the description adequately covers purpose, parameters, and return value. It could mention error conditions but is largely 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?
The description includes an Args section with brief descriptions ('The application identifier', 'The cache identifier to delete'), adding minimal meaning beyond the schema names. Since schema description coverage is 0%, the description partially compensates but lacks depth.
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 a specific cache from an application,' using a specific verb and resource. It distinguishes from the sibling tool 'delete_all_app_caches' by specifying 'specific 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?
The description implies usage for deleting a single cache but does not explicitly state when to use this tool versus alternatives like 'delete_all_app_caches.' No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a team member from the team.
Args: team_id: The team identifier user_id: The user identifier to remove
Returns: Response from the API (empty if successful)
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| user_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the action (removal) and return type, but does not disclose reversibility, permissions needed, 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?
The description is concise and front-loaded, with three distinct sections: purpose, args, and returns. 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 the simple two-parameter tool with an output schema, the description covers the basics. It could include more behavioral context but is largely complete for a straightforward deletion.
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% parameter descriptions, so the description's brief explanation of team_id and user_id adds meaning beyond the schema titles. It could specify formats or sources but is adequate.
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 'Remove a team member from the team,' which is a specific verb-resource pair. It distinguishes itself from sibling tools like invite_team_member.
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 for removing team members but does not explicitly state when to use or avoid this tool, nor does it mention permissions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all applications from Codemagic.
Returns: Dictionary containing the applications
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states 'Retrieve all applications' and return type, but omits behavioral traits such as authorization requirements, rate limits, scope limitations, or whether it returns all applications accessible by the user or all in the system.
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 succinct with one functional line and a return note. It avoids fluff but could be more informative (e.g., specifying the scope 'accessible to the authenticated user'). It earns a 4 for being concise without being wasteful.
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 zero-parameter tool, the description is minimally complete: it states what it does and the return type. However, it lacks context on authentication requirements, pagination, or any limitations. The output schema exists but is not referenced. Gaps remain for full agent decision-making.
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?
There are zero parameters, and schema coverage is 100% by default. The description does not add parameter semantics because none exist. Per guidelines, baseline for 0 params is 4, and no additional value is needed.
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 'Retrieve all applications from Codemagic,' specifying the action (retrieve), resource (all applications), and source (Codemagic). It distinguishes from siblings like 'get_application' (singular) and 'add_application' (write action).
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. There is no mention of prerequisites, context, or exclusions. Given the list of sibling tools like get_application and add_application, the description lacks usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of caches for an application.
Args: app_id: The application identifier
Returns: Dictionary containing the list of caches for the application
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('Retrieve') but does not explicitly state it is non-destructive or discuss permissions, rate limits, or error conditions. 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 short and uses a clear 'Args/Returns' format. It is front-loaded but could be more informative without adding length.
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?
While the output schema exists to describe return values, the description lacks usage context and behavioral details. It is adequate for a simple list tool but missing sibling differentiation and edge cases.
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 application identifier', which adds minimal meaning beyond the schema's 'App Id' label. No format, constraints, or examples are provided, leaving gaps for a required parameter.
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 retrieves a list of caches for an application, with a specific verb and resource. It differentiates from sibling delete operations, though not explicitly.
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 like delete_app_cache or delete_all_app_caches. It does not mention use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific application from Codemagic by ID.
Args: app_id: Application ID
Returns: Dictionary containing the application details
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states the basic function. It does not disclose behavioral traits such as whether the operation is safe, requires authentication, or has any 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?
The description is concise and well-structured with Args/Returns sections. It front-loads the purpose and is easily parseable, though it could be improved by front-loading the most critical 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 the presence of an output schema, the description does not need to detail return values. However, it still lacks context on how to obtain the app_id or when this tool is preferable, leaving the agent with a minimally complete picture.
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%, yet the description merely repeats the parameter name (app_id) without explaining its format, derivation, or constraints. It adds minimal 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 action (Retrieve), the resource (application from Codemagic), and the scope (by ID). It effectively distinguishes this tool from siblings like get_all_applications and add_application.
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 does it mention any prerequisites or exclusions. The agent is left to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authenticated download URL for a build artifact.
Args: secure_filename: The secure filename of the artifact (from Builds API or Codemagic UI) Format: uuid1/uuid2/filename.ext
Returns: The artifact file content as bytes
| Name | Required | Description | Default |
|---|---|---|---|
| secure_filename | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to return a 'download URL' but the 'Returns' section says 'the artifact file content as bytes,' creating a contradiction. No annotations are provided, so the description should fully disclose behavior, but it fails to clarify authentication needs, rate limits, or the actual return format.
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 'Args' and 'Returns' sections. It is concise but not overly brief, with the first sentence directly stating the purpose. Minor redundancy exists in the 'Returns' line.
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?
Despite having an output schema (unshown), the description's return description contradicts the tool's stated purpose. It lacks guidance on usage context relative to siblings and does not address potential pitfalls. The artifact's nature and authentication steps are unclear.
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 'secure_filename' parameter is explained with context about its origin and format ('uuid1/uuid2/filename.ext'), which adds meaning beyond the schema's basic title and type. Schema description coverage is 0%, so the 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 tool's purpose: 'Get authenticated download URL for a build artifact.' It uses a specific verb and resource, distinguishing it from sibling tools like 'create_public_artifact_url' and 'get_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?
No guidance is provided on when to use this tool versus alternatives such as 'create_public_artifact_url'. No context about prerequisites, authentication, or comparison with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of builds from Codemagic build history.
Args: app_id: Optional filter by application identifier workflow_id: Optional filter by workflow identifier branch: Optional filter by branch name tag: Optional filter by tag name
Returns: Dictionary containing applications and builds information
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | No | ||
| workflow_id | No | ||
| branch | No | ||
| tag | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states it gets a list and returns a dictionary, without mentioning side effects (none expected), authentication requirements, rate limits, or the read-only nature. This lack of detail leaves behavioral ambiguity.
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 three sentences: purpose, parameter list, and return type. It is front-loaded with the core action, and every sentence serves a purpose 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 tool's low complexity and available output schema, the description covers basic functionality and parameters. However, it omits contextual details like pagination, default ordering, or result limits, which are relevant for a listing endpoint. It is adequate but not comprehensive.
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 compensates with an 'Args' block that provides clear, concise descriptions for each parameter (e.g., 'Optional filter by application identifier'). These add meaning beyond the schema's type and default fields, though they are minimal and could include formatting details.
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 'Get a list of builds from Codemagic build history,' providing a specific verb and resource. It distinguishes from sibling tools like get_build_status (which retrieves a single build) and cancel_build, making its 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 does not explicitly state when to use this tool versus alternatives like get_build_status or start_build. It implies usage for listing builds with optional filters but lacks direct comparisons or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a build on Codemagic.
Args: build_id: The build identifier
Returns: Dictionary containing the application and build information
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 states the return type (Dictionary with application and build info), which adds transparency. However, it does not mention side effects, auth requirements, or rate limits, but for a read-only operation this is acceptable.
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 includes structured 'Args:' and 'Returns:' sections, making it easy to parse. It is appropriately concise without missing critical information.
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 that there is only one parameter and an output schema exists, the description provides enough information for a simple 'get status' tool. It covers the basic workflow, though it could mention potential errors or prerequisites.
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. The description adds 'The build identifier' for the build_id parameter, which is only marginally more informative than the schema's title 'Build Id'. No additional constraints or format details are provided.
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 gets the status of a build, with a specific verb and resource. However, it does not explicitly distinguish from the sibling tool 'get_builds', which likely retrieves a list of 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?
No guidance is provided on when to use this tool versus alternatives like 'get_builds' or 'get_build_step_log'. There are no exclusions or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw log output for a specific build step on Codemagic.
Calls the undocumented endpoint that the Codemagic web dashboard uses internally (GET /builds/{build_id}/step/{step_id}), which returns the step's stdout/stderr as text/plain. Use this to diagnose failed builds without manual dashboard access.
The step_id is the _id field of any entry in the buildActions array
returned by get_build_status, or equivalently the last path segment
of that step's logUrl.
Args: build_id: The build identifier step_id: The build step identifier
Returns: The step log as plain text
| Name | Required | Description | Default |
|---|---|---|---|
| build_id | Yes | ||
| step_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it calls an undocumented endpoint and returns text/plain. No side effects mentioned; read operation implied.
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?
Six sentences covering purpose, background, usage, parameters, and return value. No fluff, well-organized.
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 simple tool with 2 parameters and plain text output, description is complete. Includes endpoint details and parameter origin.
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?
No schema descriptions, but description adds crucial semantics for step_id: 'the `_id` field of any entry in the `buildActions` array returned by `get_build_status`, or equivalently the last path segment of that step's `logUrl`.' build_id is simply described as 'The build identifier'.
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 'Get the raw log output for a specific build step on Codemagic.' Differentiates from siblings like get_build_status and get_artifact by specifying step-level 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?
Explicitly recommends using it 'to diagnose failed builds without manual dashboard access.' Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invite a new team member to your team.
Args: team_id: The team identifier email: User email to invite role: User role, can be 'owner' (Admin) or 'developer' (Member)
Returns: Full team object
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| Yes | |||
| role | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the action and return value but does not disclose side effects (e.g., sending an invitation email), potential errors (e.g., duplicate invitation), or permissions needed. For a mutation tool, this is a significant gap.
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, using a front-loaded main sentence followed by a structured Args section. Every sentence is informative, and there is no redundant or extraneous text.
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 three required parameters and no annotations, the description explains the parameters and return value but lacks information on permissions, error handling, and behavioral nuances (e.g., idempotency, email delivery). It is functional but not fully comprehensive for a new user.
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 compensates by explaining each parameter's meaning: team_id is identifier, email is User email, role is User role with allowed values listed ('owner' or 'developer'). This adds clear value beyond the schema's bare type declarations.
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 ('Invite a new team member') and identifies the resource (team member) and context ('to your team'). It is specific and distinguishes from sibling tool 'delete_team_member'.
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 does not explicitly state when to use the tool versus alternatives, nor does it mention prerequisites (e.g., required permissions) or conditions to avoid (e.g., if the user is already a member). It implies usage context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new build on Codemagic.
Args: app_id: The application identifier workflow_id: The workflow identifier branch: The branch name (either branch or tag is required) tag: The tag name (either branch or tag is required) environment: Dictionary with environment variables, variable groups, and software versions labels: List of labels to include for the build instance_type: Type of instance to use for the build (e.g. 'mac_mini_m2')
Returns: Dictionary with the build ID
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | ||
| workflow_id | Yes | ||
| branch | No | ||
| tag | No | ||
| environment | No | ||
| labels | No | ||
| instance_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It lacks details on side effects, permissions, rate limits, error conditions, or guarantees, which are critical for a build-triggering tool.
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 Args and Returns sections, but could be more concise by separating required and optional parameters.
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 basic inputs and output but lacks completeness regarding error handling, prerequisites, or behavior under failure conditions, which are important for a CI/CD build 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 beyond the schema by explaining each parameter and noting that 'either branch or tag is required'—a constraint not present in the schema. This compensates for the 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?
The description clearly states 'Start a new build on Codemagic' and lists specific parameters, making it distinct from sibling tools like get_builds or cancel_build.
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, nor does it mention prerequisites or exclusions.
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.1.0add_applicationadd_application_privatecancel_buildcreate_public_artifact_urldelete_all_app_cachesdelete_app_cachedelete_team_memberget_all_applicationsget_app_cachesget_applicationget_artifactget_build_statusget_build_step_logget_buildsinvite_team_memberstart_buildAll tools have clearly distinct purposes: adding public vs private apps, managing builds, caches, team members, and artifacts. No overlap or ambiguity.
Tools follow a consistent verb_noun pattern with underscores. Minor inconsistency: singular vs plural nouns (e.g., 'get_application' vs 'get_all_applications').
16 tools cover the essential aspects of Codemagic CI/CD (apps, builds, caches, teams, artifacts) without being excessive or sparse.
Core operations are present, but missing update/delete for applications and no tool to list or get workflow details, which agents may need.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Appcircle mobile CI/CD platform.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/stefanoamorelli/codemagic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
