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.
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.
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.
get_applicationAInspectGet 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a meaningful behavioral trait: 'Costs 1 credit', which informs the agent about potential rate or cost implications. However, it does not describe return format, error behavior, or any prerequisites, leaving some behavioral 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 extremely concise: two short sentences, each contributing unique information (purpose and cost). There is zero redundancy or wasted words, making it an exemplary model of efficient writing.
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 get-by-id tool, the description covers the core purpose and cost, and the schema handles parameters. However, 'full detail' is vague about return structure, and there is no mention of error cases or prerequisites. With no output schema, the description should provide a bit more about what the agent can expect, so it is adequate but with clear gaps.
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 both parameters (id and context) already well-described in the input schema. The description adds no additional meaning beyond 'by id' and 'full detail', which are more about purpose than parameter semantics, so it does not raise above the baseline.
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 uses a specific verb+resource combination ('Get one application by id') and clarifies it returns 'full detail'. This clearly distinguishes it from sibling tools like list_applications, search_applications, and the get_application_* sub-resource tools, as it is the canonical fetch for a single application's complete data.
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 phrase 'by id' implies that this tool is for when you have a known application id and want its full detail, which is a clear use case. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for specific data like ratings or reviews, use the dedicated sibling tools), so the guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_chart_historyBInspectChart 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 |
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 that the tool costs 2 credits, which is useful, but it does not mention whether the operation is read-only, any prerequisites, or what the response contains. The cost note is the only behavioral trait disclosed.
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 with no filler. It states the core action in one clause and adds the cost note in a second. Every word earns its place, achieving maximum efficiency.
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?
Despite having 6 parameters and no output schema, the description is minimal. It does not explain parameter interactions, return format, pagination, or how the tool fits into broader workflows. The cost note is helpful but insufficient for a tool of this 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 83%, so most parameters are already explained. The description adds no parameter-level detail beyond the schema; it only mentions the cost. With high schema coverage, a baseline 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 states the tool retrieves chart position history for a specific application, which is a clear verb+resource+scope. It does not explicitly contrast with sibling tools like get_chart_history or get_chart_positions, but 'of an application' narrows its purpose sufficiently.
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 use when an application's chart position history is needed, but provides no explicit guidance on when not to use it or which alternative tool to choose. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_editorial_itemsAInspectApp 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses pagination and the credit cost per row, which are useful behavioral traits. However, it does not describe the return format, any potential auth requirements, or error behavior, leaving gaps for a tool with no output schema.
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 core purpose ('App Store editorial stories featuring an application') and appends two key modifiers (paginated, credit cost). There is zero fluff; every word contributes, making it highly scannable.
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 paginated list tool with no output schema and no annotations, the description is minimally adequate. It tells the agent what data is returned (editorial stories) and the cost/pagination behavior, but omits details about the response structure and required permissions, which could reduce the agent's ability to correctly parse results.
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 75%, with descriptions for page, context, and perPage. The description adds minimal semantic value by mentioning 'application' (mapping to applicationId) and 'paginated' (relating to page/perPage), but it does not elaborate on parameter specifics or edge cases. The baseline of 3 applies since coverage is high.
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 what the tool does: it returns App Store editorial stories featuring a specific application, with pagination. It distinguishes from sibling tools like get_editorial_item (singular) and other get_application_* tools by focusing on editorial items for an app, though it lacks an explicit verb like 'list' or '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?
The description implies usage: to retrieve editorial stories for an application. However, it provides no explicit when-to-use/when-not-to-use guidance or alternatives, such as mentioning that get_editorial_item should be used for a single story. The cost per row hints at selective use but not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_eventsAInspectApp 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about pagination and credit cost per row, but does not describe what an 'in-app event' includes, any authentication requirements, or potential errors, leaving significant behavioral aspects unstated.
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, front-loaded sentence conveys the essential purpose and key behavioral traits with no filler. Every word 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?
The description is adequate for a simple paginated list tool given the schema's parameter descriptions, but it omits what constitutes an 'event' and any return-value structure. Since there is no output schema, a bit more detail on the returned data 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 description coverage is 80%, so the schema already documents most parameters. The description adds a note about pagination and per-row cost, which aligns with page/perPage parameters, but provides no additional parameter-level 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 identifies the tool as retrieving App Store in-app events for a specific application, with pagination noted. This distinguishes it from sibling tools like get_developer_events (developer-scoped) 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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool might be more appropriate, leaving the agent to infer usage solely from the resource scope.
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_purchasesBInspectIn-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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that results are paginated and that credits are consumed per row, which is useful. However, it does not disclose the return format, ordering, authentication requirements, or error behavior, 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 and front-loaded: two short sentences immediately state the tool's purpose and a key operational detail. Every word earns its place, and there is no redundancy or filler.
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 that there is no output schema and no annotations, the description should explain what the returned data contains, but it only states 'in-app purchases of an application' without detailing fields, ordering, or any other response characteristics. The cost and pagination info is helpful but insufficient for full context in a tool with sparse structured metadata.
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 documents 3 of 4 parameters with descriptions, providing a high coverage baseline. The description adds little beyond the schema, except an implicit link between perPage and credit costs. The applicationId parameter lacks a schema description but is self-explanatory; the tool description does not compensate for this gap.
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 'In-app purchases of an application (paginated)' clearly identifies the resource being retrieved, though it lacks an explicit verb like 'retrieves' or 'lists'. It distinguishes itself from sibling tools by specifically targeting in-app purchases, a unique resource type.
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 a cost-related usage consideration ('Costs 1 credit per row returned') but offers no explicit guidance on when to use this tool versus alternatives. The intended use case is implied by the tool name and context, but there is no direct mention of alternatives 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_price_changesBInspectPrice 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'Costs 1 credit per row returned', which is valuable for cost management. However, it does not mention any other behavioral aspects such as pagination, ordering, or the shape of the returned data, so it's only partially 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?
The description consists of two short sentences that directly state the purpose and a critical cost fact. There is no verbosity or irrelevant information, making it highly concise and well-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?
The tool has no output schema and no annotations, so the description should ideally explain what the response contains or how to interpret rows. It only mentions the cost per row, leaving the return structure and pagination to the user's imagination. This is insufficient for a tool with no other structured documentation.
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 already describes 'context' and 'daysPeriod' clearly, and 'applicationId' is self-explanatory from its name. The description adds no additional parameter meaning, but the schema covers 67% of parameters, which is moderate. The description does not compensate for the undocumented 'applicationId', but its meaning is obvious.
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 as 'Price change history of an application', which distinguishes it from sibling tools like get_application_reviews or get_application_versions. However, it lacks an explicit verb ('Retrieve', 'List'), making it slightly less direct but still 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 provides no explicit guidance on when to use this tool versus alternatives. The pricing note ('Costs 1 credit per row returned') indirectly suggests cost considerations, but it doesn't mention any exclusions or alternative tools. The usage is only implied by the tool name and resource description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_rating_histogramBInspectStar-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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the credit cost and the 'over time' dimension, adding behavioral context beyond the schema. However, with no annotations, the description carries the full burden and lacks detail on return format, histogram bins, or potential pagination, leaving significant ambiguity.
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, immediately stating purpose and cost. Excellent front-loading with no filler or repetition—every word 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?
With no output schema, no annotations, and a minimal description, the tool's expected response and usage context are unclear. Sibling tools offer similar functions, and the description doesn't clarify when this is the best choice or what the histogram actually represents beyond 'over time'.
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 no parameter-level information. Schema covers 75% of parameters (from, to, context) but applicationId lacks description; the ID name is self-explanatory. Since the description doesn't compensate for the moderate coverage, it falls short.
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 the tool returns a 'star-rating histogram of an application over time', identifying the resource and data type. The temporal scope helps distinguish it from version-based or review-based siblings, though it doesn't explicitly name alternatives.
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_application_review_histogram or get_application_ratings_by_version. The only operational hint is 'Costs 2 credits', which is not a usage guideline.
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_versionCInspectStar 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions the credit cost but does not clarify whether the call is read-only, requires authentication, or has rate limits. The return format and potential side effects are also unspecified, which is inadequate given the absence of annotations.
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 exceptionally concise, using just two short sentences. It front-loads the primary purpose and then adds the cost detail in a separate sentence. Every word is meaningful, and there is no redundancy or filler.
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 or annotations, the description must carry more contextual weight. It fails to explain the return structure, what fields are included, or any operational constraints beyond the credit cost. The context parameter requirements are documented in the schema, but the description adds minimal value, making the tool under-specified 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 50%, with only the context parameter well-described. The tool description does not elaborate on applicationId or its role in the query, nor does it explain how parameters map to the output. This does not compensate for the undocumented applicationId parameter, leaving semantic 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 clearly states the resource (application star ratings) and the breakdown by version, which distinguishes it from similar sibling tools like get_application_rating_histogram. However, it lacks an explicit verb (e.g., 'retrieves') and does not explicitly reference alternative tools, so it falls short of a perfect score.
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 such as get_application_rating_histogram or get_application_reviews. No prerequisites, scenarios, or when-not-to-use instructions are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_review_histogramCInspectReview-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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavior. It only mentions 'Costs 2 credits', but does not describe whether the operation is read-only, the return format, any required permissions, or limitations. The behavior beyond cost is opaque.
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 at two short sentences, with the first stating purpose and the second noting cost. It is efficiently worded, though it is under-specified rather than merely concise.
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 (2 required), no annotations, and no output schema, the description is notably incomplete. It does not explain the histogram's parameters, return values, or how it differs from closely related siblings, leaving critical 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?
Schema description coverage is only 25% (only 'context' is described). The tool description does not clarify parameters like 'from' and 'to', which are ambiguous as integers (dates? counts?). It adds no meaning beyond the schema, failing to compensate for the low 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 'Review-count histogram of an application' clearly identifies the tool's output as a histogram of review counts for a specific application. It distinguishes from sibling 'get_application_rating_histogram' by specifying 'review-count' vs. 'rating', though it lacks an explicit verb (e.g., 'retrieves') and relies on the tool name for the action.
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 like get_application_rating_histogram or get_application_reviews. The only additional context is the credit cost, which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_reviewsBInspectCustomer 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: pagination and credit cost per row. With no annotations provided, these additions are valuable. However, it omits other potentially relevant behaviors like default sorting, response structure, or rate limits, leaving the agent partially informed.
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 two short sentences that front-load the primary purpose and critical cost detail. Every word earns its place, with no redundancy.
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 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain response format, pagination mechanics, how to choose sort options, or when to use filters. It leaves the agent to figure out many operational details from the schema alone, which is insufficient for a complete understanding.
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 71%, which is not high enough to rely solely on the schema. The description adds no parameter-specific meaning beyond the schema, and it does not explain how parameters like sort, score, countries, or perPage interact with the returned rows. The only indirect hint is that perPage affects cost, but this is not explicit.
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 (customer reviews of an application) and notes pagination, distinguishing it from sibling tools like rating_histogram or reviews_by_version. However, it lacks an explicit verb (e.g., 'retrieves' or 'lists'), relying on the tool name to imply the action.
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. It does not mention scenarios, prerequisites, or exclusions. The agent must infer usage solely from the name and schema, with no hint of how it differs from related review tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_similarsBInspectApps 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose pagination ('paginated') and a per-row credit cost, which are useful behavioral traits. However, it does not describe the return format, any ordering, or whether it is a safe read operation, leaving important context unaddressed.
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 exceptionally concise, consisting of two short sentences that immediately convey the core purpose, pagination behavior, and cost. No filler words or redundancy.
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?
The tool is relatively simple, but the description does not explain what 'similar' means, how results are ordered, or what the response contains. Given no output schema and no annotation, the description leaves some gaps, though pagination and cost are noted. It is adequate but not complete for a tool with this level of context.
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%, leaving applicationId undocumented in the schema. The description's phrase 'similar to an application' gives some semantic context for applicationId, but it does not add syntax or format details. Other parameters (page, perPage, context) are already well-described in the schema, so the description adds marginal value.
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 'Apps similar to an application' clearly identifies the resource and scope, distinguishing it from sibling tools that handle reviews, versions, or developer data. However, it lacks an explicit verb like 'Retrieves' or 'Lists', so it is not a fully specific verb+resource statement.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The only usage-related information is the credit cost, which is a cost constraint, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_versionsBInspectVersion 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly mentions that results are paginated and that each row costs 1 credit, which is valuable. However, it does not disclose the return structure or any side effects, though the read-only nature is implicit in 'version history'.
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 core purpose ('Version history of an application') followed by two key behavioral notes (paginated, cost). Every word earns its place, and there is no redundancy.
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 four parameters, no output schema, and no annotations, the description is insufficiently complete. It omits return format, ordering, error behavior, and any prerequisites. The cost note is helpful, but agents still lack context on what a 'version' contains and how to interpret results.
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 no parameter-specific meaning beyond the schema. Schema coverage is 75% (three of four parameters have descriptions), but the description does not compensate for the undocumented applicationId or clarify usage of page/perPage. The pagination mention is generic, not tied to specific parameters.
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 as retrieving version history for an application, with a specific resource (application versions) and an implied 'get' action. This distinguishes it from sibling tools like get_application_ratings_by_version or get_application_events, which target different data aspects.
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 given on when to use this tool versus alternatives, such as get_application or get_application_reviews. The description only notes pagination and cost, leaving the agent to infer appropriate use cases from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chart_historyCInspectApp 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the name's implied 'get', the description discloses only the credit cost. With no annotations, the full burden falls on the description, but it fails to state whether data is historical time-series, what date range is covered, or how results are returned.
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 short sentences deliver purpose and cost without redundancy. However, the brevity risks under-specification for a tool with 5 parameters, though the schema compensates for parameter details.
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 and no annotations, the description should explain return shape and parameter interplay. It only states the general resource and cost, leaving the agent to infer behavior for genreId, daysPeriod, maxPosition, and possible pagination. This is insufficient for a tool with 5 parameters.
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?
All 5 parameters are fully described in the schema, including enum values for type and constraints for daysPeriod/maxPosition. The tool description adds no additional parameter context, so the schema carries the weight; the description does not mention that daysPeriod limits look-back or that maxPosition filters ranks.
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 identifies the resource ('App Store chart history') and scope ('across apps'), which differentiates it from sibling get_application_chart_history. However, it lacks a direct verb like 'retrieves' or 'lists', making it less explicit than ideal.
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 mention of when to use this tool versus alternatives. It does not reference sibling tools like get_application_chart_history or get_chart_positions, nor any scenario-based guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chart_positionsCInspectCurrent 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses 'Costs 1 credit per row returned,' which is a helpful behavioral detail, but it doesn't clarify that the operation is read-only, what the return format is, or any other side effects. For a simple read tool, cost disclosure 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?
Two short sentences with the purpose front-loaded and the cost detail earning its place. It is highly concise, though bordering on under-specification, but every word is meaningful.
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 and no annotations, the description should explain what a 'row' contains or how the results are structured. It doesn't describe the return format, the required context parameter's role, or how the type/genreId/maxPosition parameters shape the output. Lacks enough context for the agent to set expectations.
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 100%, so the baseline is 3. The description adds no parameter-specific meaning; the cost note is tangential and doesn't relate to how genreId or maxPosition affect results.
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 'Current App Store chart positions' is a noun phrase without a verb, relying on the tool name for action. It vaguely indicates current data and distinguishes from history tools via 'Current,' but doesn't mention the chart types (FREE/PAID/TOP_GROSSING) or what 'positions' entails.
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 or get_application_chart_history. The word 'Current' implies using it for present-time positions but doesn't explicitly state when not to use it or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developerAInspectGet 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." |
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 adds a unique behavioral note that the call 'Costs 1 credit', and the verb 'Get' implies a read operation. However, it does not disclose expected return format, error behavior, or idempotency, leaving some transparency 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 exceptionally concise, consisting of two short sentences that convey the core function and the associated cost. Every word is informative and there is no redundant or vague phrasing.
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 get-by-id tool with fully documented parameters and no output schema, the description is nearly sufficient. It states what it retrieves, by what key, and the cost. However, since there is no output schema, a brief mention of the return value (the developer object) would make it fully complete, but the current level is adequate given the low 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?
The schema already provides 100% coverage for both parameters, including a clear description of 'id' (Apple artist id) and a detailed explanation for 'context'. The tool description only mentions 'by id', adding no extra semantic value beyond the schema, so the 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 states the action ('Get') and the resource ('one developer (publisher)') with the key identifier ('by id'). This distinguishes it from sibling tools like get_developer_applications or get_developer_events, which retrieve related data rather than the developer entity itself.
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 use when you have a developer id, but does not explicitly mention when to use this tool versus alternatives or provide any exclusionary guidance. While the name and action are clear, there is no direct comparison to sibling tools or note on when another retrieval method would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developer_applicationsBInspectApplications 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds cost information (1 credit per row) and pagination, which are useful. However, there are no annotations, so the description must disclose more about safety, permissions, or output format, but it does not. It implies a read operation but doesn't state it explicitly.
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?
At 8 words, it is very concise and front-loaded. However, it is almost too terse, lacking a verb. It is not bloated, but under-specified.
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 5 parameters, no annotations, and no output schema, this description is inadequate. It provides cost but not enough context about use cases, return data, or limitations. The sibling tools suggest various application-related queries, and this one needs clearer differentiation.
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 covers 60% of parameters with descriptions, including page, context, and perPage. The description simply says 'paginated' which is indirect. It does not add meaning about developerId or sort beyond the schema. Since coverage is moderate, the description should compensate but doesn't significantly.
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 identifies the resource (applications) and scope (of a developer) but lacks an explicit verb, relying on the tool name. It mentions pagination. It does not explicitly distinguish from sibling tools like list_applications or search_applications, though 'of a developer' implies a specific filter.
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. It does not mention that list_applications might be for general listing or search_applications for search. It only states what it returns and the cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_developer_eventsAInspectApp 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses two important behaviors: pagination and a credit cost per row returned. However, it does not mention authentication requirements, response shape, or potential side effects, leaving some 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 a single sentence that front-loads the core function, then adds the critical cost disclosure. Every word earns its place, with no redundancy or filler.
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 paginated list with no output schema, the description covers the essential context: what is returned (in-app events), scope (all developer apps), pagination, and cost. It does not explain event details or ordering, but given the tool's simplicity and sibling context, this is sufficiently complete.
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 75%, and the description adds no parameter-specific information beyond what the schema already states. Since the schema covers page and perPage, the baseline of 3 applies; developerId still lacks a description, but the description does not compensate for that.
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 uses a specific verb phrase 'App Store in-app events' and clearly scopes it to 'across a developer’s apps', which distinguishes it from sibling tools like get_application_events that target a single app. The 'paginated' qualifier also hints at the endpoint's behavior.
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 implicitly indicates when to use this tool (when needing events across a developer's entire app portfolio) but does not explicitly mention alternatives or exclusions. It lacks a statement like 'use get_application_events for a single app', so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_editorial_itemAInspectGet 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses a meaningful behavioral trait by stating 'Costs 1 credit' and indicates a read operation via 'Get', but it does not mention authentication requirements, not-found behavior, rate limits, or response format. This is adequate but not rich.
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 short sentences: 'Get one App Store editorial story by id.' and 'Costs 1 credit.' Both are front-loaded and contain essential information with no filler or redundant 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?
For a simple get-by-id tool, the description plus the schema covers the essential invocation requirements: purpose, id semantics, context parameter, and credit cost. However, since there is no output schema, return-value details are not described, and no comparison to sibling tools is provided. This is slightly incomplete but overall adequate for a tool of this 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?
The context parameter has a detailed schema description, so no additional explanation is needed there. The id parameter is only an integer in the schema, and the phrase 'by id' adds the key semantic that it identifies which editorial story to retrieve. Thus the description compensates well for the partially undocumented 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?
Description uses a specific verb 'Get' with a clear resource 'one App Store editorial story' and scope 'by id', which clearly differentiates it from sibling get_application_editorial_items that lists editorial items for an application. The purpose is immediately understandable and cannot be confused with other sibling tools.
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 about when to use this tool versus alternatives like get_application_editorial_items or get_event. The phrase 'by id' implicitly suggests using it when an ID is already known, but there are no explicit usage exclusions, prerequisite conditions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventAInspectGet 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." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful behavioral trait that the tool costs 1 credit, which is not in the schema. However, it does not explicitly state that the operation is read-only, nor does it describe error handling or prerequisites. Since no annotations are provided, the description carries the full burden but only partially addresses it.
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, compact sentence with no redundant words. It front-loads the purpose and adds a relevant cost detail, making every word valuable.
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 get-by-id tool with low complexity, the description covers the core purpose and cost. It does not explicitly describe the return value, but that is generally understood for a 'get' tool. Given the absence of annotations and output schema, it could be more complete, but it is adequate for the tool's simplicity.
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 clarifies that the 'id' parameter is the identifier of the in-app event, providing meaning beyond the schema's bare integer type. The 'context' parameter is already well-described in the schema, so the description's minimal mention is sufficient. This compensates for the 50% schema description 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 the tool retrieves a single App Store in-app event by its ID, using a specific verb and resource. This distinguishes it from sibling tools like get_application_events, which likely list events. The mention of 'App Store in-app event' adds specificity.
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 phrase 'Get one ... by id' provides a clear context: use this tool when you need a specific event's details. However, it does not explicitly state when not to use it or name alternatives, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_applicationsCInspectList 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses two useful behaviors: pagination and credit cost per row returned. However, it does not disclose return format, filtering semantics, sorting defaults, or authentication needs, which are significant omissions for a 24-parameter tool.
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 and front-loaded, with no wasted words. However, it is under-specified for a tool with 24 parameters and a complex filter interface; concise is not appropriate when critical context is missing.
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 high parameter count, absence of annotations, and no output schema, the description is far from complete. It does not explain return values, pagination details like page size, or how filtering works, leaving the agent without essential information to use the tool 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?
Schema description coverage is only 42%, and the description adds no parameter-specific information beyond the generic term 'filter'. It does not mention ids, page, sort, device, price filters, or any of the 24 parameters, failing to compensate for the low 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 the tool lists and filters iOS App Store applications with pagination. It distinguishes from singular get_* tools, though it does not explicitly differentiate from search_applications, which is a sibling that could overlap.
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 like search_applications or get_developer_applications. It implies usage for browsing/filtering apps but does not state exclusions or provide context for selecting this tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_applicationsAInspectSearch 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" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 5-credit cost and the proxy behavior, but doesn't mention the return format, error handling, or any side effects beyond the cost. This is minimal behavioral disclosure.
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 succinct sentence plus a short cost note. It's front-loaded with the action and contains zero filler, making it highly concise.
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 search tool with four parameters and no output schema, the description covers the essential purpose and cost. It doesn't describe the return structure, but the expected result (search results) is fairly inferable from the action.
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 100%, so all four parameters are already documented. The description's phrase 'free-text term' lightly aligns with the term parameter, but adds no significant semantic value 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 the tool searches the iOS App Store by free-text term, distinguishing it from the sibling get_* tools which retrieve specific entities. The proxy note adds specificity about its underlying data source.
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?
It clearly indicates use for free-text searching of the App Store, implying when a keyword-based lookup is needed. It doesn't explicitly mention alternatives or when not to use, but the context is clear given the sibling set.
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.
No comments yet. Be the first to start the discussion!
