appforshare-mcp

Official

by appforshare

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Test plan for a build

test_plan

Idempotent

Retrieves a build’s AI QA plan with up to 15 risk-ordered tasks, steps, source facts, and completion status; set generate to create or refresh it and focus to narrow scope.

Instructions

The AI test plan of a build: up to 15 tasks ordered by risk, each with steps and the fact it comes from (a new permission, a minimum OS change, a readiness finding, the release notes), and which tasks the team ticked as done. Pass generate: true to write a new plan when there is none or the build changed; that uses 1 AI action of the account (Developer role). focus narrows it, for example "payments".

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": "test_plan"
  }
}

Input Schema

Name	Required	Description
`build`	Yes	Build id or the slug of its install link
`focus`	No	Optional area to focus on, with generate
`generate`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.7Nov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond annotations it discloses the costly behavior clearly: a generated plan consumes 1 AI action of the account and requires the Developer role, and it states the condition under which a new plan is written. The annotations flag readOnlyHint=false, and the description is consistent with that by isolating the write behind generate. It does not clarify what an unpermitted caller sees or whether an existing plan is overwritten.

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?

A single dense paragraph front-loads the payload (what the plan contains) before the mutation and cost details. Each clause carries information, though the parenthetical list of provenance sources (new permission, minimum OS change, readiness finding, release notes) is the longest and least actionable part.

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?

With no output schema, the description correctly spends words describing the returned plan's size, ordering, per-task contents, and completion state. Cost, role requirement, and idempotency context round it out; only the empty-plan case and sibling routing are left implicit.

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 67%, and the description adds real meaning to the two weaker parameters: generate's trigger conditions and its AI-action cost, and focus as a narrowing hint with a worked example. It does not clarify focus's behavior when generate is false, despite the schema tying focus to generation.

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 states a concrete resource and return shape: an AI test plan of a build with up to 15 risk-ordered tasks, each with steps and provenance, plus completion ticks. It is clear what the tool produces, but it never distinguishes itself from the sibling export_test_plan, which an agent might reasonably pick for the same artifact.

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?

It gives an explicit trigger for the write path: pass generate: true when there is no plan or the build changed, and explains focus narrows scope with a concrete example ("payments"). It does not say when to prefer a sibling such as export_test_plan, nor what happens when generate is false and no plan exists.

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