Skip to main content
Glama

create_release

Create or replace app releases on Google Play Console tracks (internal, alpha, beta, production) with version codes, rollout percentages, and release notes.

Instructions

Create or replace a release on a track.

NOTE: With Managed Publishing enabled, the edit is held pending approval. Call publish_managed_release to send live.

Args: package_name: Package name, e.g. com.example.myapp track: "internal", "alpha", "beta", or "production". version_codes: Version codes to include, e.g. [1234]. rollout_percentage: Rollout % when status is "inProgress". Default 10%. status: "draft" (default), "inProgress" (staged), "halted", or "completed". release_name: Optional human-readable name. release_notes: Optional {lang: text} dict, e.g. {"en-US": "Bug fixes"}. country_codes: Optional ISO 3166-1 alpha-2 codes. Empty list removes restrictions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
package_nameYes
trackYes
version_codesYes
rollout_percentageNo
statusNodraft
release_nameNo
release_notesNo
country_codesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The create_release function is defined and decorated as an MCP tool, handling the logic to create or replace a release on a given track via the PublisherClient.
    def create_release(
        package_name: str,
        track: str,
        version_codes: list[int],
        rollout_percentage: float = 10.0,
        status: str = "draft",
        release_name: str = "",
        release_notes: Optional[dict] = None,
        country_codes: Optional[list[str]] = None,
    ) -> str:
        """Create or replace a release on a track.
    
        NOTE: With Managed Publishing enabled, the edit is held pending approval.
        Call publish_managed_release to send live.
    
        Args:
            package_name: Package name, e.g. com.example.myapp
            track: "internal", "alpha", "beta", or "production".
            version_codes: Version codes to include, e.g. [1234].
            rollout_percentage: Rollout % when status is "inProgress". Default 10%.
            status: "draft" (default), "inProgress" (staged), "halted", or "completed".
            release_name: Optional human-readable name.
            release_notes: Optional {lang: text} dict, e.g. {"en-US": "Bug fixes"}.
            country_codes: Optional ISO 3166-1 alpha-2 codes. Empty list removes restrictions.
        """
        try:
            notes = _notes_from_dict(release_notes)
            result = _publisher().create_release(
                package_name=package_name,
                track=track,
                version_codes=version_codes,
                rollout_percentage=rollout_percentage,
                release_name=release_name or None,
                release_notes=notes,
                status=status,
                country_codes=country_codes,
            )
            return json.dumps(
                {
                    "success": True,
                    "message": (
                        f"Release created on '{track}' track with status '{status}'."
                    ),
                    "track": _format_track(result["track"]),
                    "editId": result.get("commit", {}).get("editId"),
                },
                indent=2,
            )
        except Exception as exc:
            return json.dumps({"success": False, "error": str(exc)}, indent=2)
  • Registration of the create_release tool using the @mcp.tool decorator.
    # Tool: create_release
    # ---------------------------------------------------------------------------
    
    @mcp.tool()
Behavior3/5

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

No annotations provided, so description carries full burden. Adds valuable behavioral context about Managed Publishing workflow ('held pending approval'), revealing state management. However, lacks details on idempotency guarantees, error conditions (invalid version codes), or side effects beyond the approval state.

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?

Well-structured with clear separation: one-line purpose, workflow NOTE, then Args block. Every sentence serves a purpose. The Args documentation is verbose but necessary given zero schema coverage. Front-loaded with the key workflow constraint before parameter details.

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

Completeness4/5

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

For a complex 8-parameter mutation tool with output schema, the description is comprehensive. It documents all inputs with business logic (enums, defaults, formats) and workflow integration. Since output schema exists, description appropriately omits return value explanation. Lacks only explicit auth/permission requirements to be a 5.

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

Parameters5/5

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

Schema has 0% description coverage (titles only), so description must fully compensate. The Args section comprehensively documents all 8 parameters: provides examples (package_name, version_codes), enumerates valid values (track, status), explains conditional logic (rollout_percentage depends on status), and clarifies complex types (release_notes as dict, country_codes format). Fully compensates for schema deficiency.

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?

States specific verb+resource ('Create or replace a release on a track') and distinguishes scope from siblings like update_release and promote_release via the replacement semantics. Slightly ambiguous what 'replace' entails (full replacement vs. update), preventing a 5.

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

Usage Guidelines5/5

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

Excellent explicit guidance: 'With Managed Publishing enabled, the edit is held pending approval. Call publish_managed_release to send live.' Directly names sibling tool publish_managed_release and clarifies when to use it, providing clear workflow sequence.

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/GooglePlayConsoleMcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server