Fledly

Check App Store metadata

check_metadata

Read-onlyIdempotent

Checks an app's App Store texts against Apple's limits and keyword hygiene before you submit them: title and subtitle (30 characters each), keyword field (100 bytes, commas without spaces; words already in the title or subtitle, repeated words, singular/plural twins, the app name and category names waste space), promotional text (170), description (4000) and In-App Event name (30, indexed for search), short (50) and long (120) description. valid is false when any issue has level error.

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

Input Schema

Name	Required	Description	Default
`title`	No	App name / title, max 30 characters.
`locale`	No	Metadata language, e.g. en-US or fi (Finnish plural rules).	en-US
`app_name`	No	Brand part of the title if it is not the text before ':' or ' - '.
`keywords`	No	Keyword field: comma-separated, no spaces, max 100 bytes.
`subtitle`	No	Subtitle, max 30 characters.
`event_name`	No	In-App Event name, max 30 characters; indexed for search.
`description`	No	App description, max 4000 characters; not indexed for search.
`target_keywords`	No	Searches the event name should contain; default: keyword field entries and title/subtitle words.
`promotional_text`	No	Promotional text, max 170 characters; not indexed for search.
`event_long_description`	No	In-App Event long description, max 120 characters.
`event_short_description`	No	In-App Event short description, max 50 characters.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds real behavioral value: it enumerates the hygiene rules applied (duplicate words, singular/plural twins, app name and category names wasting space) and discloses the return signal 'valid is false when any issue has level error'.

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?

Two sentences, front-loaded with purpose and then the field limits; no filler. The long parenthetical list is dense but every clause carries information, so it earns its length.

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 an 11-parameter, all-optional validation tool with no output schema, the definition covers purpose, which fields are checked, and the key return field. It does not describe the shape of the issue list, which is the only notable gap.

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 description coverage is 100%, so per-field limits are already documented there; the description largely repeats them. It does add that the keyword field is measured in bytes and that event name is indexed for search, which is a modest increment beyond 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?

States a specific verb (checks) and a precise resource (App Store texts against Apple's limits and keyword hygiene) with scope limits per field. It is clearly a validation tool, distinct from siblings like build_keyword_field or suggest_keywords.

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?

Gives explicit timing guidance: 'before you submit them'. It does not name an alternative tool or state exclusions, but the check-versus-generate split is obvious from the description.

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

All Fledly tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?