Skip to main content
Glama
Sign In
appforshare-mcp

appforshare-mcp

Official
by appforshare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Tester feedback

list_feedback
Read-only

Read tester feedback from install pages, in-app links, and TestFlight, including bug reports, suggestions, screenshots, and crash notes; filter by build, source, status, or release blockers.

Instructions

Feedback testers sent from install pages and the in-app link, and on Team the TestFlight screenshot and crash feedback read from App Store Connect: bug reports, suggestions and other notes, newest first, with the source (page, app or testflight), the device, OS, build (and the TestFlight build) and how many screenshots or recordings came with it (open them in the dashboard link). Read only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
buildNoOptional build id or install link slug
sourceNoOnly reports from the install page, the in-app link, or TestFlight (Team)
statusNoopen
blockersNoOnly reports marked as release blockers

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds real behavioral context beyond them: sort order ('newest first'), the returned fields (source, device, OS, build, screenshot/recording count), and the dashboard link for viewing attachments. It omits pagination or result limits, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a single dense run-on that mixes purpose and return-value detail with nested parentheticals, making it harder to parse than necessary. Meaningful content, but structure could be tightened into discrete clauses.

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 usefully enumerates what comes back and in what order, which is the key missing structured data for a read-only list. It stops short of documenting pagination or the status filter, but is otherwise complete for the tool's complexity.

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

Parameters3/5

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

Schema coverage is 75% and the description adds no meaning beyond the schema for build, source, or blockers, nor does it explain the status filter (which the schema leaves undocumented). Baseline 3 is appropriate since the schema does most of the work and the description doesn't compensate for the gaps.

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?

Names a specific resource (tester feedback) plus the concrete channels it comes from (install pages, in-app link, TestFlight) and the types of content (bug reports, suggestions, notes). The 'Read only' tag signals it is the read path distinct from resolve/tracker siblings, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is only implied by the enumeration of sources and the 'Read only' qualifier; there is no explicit when/when-not statement or pointer to an alternative such as list_reviews or the mutation siblings. An agent can infer its role but gets no routing guidance.

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