Skip to main content
Glama

list_build_artifacts

Retrieve all artifacts generated by a specific Codemagic build by providing its build ID.

Instructions

List all artifacts produced by a Codemagic build.

Args: build_id: The Codemagic build ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
build_idYes

Implementation Reference

  • Core handler that calls the Codemagic API to GET /builds/{build_id}, extracts 'artefacts' from the response, and returns a filtered list of artifact metadata (name, type, url, size, version, versionCode, minOsVersion).
    async def list_build_artifacts(self, build_id: str) -> Any:
        build = await self._get(f"/builds/{build_id}")
        artifacts = build.get("build", {}).get("artefacts", [])
        return [
            {
                "name": a.get("name"),
                "type": a.get("type"),
                "url": a.get("url"),
                "size": a.get("size"),
                "version": a.get("versionName") or a.get("version"),
                "versionCode": a.get("versionCode"),
                "minOsVersion": a.get("minOsVersion"),
            }
            for a in artifacts
        ]
  • MCP tool handler function decorated with @mcp.tool(). Receives build_id, creates a CodemagicClient, and delegates to client.list_build_artifacts. Includes docstring and Args section.
    @mcp.tool()
    async def list_build_artifacts(build_id: str) -> Any:
        """List all artifacts produced by a Codemagic build.
    
        Args:
            build_id: The Codemagic build ID.
        """
        async with CodemagicClient() as client:
            return await client.list_build_artifacts(build_id)
  • Top-level registration: register_all_tools(mcp) called during server setup, which in turn registers builds module including list_build_artifacts.
    register_all_tools(mcp)
  • The register_all_tools function calls builds.register(mcp), which registers all build-related tools including list_build_artifacts via the @mcp.tool() decorator.
    def register_all_tools(mcp: FastMCP) -> None:
        apps.register(mcp)
        builds.register(mcp)
  • The @mcp.tool() decorator on line 143 registers list_build_artifacts as an MCP tool.
    @mcp.tool()
    async def list_build_artifacts(build_id: str) -> Any:
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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