Skip to main content
Glama

AppTrack Ninja

find_apps

Structured catalog filter for a Pro account. Dates are YYYY-MM-DD. upcoming=false drops pre-orders. Pass the previous response next value as cursor to continue. limit defaults to 50 and caps at 5000.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
sortNo
limitNo
orderNo
cursorNo
countryNo
languageNo
upcomingNo
minRatingNo
monetizationNo
updatedAfterNo
releasedAfterNo
updatedBeforeNo
minRatingCountNo
releasedBeforeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real behavior: cursor-based pagination via a returned 'next' value, a default limit of 50 with a 5000 cap, and that upcoming=false drops pre-orders. It still omits return shape, ordering semantics, rate limits, and error behavior.

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?

Five short, information-dense sentences with no filler; pagination and defaults are each given one clause. The opening purpose clause is the weakest part because it is a noun phrase rather than an actionable statement.

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?

For a 15-parameter tool with no annotations and no output schema, the definition omits much of what an agent needs: what a result row contains, how sort/order interact, and the meaning of most filter fields. The pagination note is the one genuinely complete piece of context.

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 15 parameters, so the description must compensate, and it only touches limit, cursor, upcoming, and date format (which the schema pattern already encodes). Roughly nine parameters — q, sort, order, country, language, minRating, minRatingCount, monetization — are undocumented in either place.

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

Purpose3/5

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

The phrase 'Structured catalog filter' names the resource domain (app catalog) and implies a list/filter operation, so the gist is recoverable. However, there is no clear verb and no differentiation from siblings like search_apps, trending_apps, or get_app, which an agent must disambiguate on its own.

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?

The description states it is for 'a Pro account' (a prerequisite of sorts) but never says when to choose this over search_apps or the other catalog-listing tools. No exclusion criteria, no guidance on which parameters combine to answer which question.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources