Skip to main content
Glama
vom-core

storelift-mcp

get_weekly_plan

Read-onlyIdempotent

Fetches an app's prioritized weekly App Store or Google Play listing suggestions with proposed title, subtitle, and keyword changes, reasons, trade-offs, and confidence; empty when none are safe.

Instructions

This week's listing suggestions for the app — the same list as the dashboard's "This week" card, best first. A suggestion only appears when it passes strict checks: a keyword goes into the title or subtitle only if it is a core, high-demand term of the app's niche, the app already ranks #4–15 for it, rival apps above carry it in their name and it fits without dropping the brand or anything that ranks; niche or long-tail keywords go to the keyword field at most, only when there is room; other categories, other languages and keywords the user turned down never appear; nothing is suggested while a recent listing change is still settling (settling says until when). Each task has the sentence, the current and proposed text, the words it adds and removes, the reasons (measured facts), the trade-off and a confidence. Without country, all storefronts are merged and the same change is one task with its countries. Often empty — that is on purpose. Pro plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoaccepted for compatibility; suggestions are ordered by expected value
appIdYesapp id from list_apps
limitNotasks to return, 1–10 (default 5)
countryNoone storefront, e.g. tr, us (omit to merge all storefronts)
platformNostore (default ios)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/openWorld=false), the description discloses a great deal: the strict eligibility checks, empty-result behavior ('often empty — that is on purpose'), the settling-state suppression rule, country merging, and a 'Pro plan' requirement. This is exactly the behavioral context the annotations cannot carry.

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?

The purpose is front-loaded, which is good, but the body is one dense run-on block of comma-linked clauses that is hard to scan. Most sentences carry useful policy content, yet the overall size is larger than needed for an agent to act.

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

Completeness5/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 takes on the return-value burden and delivers: it enumerates each task's fields (sentence, current/proposed text, added/removed words, reasons, trade-off, confidence). Combined with the eligibility and empty-state notes, an agent has everything needed to call and interpret it.

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 100% so the baseline is 3, but the description adds real meaning: country omission merges storefronts and collapses the same change into one task with its countries. The goal parameter's compatibility-only role is noted too, adding slight value over the schema.

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 specific resource ('this week's listing suggestions for the app') and anchors it to a known dashboard card, distinguishing it clearly from apply-style siblings like update_listing or draft_listing. It does not, however, name any sibling tool to route between.

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 context is implied through the pointer to the dashboard's 'This week' card and the 'best first' ordering, but there is no explicit when-to-use / when-not-to-use guidance and no comparison to alternatives such as draft_listing or get_change_impact. The heavy policy prose describes what gets included, not which tool to pick.

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