Skip to main content
Glama
Sign In
appforshare-mcp

appforshare-mcp

Official
by appforshare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Export the test plan for Firebase or Maestro

export_test_plan
Read-only

Creates runnable Firebase App Testing or Maestro files from a generated AI test plan so other tools can execute the tests.

Instructions

The build's AI test plan as a file other tools run: format "firebase" gives Firebase App Testing agent test cases (YAML for firebase apptesting:execute --test-dir, Android only, preview), "maestro" a Maestro starter flow with a screenshot and an assertWithAI check per task. Needs a plan (test_plan with generate: true). Read only. Pro and Team.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "build": "<build>"
    },
    "name": "export_test_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
buildYesBuild id or the slug of its install link
formatNofirebase

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Read only.' merely restates that. The genuine added value is the disclosure of platform and maturity constraints: Firebase output is Android only and preview, and the Maestro variant is a 'starter flow' rather than a complete suite. Those are real limits an agent needs, but nothing is said about how the file is delivered, whether the export is stable across plan regenerations, or any entitlement enforcement beyond the Pro/Team note.

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 front-loaded with the core action and the two format branches, and every clause carries information – no filler sentences. It is dense, with stacked parentheticals around the firebase format, which slightly taxes first-pass parsing but does not waste words.

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

Completeness3/5

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

For a two-parameter export tool with no output schema, the description does a good job characterizing the payload's contents per format and notes the 'Pro and Team' entitlement plus the prerequisite plan. What it omits is the return mechanics – whether the agent receives raw file content, a download URL, or both – which matters more here precisely because there is no output schema to fall back on.

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

Parameters4/5

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

Schema coverage is only 50% – the 'format' property has an enum and default but no schema description. The description compensates well by explaining precisely what each enum value produces, including the execution target and the per-task contents of the Maestro flow. The 'build' parameter gets only oblique coverage ('the build's AI test plan'), and 'slug of its install link' is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (export) and resource (the build's AI test plan), then enumerates the two output formats with concrete distinctions: 'firebase' yields YAML for firebase apptesting:execute --test-dir, Android only, preview, while 'maestro' yields a starter flow with a screenshot and assertWithAI check per task. An agent can tell exactly what it will receive and how it differs from the sibling test_plan tool, which is explicitly named as a prerequisite rather than a competitor.

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

Usage Guidelines4/5

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

The prerequisite is stated plainly: 'Needs a plan (test_plan with generate: true)', which routes the agent to test_plan first. Format selection guidance is implicit in the format descriptions but there is no explicit when-not-to-use clause or statement of what to do if the plan has not been generated (e.g., whether this errors or auto-generates).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools