Skip to main content
Glama

list_app_info_localizations

Read-only

Retrieve localized app names, subtitles, and privacy URLs for an app info record, using pagination to browse all available localizations.

Instructions

List app-level localized names, subtitles, and privacy URLs.

Input Schema

NameRequiredDescriptionDefault
nextNo
limitNo
appInfoIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the shape of returned fields (names, subtitles, privacy URLs) and says nothing about pagination behavior despite the presence of a 'next' parameter, nor about auth or rate limits.

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 front-loaded sentence with zero filler, which is efficient and readable. However, given the total absence of schema descriptions, the extreme brevity is under-specification rather than true conciseness.

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

Completeness2/5

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

There is no output schema and no parameter documentation, and the description does not cover the required appInfoId, the pagination cursor, or result limits. For a paginated list tool with three undocumented parameters, this leaves the agent without enough information to call it correctly on the first try.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and does not meet it. It never mentions that appInfoId is required, nor explains the limit (1-200) or next cursor parameters, leaving pagination semantics entirely undocumented.

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 names a specific verb ('List') and a specific resource scope ('app-level localized names, subtitles, and privacy URLs'), which distinguishes it from the sibling list_localizations (version-scoped) by the 'app-level' qualifier. It does not explicitly name list_localizations or list_app_infos as alternatives, so the differentiation is implied rather than stated.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative such as list_localizations for version-level data. The 'app-level' qualifier hints at scope but leaves the agent to infer when this tool is preferred over its siblings.

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