AppSigma's App Store Data MCP
Server Details
Connect Claude, Cursor or any MCP client to AppSigma and let your AI research apps, read reviews and track rankings on its own – no glue code.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 21 of 21 tools scored. Lowest: 2.3/5.
Each tool targets a distinct data element (e.g., application details, chart history, reviews, ratings, in-app purchases, etc.) with no overlapping purposes, ensuring clear differentiation.
All tools follow a consistent `verb_noun` pattern (e.g., `get_application`, `get_chart_history`, `list_applications`, `search_applications`), using snake_case uniformly.
21 tools is slightly high but justified by the breadth of App Store data (applications, charts, reviews, ratings, etc.). Each tool covers a specific aspect without redundancy.
Covers major data categories (app details, search, list, versions, ratings, reviews, price changes, chart positions, similars, in-app purchases, events, editorial, developer info). Missing some potential aspects like app categories or usage stats, but core needs are met.
Available Tools
21 toolsget_applicationAInspect
Get one application by id (full detail). Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Application id (Apple track id) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Costs 1 credit', which is a behavioral trait beyond the schema. However, since there are no annotations, it does not cover authorization requirements, rate limits, or what 'full detail' entails. It is adequate but minimal.
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 very concise, consisting of two clear facts in 8 words. No unnecessary information.
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 the simple interface (1 param, no output schema) and many siblings, the description is adequate but could be more complete by hinting at the return structure or contrasting with other get_application_* tools.
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%, so the baseline is 3. The description adds no additional semantic information beyond what the schema already provides for the 'id' parameter.
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 'Get one application by id (full detail)', using a specific verb and resource. It distinguishes from sibling tools like get_application_versions or list_applications, which either return specific subsets or lists.
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 using this tool when you have a specific application ID and need full details, but it does not explicitly differentiate from list_applications or search_applications. No explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_chart_historyCInspect
Chart position history of an application. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Chart to read (top free / top paid / top grossing) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| genreId | No | Restrict to an App Store genre id | |
| daysPeriod | No | Look-back window in days | |
| maxPosition | No | Only chart positions from 1 to this rank | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions a cost of 2 credits, omitting critical behavioral traits such as whether the operation is read-only, rate limits, error conditions, or data structure nuances.
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 one sentence with no fluff. Every word is functional: it states the purpose and cost. No redundant or extraneous content.
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 5 parameters, no output schema, and no annotations, the description is insufficient. It lacks information about return values, error handling, and how results relate to sibling tools like get_application_rating_histogram.
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 high (80%), providing baseline meaning for parameters. The description adds no extra detail beyond the schema, so it neither improves nor reduces understanding.
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 returns chart position history of an application, which is a specific verb+resource combination. However, it does not differentiate from similar sibling tools like get_chart_history or get_chart_positions, leaving ambiguity about scope.
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?
No guidance on when to use this tool versus alternatives like get_chart_history. No mention of prerequisites or conditions. The only additional info is the credit cost, which does not address usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_editorial_itemsAInspect
App Store editorial stories featuring an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses pagination and credit cost, but lacks details on authentication, rate limits, or handling of missing data.
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?
Single sentence efficiently conveys purpose and cost. No wasted words, but could benefit from structured breakdown.
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?
No output schema, but for a simple paginated list tool, the description adequately covers what the tool does and its cost. Missing details on return structure, but overall sufficient.
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 covers 67% of parameters with descriptions. The description adds no extra parameter semantics beyond the schema. Baseline 3 is appropriate.
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?
Clearly states the tool retrieves 'App Store editorial stories featuring an application' and mentions pagination. Distinguishes from siblings like get_editorial_item (single item) and get_application (app info).
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?
Mentions credit cost per row, which gives some usage context, but does not explicitly state when to use versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_eventsBInspect
App Store in-app events of an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date, YYYY-MM-DD | |
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially fills the gap by disclosing pagination and a credit cost per row. However, it does not mention any side effects, authentication requirements, rate limits, or whether the operation is read-only, leaving significant behavioral aspects undisclosed.
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 short and front-loaded with the core purpose, then adds a cost note. It wastes no words, but could be better structured with a clear verb and separate usage 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?
Given no output schema, 4 parameters, and no annotations, the description is too brief. It does not explain what an 'in-app event' contains, how pagination works beyond basic params, or any result format. This leaves the agent with insufficient context to use the tool confidently.
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 75% (3 of 4 parameters documented). The tool description does not add any extra meaning beyond the schema's parameter descriptions (e.g., date format, default values). Thus it meets the baseline but does not enhance understanding.
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 'App Store in-app events of an application (paginated)' clearly identifies the resource (in-app events) and context (for an application), with a mention of pagination. It distinguishes from sibling tools like get_application_reviews or get_application_versions, though the verb 'get' is implicit.
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?
No guidance on when to use this tool over alternatives like get_application_editorial_items or get_developer_events. The only additional note is about credit cost, which aids decision-making but does not specify usage contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_in_app_purchasesAInspect
In-app purchases of an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses pagination and credit cost per row, which is useful. However, it does not state read-only nature, response format, or potential side effects.
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?
One sentence with essential information: what the tool returns, pagination, and cost. No unnecessary words.
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?
No output schema exists and no annotations are provided. The description is minimal but sufficient for a paginated list tool. It lacks details on response structure or any prerequisites beyond the required parameter.
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?
Two of three parameters have schema descriptions (page and perPage). The description adds 'paginated' context but does not describe the required 'applicationId' parameter. Baseline score of 3 is appropriate given 67% schema coverage.
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 it retrieves in-app purchases for a given application, specifying pagination and credit cost. It distinguishes well from sibling tools that focus on other app aspects like ratings, reviews, or versions.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or provide comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_price_changesBInspect
Price change history of an application. Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| daysPeriod | No | Look-back window in days | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait 'Costs 1 credit per row returned' which is valuable. Without annotations, it carries burden but does not disclose auth needs, rate limits, or whether it is read-only. It is adequate but minimal.
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 very short with two sentences. It front-loads the purpose and adds the cost note efficiently. No wasted words, though it could be slightly more structured.
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 the lack of output schema and context signals, the description is incomplete. It does not explain what the returned data looks like, whether pagination is needed, or what constitutes a price change. It leaves significant gaps 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?
The schema already describes both parameters with 50% coverage (daysPeriod has a description). The tool description does not add any additional meaning beyond what the schema provides.
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 returns price change history of an application. It is specific and distinguishes from sibling tools like get_application_chart_history. However, it could be more explicit that it returns a list of changes.
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?
No guidance is provided on when to use this tool versus alternatives like get_application_events or get_application_versions. There is no mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_rating_histogramBInspect
Star-rating histogram of an application over time. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Date, YYYY-MM-DD | |
| from | No | Date, YYYY-MM-DD | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only discloses the cost (2 credits) but does not specify if the tool is read-only, if there are rate limits, or any side effects. Behavioral traits beyond cost are absent.
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 sentences, front-loaded with purpose and immediately followed by cost. No redundant information. However, there is room to include more context without sacrificing conciseness.
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 no output schema, the description does not explain the structure of the histogram (e.g., what the bins are, count format). It also does not clarify the relationship between from and to parameters or default behavior. The tool is simple but the description is incomplete.
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 covers 67% of parameters with descriptions (from and to have 'Date, YYYY-MM-DD'). The description adds no additional meaning to parameters; applicationId lacks description in both schema and description. The tool description does not compensate for the missing parameter info.
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 returns a star-rating histogram of an application over time. It distinguishes from sibling tools like get_application_ratings_by_version (aggregated by version) and get_application_review_histogram (reviews vs ratings). The purpose is unambiguous.
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 mentions the cost (2 credits) but provides no guidance on when to use this tool versus alternatives like get_application_ratings_by_version. No explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_ratings_by_versionCInspect
Star ratings of an application broken down by version. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is the credit cost of 2 credits. With no annotations, the description should cover side effects, authorization needs, or rate limits, but it does not. The read-only nature is implied but not confirmed.
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 very concise with two sentences, no redundancy, and front-loads the core function. The credit cost is an efficient addition, though the description could benefit from slightly more structure.
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 tool with one parameter and no output schema, the description is insufficient. It does not mention what the response format looks like, whether pagination exists, or how versions are represented. Given the sibling tools, more context would help an agent choose correctly.
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?
The single parameter 'applicationId' has no description in the schema and is not explained in the tool description beyond being an identifier of an application. With 0% schema coverage, the description adds no meaning beyond the schema's type and constraints.
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 returns star ratings broken down by version, which is specific and distinct from sibling tools like get_application_rating_histogram or get_application_reviews. The verb 'get' is implied, and the resource and breakdown are explicit.
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?
No guidance is provided on when to use this tool versus alternatives such as get_application_rating_histogram. There is no mention of prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_review_histogramCInspect
Review-count histogram of an application. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a cost of 2 credits, which is a behavioral detail not in annotations. However, with no annotations provided, the description should disclose more about the tool's behavior, such as whether it supports date ranges or what the histogram bins represent. The cost alone is insufficient.
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 very short (two sentences) but fails to provide essential details. While brevity is valued, under-specification for a tool with 3 parameters and no schema descriptions makes it less useful. It is not appropriately sized for the tool's complexity.
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 the tool has 3 parameters, 0% schema coverage, no output schema, and no sibling differentiation, the description is far from complete. It lacks parameter explanations, usage context, and return value description.
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 0%, and the description does not mention any parameters. The required 'applicationId' and optional 'from' and 'to' are not explained, leaving the agent without necessary context for correct invocation.
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 it returns a 'review-count histogram of an application'. This verb+noun structure indicates the tool's purpose, but it does not explicitly differentiate it from similar siblings like get_application_rating_histogram or get_application_reviews.
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?
No guidance is provided on when to use this tool over alternatives. The description lacks context about prerequisites or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_reviewsAInspect
Customer reviews of an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| sort | No | ||
| score | No | Only reviews with this star score | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| countries | No | Storefront country codes | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It mentions pagination and credit cost, but lacks details on default sorting, data freshness, or side effects.
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?
Two efficient sentences with no wasted words. Front-loaded with core purpose, then additional cost note.
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?
Adequate for basic use but incomplete. No output schema or return format details leaves agent guessing about response structure.
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?
With 67% schema coverage, description adds minimal value beyond schema. Only mentions pagination, does not explain sort or applicationId semantics.
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?
Description clearly states 'Customer reviews of an application (paginated)' using specific verb and resource. Implicitly distinguishes from sibling histogram tools by specifying 'reviews' vs aggregated metrics.
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?
No explicit when-to-use or alternative guidance. Context of sibling tools suggests use case, but description does not differentiate from histogram tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_similarsBInspect
Apps similar to an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds value by disclosing pagination and the credit cost ('1 credit per row returned'). However, it lacks information on idempotency, authentication requirements, or what happens on invalid inputs. The bar is higher without annotations, and while the given details help, they are minimal.
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 extremely concise, consisting of one short sentence that communicates the purpose, pagination, and cost with zero filler. It is front-loaded and efficient, earning a top score.
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?
While the tool is relatively simple with 3 parameters and no output schema, the description omits details about the return format, what constitutes 'similar,' and how pagination works (e.g., default values are in schema but not restated). A more complete description would help agents understand expected output, especially without an output schema.
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?
The input schema covers 67% of parameters with descriptions (page and perPage), but applicationId lacks a description. The tool description does not add any parameter-specific meaning beyond what the schema provides, so it does not compensate for the missing description of applicationId. Baseline 3 is appropriate given moderate schema coverage.
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 that the tool returns 'Apps similar to an application' and mentions pagination, effectively communicating the core function and distinguishing it from siblings like search_applications. However, it could be more explicit by starting with a verb like 'Retrieve'.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., search_applications or get_application). There is no mention of prerequisites or context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_versionsBInspect
Version history of an application (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| applicationId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination and credit cost, which are useful. However, it fails to mention that the tool is read-only or what the response format is, leaving gaps in behavioral context.
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 that conveys the core purpose and a key behavioral trait (cost). No unnecessary words or repetition. It is front-loaded and efficient.
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 list tool with 3 parameters and no output schema, the description is sparse. It omits details like return format, ordering, authentication needs, and rate limits. Lacking annotations, the description should provide more contextual completeness.
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 67% (page and perPage have descriptions). The description adds no parameter semantics beyond the schema. The missing description for 'applicationId' is not compensated by the tool 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 identifies the resource ('version history of an application') and includes the key trait of pagination. It distinguishes from siblings like 'get_application' (single app) and 'list_applications' (list of apps), but lacks a specific verb like 'retrieve' or 'list'.
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?
No explicit guidance on when to use this tool versus alternatives. The cost warning ('1 credit per row') is a constraint, but there is no comparison to siblings like 'get_application' or other version-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chart_historyCInspect
App Store chart history across apps. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Chart to read (top free / top paid / top grossing) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| genreId | No | Restrict to an App Store genre id | |
| daysPeriod | No | Look-back window in days | |
| maxPosition | No | Only chart positions from 1 to this rank |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only mentions a cost of 2 credits but fails to disclose other behavioral aspects like rate limits, pagination, error conditions, or data structure, leaving significant gaps.
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 concise with two sentences, each serving a purpose: stating functionality and noting cost. It is front-loaded and avoids verbosity, though it could be slightly more informative without sacrificing brevity.
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 the tool has 4 parameters and no output schema or annotations, the description should provide more context about what 'chart history' entails, such as time-series data or response format. It is insufficient for the tool's complexity.
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% with descriptions already present for all parameters. The description adds no additional meaning beyond cost context, so it meets the baseline of 3 without exceeding it.
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 retrieves App Store chart history across apps. It is specific but does not differentiate from sibling tools like get_chart_positions, which might have overlapping functionality.
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 provides no guidance on when to use this tool versus alternatives. It only describes what it does, leaving the agent to infer appropriate use cases without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chart_positionsCInspect
Current App Store chart positions. Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Chart to read (top free / top paid / top grossing) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| genreId | No | Restrict to an App Store genre id | |
| maxPosition | No | Only chart positions from 1 to this rank |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a credit cost per row returned, which is a behavioral trait beyond annotations. However, with no annotations provided, the description fails to disclose other important behaviors like pagination, rate limits, or whether the tool is read-only. The credit cost is useful but insufficient.
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 very short (one sentence) and includes the critical credit cost information. However, it lacks structure and could be more informative without becoming verbose. It is concise but not optimally structured for an AI agent.
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 the tool has 3 parameters with full schema coverage, no output schema, and no annotations, the description provides minimal but adequate information: purpose and cost. It is missing guidance on when to use, return format, and limitations, but for a simple read tool it is sufficient.
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% with all parameters described in the input schema. The description adds no additional meaning to parameters beyond what the schema provides, resulting in no extra value. Baseline score of 3 is appropriate.
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 identifies the tool's function: retrieving current App Store chart positions. While it doesn't explicitly differentiate from siblings like get_chart_history, the name and context imply it's for current positions, making the purpose distinct and specific.
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?
No guidance is provided on when to use this tool versus alternatives like get_chart_history or get_application_chart_history. The credit cost is mentioned but not in a usage-directing way.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developerAInspect
Get one developer (publisher) by id. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Developer id (Apple artist id) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description adds behavioral info: 'Costs 1 credit'. It does not cover error handling or rate limits, but for a read-only get operation, this is fairly transparent.
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?
Two sentences, front-loaded with purpose, zero wasted words. Ideal conciseness.
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?
With no output schema, the description does not explain the return structure. For a simple get, it may be sufficient, but more detail would improve completeness.
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 parameter is well-described in the schema. The description ('by id') adds no additional semantics beyond the schema's 'Developer id (Apple artist id)'. Baseline 3 is appropriate.
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 'Get one developer (publisher) by id', using a specific verb and resource. It distinguishes from sibling tools like 'get_developer_applications' which retrieve lists.
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?
While it states the basic use case, it does not provide explicit guidance on when not to use this tool or mention alternatives. For a simple lookup, this is adequate but lacks the 'when-not' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developer_applicationsBInspect
Applications of a developer (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| sort | No | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| developerId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost per row returned, which is significant behavioral info. However, without annotations, it omits authorization needs, rate limits, and behavior for empty results or invalid parameters.
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?
Extremely concise: one sentence plus a crucial detail about cost. No wordiness, front-loaded with purpose.
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 tool with 4 parameters and no output schema, the description is too minimal. It does not explain pagination behavior, sorting, or return format, leaving the agent underinformed.
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?
The description does not add meaning beyond the input schema for the parameters. Schema coverage is 50% and description fails to explain the 'sort' enum or the exact meaning of 'developerId'.
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 it retrieves applications for a developer with pagination. It distinguishes from sibling tools like get_application (single app) and get_developer (developer info), but does not explicitly differentiate from list_applications or search_applications.
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?
No guidance on when to use this tool versus alternatives such as list_applications or search_applications. The description lacks context about prerequisites, filtering, or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developer_eventsAInspect
App Store in-app events across a developer’s apps (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, default 1 | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| developerId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by disclosing pagination and cost ('1 credit per row returned'). This adds behavioral context beyond the basic action. However, it does not mention rate limits, error scenarios, or empty result behavior.
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 a single, concise sentence that front-loads the primary action and key feature. No unnecessary words.
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 the lack of output schema, the description could be more complete by hinting at the return structure. It covers pagination and cost but omits details about event fields, sorting, or filtering. Siblings may provide similar patterns, but for a tool returning rows, more context is needed.
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 67% with descriptions for page and perPage. The description adds context about pagination and credit cost, which aids understanding of these parameters, but does not explain developerId or provide additional details beyond 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 clearly specifies the resource ('App Store in-app events'), the scope ('across a developer’s apps'), and key feature ('paginated'). It distinguishes from siblings like get_application_events (single app) and get_event (single event).
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 usage for fetching events across all apps of a developer, but does not explicitly state when to use this tool versus alternatives (e.g., per-app event tools). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_editorial_itemAInspect
Get one App Store editorial story by id. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the credit cost, which is a behavioral trait. However, it does not explicitly state that it is a read-only operation or disclose any side effects, though 'Get' implies read.
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 extremely concise: one sentence, 8 words. It is front-loaded with the purpose. No unnecessary words.
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 the simplicity (one parameter, no output schema), the description adequately covers the core purpose and cost. It could mention error cases (e.g., if id not found) but that is not essential. Overall sufficient.
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?
The description adds minimal meaning beyond the schema: it says 'by id', linking the required parameter to the identity of the editorial story. With 0% schema description coverage, this is helpful but lacks detail on the id's source or format.
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 action ('Get'), the resource ('App Store editorial story'), and the method ('by id'). It distinguishes from sibling tools which focus on applications, developers, and events.
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 when to use: when you need an editorial story by id. The cost hint ('Costs 1 credit') provides context. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventBInspect
Get one App Store in-app event by id. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It states credit cost and retrieval by id, but does not explicitly confirm read-only behavior, auth needs, or rate limits, though the verb 'Get' implies read-only.
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 a single, efficient sentence that conveys purpose and side effect (credit cost) with no waste.
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 low complexity and no output schema, the description adequately states purpose and cost but could be improved by indicating what fields or structure to expect in the return.
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?
With 0% schema description coverage, the description adds minimal value: 'by id' references the required parameter but offers no further detail on id format, constraints, or meaning beyond 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 clearly states 'Get one App Store in-app event by id', specifying the verb, resource, and scope, and distinguishes it from siblings like 'get_application_events'.
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 only mentions credit cost but provides no guidance on when to use this tool vs alternatives (e.g., get_application_events) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_applicationsCInspect
List and filter iOS App Store applications (paginated). Costs 1 credit per row returned.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Restrict to these application ids | |
| page | No | Page number, default 1 | |
| sort | No | ||
| term | No | Full-text filter | |
| device | No | ||
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| perPage | No | Items per page, default 25, max 100 | |
| withAds | No | ||
| features | No | ||
| genreIds | No | ||
| priceMax | No | Maximum price in cents | |
| priceMin | No | Minimum price in cents | |
| discounted | No | Only currently discounted apps | |
| preReleases | No | ||
| primaryGenre | No | Primary genre name | |
| filterDeleted | No | ||
| priceCurrency | No | ||
| advisoryRating | No | e.g. "4+", "12+", "17+" | |
| filterLowRated | No | ||
| minRatingScore | No | ||
| primaryGenreId | No | ||
| withAchievements | No | ||
| releasePeriodDays | No | ||
| excludePrimaryGenreId | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description adds pagination and credit cost, but lacks details on auth requirements, rate limits, side effects, or return behavior. Insufficient for a tool with zero annotation coverage.
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?
Two sentences, no waste, front-loaded with the core purpose. Efficient, though could expand on key aspects without losing conciseness.
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?
With 23 parameters, no output schema, and no annotations, the description is far too brief. Missing return format, error handling, rate limits, and parameter interdependence. Inadequate for the tool's complexity.
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 low (39%), and the description does not add meaning to the parameters beyond what the schema provides. The credit cost mention is unrelated to parameter semantics.
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?
Describes the tool as listing and filtering iOS App Store applications with pagination, using clear verb and resource. It is somewhat distinct from siblings like search_applications but lacks explicit differentiation.
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?
No guidance on when to use this tool versus alternatives like search_applications. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_applicationsAInspect
Search the iOS App Store by free-text term (proxies Apple iTunes Search). Costs 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term | |
| limit | No | Max organic results to return (Apple returns up to ~50; unlimited responses are very large — prefer 5-10) | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| country | No | Two-letter storefront country code, e.g. "us" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone must disclose behavior. It adds that the tool proxies Apple iTunes Search and costs credits, which is helpful. However, it doesn't mention pagination, error handling, or what happens with no results.
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?
Two concise sentences that include purpose, method, and cost. No unnecessary words, and critical information is front-loaded.
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 no output schema or annotations, the description provides essential usage context (free-text search, proxy source, credit cost). It lacks details on the return format, but for a search tool this is acceptable for basic user guidance.
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 descriptions cover all parameters (100% coverage), explaining their meaning and constraints. The overall description adds only the proxy context and cost; it does not further elaborate on parameter usage beyond what the schema already provides.
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?
Description clearly states verb 'Search', resource 'iOS App Store', and method 'by free-text term (proxies Apple iTunes Search)'. It is distinct from all sibling tools which retrieve specific app details or lists without free-text search capability.
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?
Implicit guidance is strong: use for keyword-based discovery, not for known app IDs (covered by siblings). Mentions cost of 5 credits, but lacks explicit exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!