Live review times for AI app stores: ChatGPT, Claude, Muse, Grok, Cursor. Check before you submit.
Scored across 3 tools
Each tool has a clearly distinct purpose: report_submission creates a data point, review_times queries aggregate statistics, and update_submission modifies an existing submission. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern: report_submission, review_times, and update_submission. The naming is predictable and easy to infer.
Three tools is appropriate for this focused domain: submit a wait time, query aggregate review times, and update a submission's status. Each tool fills a necessary role without redundancy.
The tool set covers the full lifecycle needed for crowdsourced review-time reporting: create a submission, read aggregated data, and update status including withdrawn. There are no obvious gaps or dead ends.
Add the user's own submission to a store so others can see real wait times. Only call with the user's permission and for a real submission. Returns a token for updating it later.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| note | No | Optional public note, max 280 chars | |
| store | Yes | ||
| status | Yes | ||
| decided_on | No | YYYY-MM-DD, required unless status is waiting | |
| submitted_on | Yes | YYYY-MM-DD |
| Name | Required | Description |
|---|---|---|
| error | No | |
| token | No | Private token for update_submission |
| update_url | No | Private page to update or delete the report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide generic false flags and do not disclose safety or mutation behavior. The description adds meaningful behavioral context: permission is required, submission must be real, and invoking the tool returns a token for future updates. This goes beyond the structured metadata and helps an agent understand side effects and ethical constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value: what the tool does, when it is allowed, and what it returns. There is no filler or repetition of schema fields. The critical ethical instruction is front-loaded in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need explanation. The description covers the tool's purpose, permission requirements, authenticity constraint, and update flow. The main remaining gap is semantic explanation for the three poorly documented parameters, but the overall call context is sufficiently clear for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with store, status, and kind lacking descriptions. The tool description does not explain these fields, their enum meanings, or how they relate to the submission. It only adds context about a token, which is not even a parameter. The description fails to compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Add the user's own submission to a store.' It also clarifies the purpose ('so others can see real wait times') and distinguishes this from the sibling update_submission tool by noting that a token is returned for later updates. This is more specific than the title alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for use: 'Only call with the user's permission and for a real submission.' It also scopes the tool to the user's own submission, implicitly excluding submissions on behalf of others. However, it does not explicitly name alternatives like update_submission or review_times, though the token note strongly implies the update path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How long AI app, connector and plugin stores take to review submissions. Omit store for all stores. Returns typical wait (median days to decision), counts, pace and how review works.
| Name | Required | Description | Default |
|---|---|---|---|
| store | No | Store slug or name: chatgpt, claude-connectors, claude-plugins, muse, grok, clawhub, cursor, copilot, gemini-cli, docker-mcp |
| Name | Required | Description |
|---|---|---|
| url | No | |
| name | No | |
| pace | No | |
| slug | No | |
| error | No | |
| counts | No | |
| stores | No | |
| vendor | No | |
| verdict | No | One-line answer to how long review is taking |
| docs_url | No | |
| submit_url | No | |
| last_approval | No | |
| last_decision | No | |
| how_review_works | No | |
| longest_seen_days | No | |
| typical_wait_days | No | Median days to a decision, counting submissions still waiting |
| oldest_waiting_days | No | |
| median_to_approval_days | No | |
| median_to_rejection_days | No | |
| typical_wait_is_lower_bound | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail by specifying what is returned (median days, counts, pace, how review works) and that omitting store means all stores.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core purpose is front-loaded, and the key usage nuance (omit store for all stores) is stated early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, full schema documentation, robust annotations, and an output schema, the description covers everything an agent needs to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional parameter is documented with examples in the schema. The description adds extra semantic value by explaining that omitting the store yields all stores, which is not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports how long AI app, connector, and plugin stores take to review submissions, naming the specific resource being queried. It also distinguishes this from the sibling submission-management tools by focusing on review times rather than report/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this tool to retrieve review times, and omitting the store returns all stores. It does not explicitly mention sibling alternatives, but the difference from report_submission and update_submission is strongly implied by the resource being described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a previously reported submission as still waiting, approved, rejected or withdrawn, using its token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| status | Yes | ||
| decided_on | No | YYYY-MM-DD |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the agent knows the safety profile. The description adds useful context: it targets an existing submission ('previously reported') and identifies it via 'its token,' which goes beyond what annotations or the schema convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the action and resource before enumerating statuses and the token requirement. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers the precondition, the allowed status values, and the identifier. An output schema exists for return values and annotations cover idempotency and non-destructiveness. Only minor details like where the token comes from and when decided_on is needed are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must partially compensate for undocumented parameters. It clarifies that token is the identifier for the submission, but does not explain token provenance or when decided_on is applicable. The status enum is already fully defined in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Mark'), the resource ('previously reported submission'), and enumerates the four valid statuses. The phrase 'previously reported' distinguishes it clearly from the sibling report_submission, so an agent can tell them apart without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite (the submission must have been reported first) but does not explicitly name alternatives or state when not to use this tool. Usage context is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
report_submission1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "token": {
+ "description": "Private token for update_submission",
+ "type": "string"
+ },
+ "update_url": {
+ "description": "Private page to update or delete the report",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}review_times1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "One store when store is given, otherwise every store under stores.",
+ "properties": {
+ "counts": {
+ "properties": {
+ "approved": {
+ "type": "number"
+ },
+ "rejected": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ },
+ "waiting": {
+ "type": "number"
+ },
+ "withdrawn": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "docs_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "error": {
+ "type": "string"
+ },
+ "how_review_works": {
+ "type": "string"
+ },
+ "last_approval": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_decision": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "longest_seen_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median_to_approval_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median_to_rejection_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "oldest_waiting_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pace": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "stores": {
+ "items": {
+ "properties": {
+ "counts": {
+ "properties": {
+ "approved": {
+ "type": "number"
+ },
+ "rejected": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ },
+ "waiting": {
+ "type": "number"
+ },
+ "withdrawn": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "docs_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "how_review_works": {
+ "type": "string"
+ },
+ "last_approval": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "last_decision": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "longest_seen_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median_to_approval_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "median_to_rejection_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "oldest_waiting_days": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pace": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "submit_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "typical_wait_days": {
+ "description": "Median days to a decision, counting submissions still waiting",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "typical_wait_is_lower_bound": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ },
+ "vendor": {
+ "type": "string"
+ },
+ "verdict": {
+ "description": "One-line answer to how long review is taking",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "submit_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "typical_wait_days": {
+ "description": "Median days to a decision, counting submissions still waiting",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "typical_wait_is_lower_bound": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ },
+ "vendor": {
+ "type": "string"
+ },
+ "verdict": {
+ "description": "One-line answer to how long review is taking",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}update_submission1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "status": {
+ "enum": [
+ "waiting",
+ "approved",
+ "rejected",
+ "withdrawn"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}report_submissionreview_timesupdate_submissionLive status, API pricing and rate limits for ChatGPT, Claude, Gemini, Cursor and 42+ AI tools.
Live status and health checks for AI coding providers: Claude, Cursor, Copilot, Codex and more.
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
App Store Optimization for AI agents: keyword ranks, suggestions, popularity, competitors, reviews
Add one secure layer between your agents and this server.
