io.github.gjeltep/app-store-connect-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation4/5
Each tool targets a distinct resource and action within its category. The analytics tools follow a clear hierarchy (requests -> reports -> instances -> segments) that is discernible from descriptions, though the naming could be clearer. No two tools appear to do exactly the same thing.
Naming Consistency3/5
Most tools follow a resource_action pattern, but analytics tools mix conventions: e.g., 'reports_list_instances' vs 'analytics_report_requests_list' vs 'report_requests_get'. Nested list tools use a different word order than top-level lists, and 'builds_start_by_ref_id' is an outlier. Still, names are generally readable and predictable within categories.
Tool Count2/5
40 tools is well above the 25+ threshold for heavy tool sets. While they cover a broad API, many are simple list/get variations, and an agent would be overwhelmed. Some consolidation (e.g., combining list and search, or using parameters for different resource hierarchies) could reduce the count.
Completeness2/5
The server covers analytics, reviews, crash reports, user management, and Xcode Cloud, but omits major App Store Connect areas like app metadata, TestFlight builds/beta groups, certificates, devices, and in-app purchases. Within included domains, coverage is fairly thorough, but the overall surface is incomplete for a server claiming to be an App Store Connect MCP.
Average 3.3/5 across 40 of 40 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only states 'get detailed information' without revealing what that entails (e.g., fields returned, permissions, pagination). It is not misleading but is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. However, it is under-specified relative to the tool's requirements, and its brevity borders on insufficient rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and an output schema, but the description does not clarify what 'detailed information' means, the role of the include parameter, or any preconditions. While the output schema reduces the need to document return values, the description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 either parameter (submission_id or include). The agent is left without any explanation of what these parameters mean or how to use them, making it impossible to invoke the tool correctly beyond guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific crash submission, with a specific verb and resource. It distinguishes from list/search siblings by emphasizing specificity and detail, though it does not 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus crashes_list, crashes_search, or crashes_get_log. The single sentence implies it is for a specific crash but provides no context on selecting it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'List customer reviews' and offers no details about pagination, sorting, filtering capabilities, or any side effects (though likely read-only). This is a minimal restatement of the tool's core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than concisely informative. It does not earn its place because it fails to convey necessary context about parameters or usage; this is closer to under-specification than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no parameter descriptions, the description is incomplete. Although an output schema exists (so return values are covered), the lack of usage guidance, parameter semantics, and behavioral detail leaves significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 of the 5 parameters (sort, limit, app_id, filters, include). The description adds no meaning beyond the schema's type definitions, which lack semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('customer reviews'), with scope ('for an app'). It is unambiguous about the tool's function, but it does not differentiate from sibling tools like reviews_search or reviews_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as reviews_search for filtered queries or reviews_get for individual reviews. The description lacks any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It only states 'search' without explicitly confirming that the operation is read-only, nor does it mention pagination, sorting defaults, authentication, or any side effects. This minimal disclosure falls short for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes few words. However, the '[App]' prefix is unnecessary clutter, and the lack of any additional structure makes it overly terse for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no annotations, and only a vague one-sentence description, the tool is severely under-specified. The output schema exists but does not clarify filter interactions or usage context. This is completely inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its 14 parameters, and the description does not compensate by explaining any parameter meanings. Terms like 'body_contains' and 'created_since_days' are left entirely to inference, and 'advanced filtering' is too vague to clarify individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as searching customer reviews with advanced filtering, using a specific verb and resource. However, it does not differentiate it from the sibling tool reviews_list, which may also support listing/filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like reviews_list or reviews_get. It lacks any contextual triggers, exclusions, or references to sibling tools, leaving the choice entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses the default and maximum limit and pagination metadata; it omits any side effects, permissions, rate limits, or what the search actually does with the filters. This is minimal for a complex search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the most operationally important note (limit/pagination). However, it is under-specified for a tool with 14 parameters; the brevity comes at the cost of essential context, making it less effective than a more balanced length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain how to structure searches, interpret pagination metadata, or which filters are mutually exclusive. The tool is complex and lacks annotations, so the description should provide more contextual guidance; it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage across 14 parameters. The description adds meaning only for 'limit' (default 25, max 200), but none of the other 13 filter parameters (e.g., app_id, os_versions, created_after) are explained. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search crash submissions with advanced filtering'—a specific verb, resource, and scope. The phrase 'advanced filtering' hints at differentiation from simpler sibling list tools, although it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is about pagination limits and defaults ('Default limit is 25... Max 200. Use pagination metadata for additional pages'), but it does not explain when to use this tool over crashes_list or crashes_get_by_id, nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'List issues for a build'. It does not mention whether this is a read-only operation, how pagination works via the limit parameter, whether issues include warnings/errors, or any rate limits. The minimal wording provides only the most basic expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the category tag and clearly states the action and object. There is no fluff or redundant information. However, the brevity edges toward under-specification, losing points for not including any usage context within the same tight structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set and the presence of an output schema, the description is too sparse to provide complete context. It does not explain what 'issues' means (e.g., build errors, warnings, test failures), how the result set is ordered, or any interaction with other tools. The tool is simple, but the lack of guidance makes it inadequate for an agent to select confidently among many list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate. It clarifies that 'build_id' is the relevant identifier for the build, but says nothing about the 'limit' parameter or its default value. The description adds only minimal semantic value beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'List' and resource 'issues for a build', making the core purpose clear. However, it does not differentiate from sibling tools like crashes_list or test_results_list, which also operate on build-related data. The bracketed '[XcodeCloud/BuildArtifacts]' adds a category hint but not enough to distinguish it from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as crashes_list, test_results_list, or builds_list. The description only says 'List issues for a build' without mentioning preferred use cases, prerequisites, or exclusions. This leaves the agent to infer when 'issues' are the target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Create', implying a write operation, but does not mention side effects, authorization requirements, response behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler and the category label is front-loaded. However, it is somewhat under-specified for a tool with an opaque parameter, though this is more a completeness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not provide enough context given the open-object parameter and lack of annotations. It fails to describe the request format, any constraints, or expected outcomes, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'request_data' parameter with 0% coverage and additionalProperties true. The description does not explain what fields or structure request_data should have, leaving the agent with no guidance on how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and resource 'analytics report request', clearly distinguishing this from sibling read/list tools. The '[Analytics/Requests]' prefix adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like report_requests_get or analytics_report_requests_list. The usage is implied but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that it returns 'detailed information' without clarifying whether this is read-only, what data is included, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, making it easy to parse. However, 'detailed information' is vague and could be more specific without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex domain with many report-related sibling tools and no annotations, this minimal description lacks essential context about what constitutes an 'analytics report' versus report requests/instances. The presence of an output schema helps with return values but the description still doesn't provide enough context for correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies report_id identifies the specific report but gives no explanation of the 'include' parameter, leaving its purpose and allowed values ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies the resource as 'a specific analytics report', clearly indicating a read operation targeting a single report by ID. It is distinct from list tools, but it doesn't explicitly differentiate from sibling get tools like report_requests_get or report_instances_get, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as report_instances_get or report_requests_get. There are no usage scenarios or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 claims to list 'all' products, but the input schema includes a 'limit' parameter (default 50), implying pagination or truncation. The description does not disclose this or any other behavioral traits such as pagination, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly communicates the core purpose, though it could earn a higher score with more contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description is incomplete for a tool with three optional parameters and no annotations. It fails to mention filtering, included relationships, or pagination behavior, leaving the agent to guess how parameters affect the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the three parameters (limit, filters, include). The description adds no meaning beyond the schema's bare property definitions, leaving the agent without any semantic understanding of how these optional parameters affect the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Xcode Cloud products. The verb 'List' and resource 'Xcode Cloud products' are specific, and the scope 'all' distinguishes it from the singular 'products_get' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternatives like products_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states that it 'gets' information, which implies a read operation, but does not disclose error handling, authentication needs, pagination, or the nature of 'detailed information'. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. The category prefix '[Analytics/Reports]' adds minimal context but could be considered fluff. Still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, low schema coverage, and an output schema, the description is too sparse. It does not explain the purpose of the 'include' parameter, nor any conditions for using this tool. While the output schema may cover return values, the description fails to provide sufficient context for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. However, the description does not mention either parameter ('instance_id' or 'include'). 'instance_id' is self-explanatory from its name, but 'include' is obscure (likely an array of fields) and the description provides no clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('detailed information about a specific analytics report instance'), distinguishing it from sibling tools like report_requests_get or report_segments_get. The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or common scenarios. The sibling list includes many similar report-related tools, but the description offers no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Get' implies a read-only operation, but the description does not explain the behavior of the 'include' parameter, potential errors, or any access requirements, leaving ambiguity beyond the basic fetch action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant filler. It states the verb and object directly, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and the tool is relatively simple, the description omits crucial context about the 'include' parameter and any usage distinctions from sibling tools. This makes the description incomplete for an agent that needs to correctly invoke the tool with meaningful options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The phrase 'a specific customer review' implicitly refers to review_id, but the 'include' parameter is completely unexplained, and its default null behavior is unclear without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'a specific customer review,' which clearly distinguishes this single-item retrieval tool from sibling tools like reviews_list and reviews_search. It does not explicitly mention the review_id parameter by name, but 'specific' implies lookup by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as reviews_list or reviews_search. There is no mention of suitable scenarios, prerequisites, or exclusions, so an agent receives no help in choosing among the review-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination, the effect of the 'limit' or 'include' parameters, potential side effects, or read-only status. This is a significant gap for a tool with no safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with a domain prefix, making it highly concise and front-loaded. It avoids redundancy, but its brevity comes at the cost of essential context, so it is not perfectly structured for agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description remains incomplete given the 0% parameter coverage and missing annotations. It fails to clarify parameter semantics, pagination, or filtering behavior, leaving significant gaps for an agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 explain any of the three parameters (repository_id, limit, include) beyond their names and defaults. The phrase 'branches/tags' hints at repository content but does not clarify parameter meanings or behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'Git references (branches/tags)' scoped to 'a repository', making the tool's purpose unambiguous. This clearly distinguishes it from sibling tools like repositories_list or pull_requests_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys usage by stating the resource and action, but offers no explicit context on when to use this tool versus alternatives, no exclusions, and no prerequisites. The use case is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action 'list' and gives no information about pagination, the meaning of the 'include' parameter, rate limits, or response format. This is a significant transparency gap for a tool with optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, earning its place by stating the core functionality. It is appropriately concise, though it lacks detail, which is a completeness matter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no schema descriptions, the description is incomplete. It does not explain the optional parameters (limit, include) or any behavioral aspects like ordering or filtering. The presence of an output schema is not enough to compensate for the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage with no parameter descriptions, and the description adds no value for 'limit' or 'include'. It only implies 'repository_id' via 'for a repository'. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'pull requests' with a repository scope, which distinguishes it from sibling tools like repositories_list or reviews_list. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing pull requests for a given repository but provides no explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Remove a user account' and 'Confirmation of deletion' but fails to disclose whether the deletion is permanent, whether it cascades to related data, or if special permissions are required. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Args/Returns formatting is slightly verbose but acceptable for API documentation. Every sentence serves a purpose, though the Returns line could be more explicit. It is appropriately sized and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive tool with no annotations, yet the description only states what it does and gives a generic confirmation. It lacks details about side effects, reversibility, permissions, or error cases. Although an output schema exists, the description's return value is vague ('Confirmation of deletion') and doesn't cover operational nuances. Given the tool's severity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the only parameter, user_id, as 'The ID of the user to delete'. Schema coverage is 0%, so the description fully compensates by adding meaning beyond the schema's bare type/title. It would earn a 5 if it also described any validation or formatting rules, but as it stands it's clear and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove a user account' which is a specific verb and resource, clearly distinguishing it from tools like users_get and users_modify. It doesn't explicitly mention alternatives but the domain prefix [Users/Management] adds context. A 4 is appropriate because it's clear but lacks direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives or when not to use it. The description only explains the action itself. It does not mention any exclusions, preconditions, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the default limit (50) and max (200) to prevent response size issues, but does not clarify the optional app_id behavior, the meaning of include/access_type, or any pagination or filtering behavior. The phrase 'for an app' is ambiguous given app_id defaults to null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded. The first sentence states the purpose, and the second gives a useful limit guideline. There is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a tool with 4 optional parameters. It lacks parameter semantics, usage examples, and clarity on scope. The limit information is helpful but not sufficient for an agent to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the limit parameter (default 50, max 200). The other three parameters (app_id, include, access_type) are left entirely undefined, making it hard to know what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (analytics report requests) with a specific scope ('for an app'). This distinguishes it from sibling tools like report_requests_list_reports and report_instances_list_segments. The category prefix '[Analytics/Requests]' adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only mentions the default limit and maximum limit, which is parameter behavior not selection criteria. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the action and does not mention pagination, auth requirements, sorting, or any side effects. The optional 'limit' parameter is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, elegantly concise sentence with no redundant information. The bracket prefix adds relevant context without bloat, and it is front-loaded at the start.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks critical contextual details such as authentication prerequisites, pagination behavior, and differentiation from sibling list tools. For a tool with no annotations, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 add any meaning to the 'limit' parameter. The agent receives no semantic guidance beyond the parameter name, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('SCM providers configured for Xcode Cloud'), making it distinct from sibling tools like repositories_list and products_list. The Xcode Cloud/SCM tag adds helpful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the description (use when needing to list SCM providers), but there is no explicit guidance on when not to use it or mention of alternative tools. The tag provides some context but no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'Get detailed information' without addressing permissions, read-only guarantees, error behavior, or what 'detailed' includes. Beyond the inherent implication of 'get' as a read operation, it adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. The '[Users/Invitations]' prefix provides helpful categorization, and the structure is appropriately front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description is very sparse: no annotations, no usage context, and no parameter semantics are provided. For a tool with 3 parameters and a specific invitation-scoped operation, the description leaves significant gaps in what an agent needs to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not compensate by explaining any parameters. The phrase 'specific user invitation' hints at the required invitation_id, but parameters like include and visible_apps_limit are completely unexplained, leaving the agent without meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource ('detailed information about a specific user invitation'), making the operation unambiguous. The phrase 'specific user invitation' effectively distinguishes it from sibling tools like user_invitations_list (listing) and user_invitations_create/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer that it should be used when an invitation_id is available and detailed data is needed. It does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only mentions the parameter requirement, but does not disclose whether the operation is read-only, how pagination/sorting works, or any potential side effects or error conditions. This is a significant gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. The bracketed prefix and the key requirement are front-loaded, making it easy to parse. It is concise, though perhaps too sparse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no parameter descriptions, the description is too brief. It does not explain the output (though an output schema exists), the meaning of filters/include, or when to use this tool relative to the sibling tools. This leaves important context missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that either product_id or workflow_id is required, but it does not explain the meaning or interplay of sort, limit, filters, or include. These parameters remain largely undefined, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('builds'), and scopes the action with 'for a product or workflow'. This clearly distinguishes it from siblings like builds_get (single build) and builds_start (create build).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a necessary condition: 'Requires either product_id or workflow_id.' This gives clear invocation context but does not compare with alternatives such as builds_get or artifacts_list. It does not explicitly say when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral context. It implies a read-only operation via 'Get,' but does not disclose any additional traits such as permissions, side effects, or scope limitations. However, the output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with a category prefix, and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-ID with an output schema, so the description adequately conveys the primary purpose. However, it omits parameter semantics and usage guidance, making it incomplete for a tool with an undocumented 'include' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not mention either parameter. 'request_id' is not explained, and 'include' is completely opaque. This leaves the agent without guidance on how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get detailed information about a specific analytics report request,' which clearly identifies the verb (get), resource (analytics report request), and scope (specific). It distinguishes from sibling list/create tools by emphasizing 'specific request.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is given about when to use this tool versus alternatives such as report_requests_list_reports or report_instances_get. It merely defines the action without usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' clearly indicates a read operation, but it does not disclose any additional behavioral traits such as expected response shape, pagination, or authorization requirements. For a simple getter, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the tool's purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema present), the description is minimally viable. However, it lacks explanation of the optional 'include' parameter and provides no usage guidance relative to siblings. These gaps make it incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the 'include' parameter at all, and only vaguely references 'product' which implies product_id but without explicit mapping. The description adds little semantic value beyond the schema's bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a specific Xcode Cloud product, using a specific verb+resource. However, it does not explicitly distinguish from sibling tools like products_list, though 'specific' implies a single resource by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need details on one product. But there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites beyond what the schema shows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 usefully mentions default limit (100), maximum (200), and pagination metadata, which gives some operational transparency. However, it omits other behavioral details such as authentication, error handling, or the meaning of the 'include' parameter, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, with purpose front-loaded and operational limits in the second sentence. Every sentence earns its place, and it is free of fluff or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for an AI agent. The 'include' parameter is undocumented and ambiguous, and no guidance is given on when this tool is appropriate compared to closely related siblings. The pagination and limit details are helpful, but the missing parameter semantics and usage exclusions leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 explain any parameters beyond echoing the default limit already in the schema. The 'include' parameter is entirely ambiguous—no meaning, allowed values, or effect is described. instance_id is obvious from name, but the optional parameters lack semantic clarification, so the description fails to add value beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List segments for a specific analytics report instance.' This is a specific verb+resource combination that distinguishes it from siblings like report_instances_get (gets an instance) and report_segments_get (gets a single segment). The '[Analytics/Segments]' prefix adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific instance ('for a specific analytics report instance') but provides no explicit guidance on when to prefer this over alternatives like report_segments_get or reports_list_instances. It lacks any 'when not to use' or alternative naming, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about pagination (despite a `limit` parameter), authentication requirements, read-only nature, or what subset of repositories is returned. The verb 'List' suggests read-only but does not cover other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. It contains no filler or redundancy, making it highly concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal for a tool with three parameters, no annotations, and zero schema coverage. It lacks guidance on when to use it, what `limit` and `include` control, and any behavioral caveats. This is insufficient for an agent to use the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies the role of `scm_provider_id` ('for an SCM provider'), but leaves `limit` and `include` unexplained. The parameter names are partially self-explanatory, but `include` remains ambiguous without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('Git repositories'), and the scope ('for an SCM provider'). This clearly distinguishes it from sibling tools like pull_requests_list and git_references_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to list repositories for a given SCM provider, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or mention prerequisites like obtaining an SCM provider ID first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It merely restates the 'Get' verb with no added behavioral context: no mention of error handling (e.g., 404 if user not found), permissions, or side effects. The include parameter's effect on response is also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a category prefix, front-loaded and zero wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description lacks parameter semantics and usage guidance. The unexplained include parameter is a notable gap; the tool is simple but still under-specified for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. 'Specific user' hints at user_id, but the include parameter (likely controlling extra data) remains completely undocumented. The agent cannot infer its semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'specific user', clearly distinguishing from siblings like users_list (which lists all users) and users_modify/users_delete. The added category prefix [Users/Management] also aids context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need details of one specific user. No explicit guidance on when not to use (e.g., for bulk retrieval use users_list) or mention of alternatives. Provides a clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that the tool lists artifacts and does not mention pagination, ordering, error behavior, or read-only nature, which are important traits for an API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, comprising a single sentence with a clear verb and object. The prefix '[XcodeCloud/BuildArtifacts]' is slightly redundant but does not detract significantly from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks essential context such as param behavior, defaults, or what artifacts are included. With no annotations and a brief description, the tool is not fully self-contained for correct invocation, especially regarding the 'limit' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only implicitly suggests a build ID via 'for a build' but does not address the 'limit' parameter or provide any default/type details, offering minimal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List artifacts for a build" clearly identifies the tool's function with a specific verb and resource scope. It distinguishes itself from sibling tools by explicitly scoping to artifacts within a build, while the naming and context make it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "for a build" provides clear context that this tool is used when you need artifacts tied to a specific build. However, it does not explicitly mention when not to use it or name alternative tools, though no direct artifact sibling exists, so the guidance is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states only the action 'Get' and doesn't disclose any limitations, prerequisites, or side effects. It adds no context beyond the literal operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the tool's purpose, and contains no filler. It efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature and an output schema, but the description lacks prerequisites, usage context, and parameter semantics. It's minimally complete but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely ties the parameter via 'for a specific crash submission'. It does not explain what a submission_id is, its format, or how to find it, leaving the parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and names the resource 'raw crash log text', scoped to 'a specific crash submission'. This clearly distinguishes it from sibling tools like crashes_list or crashes_get_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user needs the raw crash log text for a known submission, but it doesn't explicitly mention alternatives or when not to use it. There's no guidance on how to obtain submission_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It implies a read-only list operation but does not mention pagination, authentication, rate limits, or any dependencies (e.g., build must have test results). This is a significant gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It front-loads the purpose and is appropriately sized for a simple list operation, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, reducing the need to explain return values. However, the description lacks contextual details such as whether the build must have run tests, result ordering, or the relationship to artifacts_list. It is minimally adequate but leaves room for misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to explain the parameters. It only mentions the scope 'for a build' (which maps to build_id) but does not describe the 'limit' parameter, its default, or how it affects results. The schema only provides titles, so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List test results') and the resource ('test results for a build'), making it specific and unambiguous. The [XcodeCloud/BuildArtifacts] prefix adds useful domain context, and it distinguishes itself from sibling tools like artifacts_list by focusing on test results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing test results of a build but offers no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or prerequisites. It relies on the tool's name and the sibling list to infer its place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions modifying a user and returning updated info, but does not disclose whether updates are partial/full, permission requirements, or side effects. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with Args and Returns, front-loaded with purpose, and contains no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the tool is a mutation with no annotations. The description lacks details on permitted user_data fields, required permissions, partial vs. full update semantics, and error behavior, making it inadequate for a modification tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists and explains all three parameters (user_id, user_data, include), which adds meaning beyond the bare schema. However, user_data's explanation ('Dictionary containing the fields to update') is vague and does not enumerate allowed fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Modify a user account' with a clear [Users/Management] scope. This is a specific verb+resource and distinguishes from sibling tools like users_delete, users_get, and users_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Modify' implies updating an existing user, providing clear context, but no explicit when-not-to-use or alternatives are mentioned. Usage is inferred rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavioral traits: a default limit of 25, maximum 200, and pagination metadata. However, it omits details like filtering behavior, sorting semantics, and authentication requirements. The description contradicts the schema's limit default of 50, undermining trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences provide purpose and limit/pagination information without fluff, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered, but the description does not guide users on the five optional parameters. The limit default discrepancy and lack of parameter explanations leave the tool incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions limit but incorrectly states a default of 25 while the schema declares 50. It offers no explanation for sort, app_id, filters, or include parameters, and schema coverage is 0%, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('crash submissions from beta testers'), and the [TestFlight] prefix distinguishes it from other crash tools like crashes_search and crashes_get_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies listing all crashes but does not explicitly contrast with crashes_search or specify when to use this instead. It provides pagination context but no alternative or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does imply a read-only GET operation via the verb 'Get,' but it does not disclose permissions, error behavior, or any side effects. The behavioral insight is minimal beyond the operation's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with a helpful domain prefix '[Analytics/Segments].' It is concise, front-loaded, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered, but the description lacks parameter semantics and usage guidance relative to numerous sibling tools. The minimal description is insufficient to fully contextualize invocation in a complex analytics domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does not. It mentions 'a specific analytics report segment' but does not explain the required segment_id or the optional 'include' parameter, leaving the agent to guess at their meaning and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information for a specific analytics report segment. The verb 'Get' plus the resource 'detailed information about a specific analytics report segment' is specific and distinguishes it from sibling tools like report_instances_list_segments (which lists segments) and reports_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing details of one specific segment, but it does not explicitly contrast with alternatives such as report_instances_list_segments for listing all segments or report_instances_get for getting instance-level info. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of indicating the operation is a safe read ('Get'). It does not disclose any additional behavioral traits such as error handling, prerequisites, or rate limits. The read-only nature is clear from the verb, but no further context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the category label '[XcodeCloud/Builds]' and immediately states the action. It contains no filler and is highly efficient for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is adequate but leaves gaps. The 'include' parameter is unexplained, and there is no mention of how to obtain a valid build_id (e.g., via builds_list). While an output schema exists to detail return values, the missing parameter semantics and usage context keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter explanations. It indirectly references build_id via 'specific build' but says nothing about the 'include' parameter or the format of build_id. The schema only provides titles, leaving the agent without semantic guidance beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get detailed information about a specific build.' It clearly distinguishes from sibling tools like builds_list (listing builds) and builds_start (starting builds). The scope ('specific build') is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a build_id and need details for that single build. However, it does not explicitly mention when not to use it or point to alternatives like builds_list for discovering build IDs. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of transparency. It discloses that the created invitation 'expires in ~3 days' and that it returns 'Created user invitation information'. However, it does not mention permissions, prerequisites, or side effects like email delivery, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections. It is concise overall, though the '[Users/Invitations]' prefix is redundant and adds minor clutter. Each line in the Args section provides useful information, so it earns a slightly above-average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, one of which is a nested object, and an output schema exists. The description provides some return context ('expires in ~3 days') but does not explain the structure of invitation_data, which is critical for correct invocation. Given the lack of annotations and schema descriptions, the description is incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must compensate. It adds meaning by identifying invitation_data as a dictionary, include as an optional list of related resources, and visible_apps_limit with a 1-50 range. However, 'Dictionary containing the invitation details' is vague and does not specify required keys, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new user invitation' with a specific verb and resource. This distinguishes it from sibling tools like user_invitations_list, user_invitations_get, and user_invitations_delete, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement about when to use this tool versus alternatives, but the purpose implies its use for creating invitations. No exclusions or alternative references are provided, so guidance is limited to what is inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does reveal a key behavior: 'The branch/tag name is resolved to a Git reference ID via the API.' This adds useful context. However, it omits other behavioral aspects such as side effects, error conditions, or permission requirements, which are important for a build-triggering mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise at two sentences. The first sentence states the core purpose, and the second provides a crucial alternative. There is minimal waste, though the leading '[XcodeCloud/Builds]' prefix and extra whitespace add minor noise. Overall, it is efficient and front-loaded enough for a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need no explanation. However, with no annotations and 0% schema coverage, the description needs to provide more context for a mutation tool. It gives the main flow (branch/tag resolution) and a sibling alternative, but leaves parameters like pull_request_number and workflow_id unclear, and lacks details on failure handling or prerequisites. It is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, leaving the description to compensate. It explains the role of source_branch_or_tag ('branch or tag name') and contrasts it with direct ID usage, but it does not clarify workflow_id (required) or pull_request_number at all. This is insufficient given the complete lack of schema descriptions, so the tool fails to help the agent understand all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start a new build using a branch or tag name.' It uses a specific verb ('Start') and resource ('new build'), and explicitly distinguishes it from the sibling tool builds_start_by_ref_id by noting the alternative for direct ID usage. This makes the purpose unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'For direct ID usage without resolution, use builds_start_by_ref_id.' This clearly indicates when to use this tool (when you have a branch/tag name) versus the alternative. However, it does not mention other potential alternatives or broader context (e.g., when to use pull_request_number), so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 usefully explains the default limit and the rationale (preventing response-size issues), and notes the upper bound of 200. However, it does not explicitly confirm a read-only nature, describe pagination behavior (e.g., no offset), or mention error conditions. It adds some context but not a rich behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: it has one clear purpose sentence and one sentence about the limit behavior. No filler or redundant material. It is appropriately sized for a list tool and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and the tool is a simple list operation, the description leaves the semantics of three of five parameters unexplained. The agent can infer request_id and limit, but 'name', 'include', and 'category' are ambiguous. Given zero schema descriptions and no annotations, this is a notable gap that could lead to incorrect invocation. The tool's overall complexity is low, so a complete description would be easy to provide; this one is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 5 parameters with zero description coverage, so the description must compensate. It only explains the 'limit' parameter (default and maximum). The required 'request_id' is inferable from the tool name but not explicitly described, and the optional 'name', 'include', and 'category' parameters are entirely unexplained. This leaves significant ambiguity for an agent invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List reports') on a clearly scoped resource ('for a specific analytics report request'), using a strong verb-object construction. It distinguishes this tool from siblings like 'analytics_report_requests_list' (lists requests) and 'reports_get' (gets a single report) by clarifying the request-scoped listing behavior. Though the category prefix is generic, the core sentence is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you have a specific analytics report request and need its reports. It also gives concrete usage guidance about the limit parameter (default 50, max 200) to avoid response-size issues. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 behavior: default limit 100, max 200, and instructs to use pagination metadata for additional pages. This adds meaningful behavioral context beyond what a simple 'list' implies, though it does not cover auth, ordering, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the category and clear action. Every sentence earns its place: one defines the tool's purpose and one gives necessary pagination details. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable given the moderate complexity and existing output schema. It covers the required report_id context and limit behavior, but omits semantics for include, granularity, and processing_date, and lacks guidance on when to choose this tool over report-instance siblings. An agent could invoke it with defaults but would be guessing on the optional filtering parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It only explains limit (default 100, max 200) and implicitly report_id, while include, granularity, and processing_date are left entirely to their parameter names with no explanation of format, allowed values, or effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[Analytics/Reports] List instances for a specific analytics report.' This clearly states the action (list), the resource (instances), and the scope (specific report), which distinguishes it from sibling tools like report_instances_get or report_instances_list_segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational context by mentioning the default limit, max limit, and pagination metadata, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling tool comparisons or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses pagination behavior and limits, which is useful, but does not explain how filters or the include parameter behave, what authentication is required, or the exact response structure beyond mentioning pagination metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—with the most important information (purpose, limit, pagination) front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered. However, with four parameters and zero schema descriptions, the description only addresses limit and pagination, leaving sort, filters, and include semantically vague. This is a minimum-viable description for a list tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only elaborates on the limit parameter (default 50, max 200). The sort, filters, and include parameters are left entirely unexplained, so the description does not compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all users in the organization', specifying both the action and the resource. It distinguishes itself from sibling tools like users_get (single user), users_modify, and users_delete by focusing on the list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: the tool lists all users in the organization, with pagination details (default 50, max 200). While it doesn't explicitly say 'use this instead of users_get for multiple users', the scope is clear enough to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds a safety note explaining that mutating operations are unsupported, implying a read-only nature. But it does not disclose other behavioral traits like pagination, rate limits, or the exact scope of 'workflows' (e.g., all workflows for a product vs. filtered subsets).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose stated in the first sentence and a relevant safety note in the second. Every word contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with an output schema, the description adequately states the core purpose and the safety limitation. However, given four parameters and no annotations, it lacks important context about filter/limit semantics and when to use this tool versus the closely related workflows_get tool. This leaves some gaps for an agent evaluating the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the parameters (limit, filters, include, product_id). Product_id is implied by the mention of 'product,' but the optional parameters remain semantically unclear. The description fails 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List workflows for an Xcode Cloud product.' It uses a specific verb ('List') and resource ('workflows'), and the product scoping is explicit. It also distinguishes itself from mutation operations, which helps separate it from potential sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for listing only and notes that 'Create/update/delete operations are not supported for safety,' providing an exclusion that guides appropriate use. However, it does not explicitly name alternatives (e.g., workflows_get for retrieving a single workflow) or mention when to prefer this over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It goes beyond the verb by specifying default limit, max limit, pagination metadata, and supported sort fields. It does not mention auth or rate limits, but these are not critical for a read-only list endpoint and the 'list' verb implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The purpose is front-loaded, followed by two clear operational bullets. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no annotations, and the output schema exists but does not explain parameter usage. The description covers core list behavior, pagination, and sort, but lacks explicit guidance on filters and include semantics. Given the complexity, the description is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully documents valid sort values and the default/max limit. However, it leaves filters, include, and visible_apps_limit completely unexplained, so parameter semantics are only partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource combination: 'List all user invitations.' It distinguishes itself from sibling tools like user_invitations_get (single invitation) and users_list (different resource) by explicitly stating it lists invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational context (default limit, max, pagination, sort options) but does not explicitly state when to use this tool versus alternatives such as user_invitations_get or users_list. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for safety disclosure. It explicitly states that create/update/delete are not supported for safety, which transparently communicates the read-only nature. It lacks details on response behavior or edge cases, but the core behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and the safety note adds essential context without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 an output schema present, the description covers the core purpose and safety scope adequately. However, it omits any guidance on the optional 'include' parameter or how this tool relates to workflows_list, leaving a slight gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. While workflow_id is self-explanatory, the 'include' parameter's purpose is entirely unclear and not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('detailed information about a specific workflow'), which distinguishes it from sibling workflows_list. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for a specific workflow) and explicitly states that create/update/delete are not supported, providing a clear exclusion. However, it does not reference alternative tools like workflows_list, so it stops short of giving explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses a key behavioral trait: it uses a Git reference ID directly and skips resolution, implying it cannot handle branch/tag names. However, it does not elaborate on potential errors or asynchronous behavior, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the action, and includes only two meaningful sentences. No redundant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 complete absence of parameter descriptions in both schema and text makes the description incomplete for an agent to invoke it correctly. The output schema helps with returns, but input semantics are not adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at source_ref_id via 'Git reference ID' but does not explain the required workflow_id or pull_request_number. This is insufficient for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool starts a new build using a Git reference ID, which is a specific verb+resource. It also distinguishes itself from builds_start by noting that branch/tag names are handled there, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool ('when you already have the Git reference UUID') and explicitly specifies the alternative ('For branch/tag names, use builds_start instead'). This provides excellent guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates the action is destructive ('delete/cancel') and describes the return value. However, it does not mention prerequisites (e.g., invitation must be pending), side effects, or permission requirements, which would provide fuller transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a short verb phrase, an Args section, and a Returns section. No wasted words, and the format is easily scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema, the description covers the essential aspects: what it does, the parameter meaning, and the resulting confirmation. It is sufficiently complete, though a note about which invitations can be cancelled would have made it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies the parameter name and type with 0% description coverage. The description compensates fully by explaining that 'invitation_id' is 'The ID of the invitation to cancel', giving the parameter clear semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Cancel/delete a user invitation') with a specific resource ('a user invitation'). It distinguishes itself from sibling user_invitation tools by indicating this operation removes an invitation, as opposed to listing, getting, or creating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear enough that an agent would know to use this tool when cancelling/removing a user invitation. It does not explicitly list alternative tools or exclusions, but the context and explicit verb provide clear situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses side effects (saves to a TSV file, temp directory if no output_path), return statuses (success, no_data, error), and output details (file_size_mb, segment_count, row_count). It doesn't mention permissions, file overwrite behavior, or rate limits, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, explanation, Args, and Returns sections. It's front-loaded with the core purpose, but the Returns section is somewhat verbose with inline descriptions. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is embedded in the Returns section, covering status, file_path, file_size_mb, segment_count, row_count, and message. The description is self-sufficient for a 2-parameter tool, with no annotations needed. It lacks only background on access requirements and potential large-file handling, but overall it's quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description does the heavy lifting. It provides meaningful explanations for both instance_id (analytics report instance ID) and output_path (optional, defaults to temp directory), adding clarity beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads analytics report data to a TSV file, with the specific verb 'download' and resource 'analytics report data'. It distinguishes itself from siblings by emphasizing it fetches all segments and saves to a file, unlike report_instances_get (metadata) or report_segments_get (individual segment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies usage for downloading all report data for later analysis, and mentions the file can be analyzed using other tools. However, it doesn't explicitly contrast with alternatives like list_segments or get, nor state when not to use it, making it clear but without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![app-store-connect-mcp MCP server](https://glama.ai/mcp/servers/gjeltep/app-store-connect-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gjeltep/app-store-connect-mcp)

Score Badge

Copy to your README.md:

[![app-store-connect-mcp MCP server](https://glama.ai/mcp/servers/gjeltep/app-store-connect-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gjeltep/app-store-connect-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gjeltep/app-store-connect-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server