App Store Connect MCP Server

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct resource and action: apps, builds, versions, beta groups/testers, reviews, users, devices, bundle IDs, certificates, profiles, IAP, subscriptions, and sales. The few related tools (list vs get, list_customer_reviews vs respond_to_review) are clearly differentiated by their verbs and object nouns.
Naming Consistency5/5
All tool names follow a consistent verb_noun or verb_preposition_noun pattern (e.g., list_apps, get_build, submit_for_review, respond_to_review). Naming is uniformly lowercase with underscores, making the pattern predictable across all 20 tools.
Tool Count4/5
With 20 tools, the set is on the heavier side but still coherent for the broad App Store Connect domain. The count is justified by the many distinct resource types covered, though it approaches the upper limit of what feels manageable.
Completeness3/5
The tool set is read-heavy, covering listing and getting for most resources, plus a few actions like responding to reviews, submitting for review, and adding beta testers. However, it lacks update/delete operations for apps, builds, versions, users, and other entities, leaving notable gaps in lifecycle management.
Average 3.4/5 across 20 of 20 tools scored. Lowest: 2.8/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 March 3, 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?
No annotations are provided, so the description must disclose behavioral traits. It only repeats the tool's name and gives no insight into pagination, return format, default behavior, or any side effects. The schema mentions the limit default, but the description itself adds no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, which is appropriate for a simple tool, but it is under-specified. It essentially restates the tool name and doesn't front-load any additional useful details, so it feels like a placeholder rather than a well-crafted description.
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?
With no output schema and no annotations, the description is the only source for understanding the response. It doesn't mention what fields are returned, how pagination works, or any caveats, so the agent is left without necessary context for a complete tool invocation.
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 input schema provides 100% coverage for both parameters (appId and limit) with clear descriptions, so the baseline is 3. The tool description does not add meaning beyond what the schema already states, but it doesn't need to given the schema's completeness.
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 action (list) and the resource (in-app purchases) with the scope ('for an app'). It is distinct from sibling tools like list_subscriptions or list_builds because the resource is explicitly named. However, it doesn't explicitly differentiate from other list tools, so it misses the top score.
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 or any prerequisites beyond the implicit appId. There is no mention of context, exclusions, or related tools, so the agent receives no usage direction beyond the obvious.
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, but it only reveals that the report is returned as text. It does not mention authentication requirements, rate limits, how to interpret the text, or any side effects. This is minimal and insufficient for a report-fetching 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 extremely concise, just two sentences with no fluff. It front-loads the purpose and includes a useful detail about return format. The brevity is appropriate for a straightforward retrieval tool, though it could be slightly more informative without becoming verbose.
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 five parameters with varied enums and no output schema, the description is too sparse to be fully self-sufficient. It lacks context about report types, frequency choices, vendor number significance, and what the returned text looks like. The schema covers parameter syntax but not usage scenarios or return structure.
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 100%, with all five parameters documented including enums. The description adds no parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 the tool requests a sales or financial report and returns data as text, making the primary purpose clear. It is distinguishable from sibling tools (none of which are report-related), though the verb 'Request' is slightly less direct than 'Get' or 'Retrieve'.
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 App Store Connect, typical use cases, or prerequisites beyond the schema's required parameters. As the only report tool, the context is weakly implied but not explicit.
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 for behavioral disclosure, but it only says 'List registered bundle identifiers,' which is essentially the tool name. It does not mention pagination, default limits, return format, or any side effects, though the list verb implies a read-only 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 a single, front-loaded sentence with no filler or redundancy. It is appropriately concise for a simple list tool, though it could have added value by noting filters or alternatives.
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 straightforward list tool with schema-covered filters, the description is minimally sufficient. However, without an output schema or any behavioral notes, the agent may not know the exact return structure or how pagination works, leaving some 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?
The input schema fully documents all three parameters, so the baseline is 3. The description adds no additional parameter semantics, but this is acceptable because the schema already provides clear descriptions for limit, filterPlatform, and filterIdentifier.
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's action ('List') and resource ('registered bundle identifiers'), making the core purpose evident. However, it does not distinguish this from sibling tools like list_apps or list_builds, so it misses some 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?
No guidance is given on when to use this tool versus alternatives such as list_apps or get_app. The description does not mention context, prerequisites, or exclusion criteria, leaving the agent to infer usage.
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 for behavioral disclosure. It only states that information is retrieved, but gives no details about permissions, return format, or any side effects. For a read operation this is minimal and not fully transparent.
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, clear sentence with no redundant words. It is appropriately sized for the tool's simplicity.
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 one-parameter get tool with no output schema, the description is adequate but minimal. It does not specify what 'detailed information' includes, and it lacks any context about expected use cases or limitations, leaving some ambiguity.
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 already documents versionId with a description and 100% coverage. The tool description adds no extra semantic meaning beyond the schema, so it meets the baseline but does not compensate or enhance understanding.
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 app version, using a specific verb ('get') and resource ('app version'). It distinguishes from the sibling tool list_app_versions by emphasizing 'specific' rather than listing, though it doesn't explicitly contrast with get_app.
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 list_app_versions or get_app. The description implies it is for retrieving a single version's details, but it does not state exclusions or context.
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 disclosing behavior. It only states that it lists subscription groups, which implies a read-only operation, but fails to disclose pagination, default limit, response format, permissions, or any side effects. This is minimal disclosure for a tool that could have varying 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 states the purpose without filler or redundancy. It is front-loaded and easy to parse, though it sacrifices additional helpful guidance. This is concise but slightly under-specified, so it earns a 4 rather than a 5.
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 simple two-parameter schema and lack of output schema or annotations, the description is incomplete. It does not explain what a subscription group is, how results are ordered, what fields are returned, or how errors/manage edge cases (e.g., no groups). An agent would need more context to reliably interpret the tool's output.
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 input schema already fully describes both parameters (appId with a clear description, and limit with numeric constraints and default). The description adds no additional semantic meaning beyond what the schema provides; the phrase 'for an app' simply restates the appId purpose. Schema coverage is 100%, so a baseline of 3 is appropriate.
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 the specific verb 'List' with the resource 'subscription groups' and scope 'for an app', making it clear what the tool does. It distinguishes itself from sibling list tools (e.g., list_apps, list_beta_groups) by naming a distinct resource type, even though it doesn't explicitly mention 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?
No guidance is provided on when to use this tool versus other list tools like list_in_app_purchases or list_beta_groups. There is no mention of prerequisites (e.g., obtaining an appId) or any exclusion scenarios. The only contextual hint is 'for an app', which is already implied by the required appId parameter.
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?
The description claims to list 'all' apps but the input schema includes an optional limit parameter (default 50, max 200), meaning the tool actually returns a limited page. This omission of pagination/limit behavior is misleading. Since no annotations are provided, the description carries the full burden and fails to disclose an important behavioral trait.
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 one short sentence, front-loaded with the verb, and contains no unnecessary words. It is appropriately concise and structurally clear.
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?
For a simple list tool with no output schema, the description adequately states the resource, but it fails to mention the limit parameter's impact on pagination or that results are capped. This is a meaningful gap that could cause an agent to believe all apps are always returned. No mention of return format or authentication, but the primary omission is the pagination behavior.
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 input schema fully documents the single 'limit' parameter with min, max, and default, so schema coverage is 100%. The description adds no additional parameter context, and its 'all' language conflicts with the limit's purpose. Baseline 3 is appropriate because the schema already handles 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 clearly states the tool lists apps in the user's App Store Connect account, using the specific verb 'list' and resource 'apps', which distinguishes it from sibling tools like get_app or list_builds. The word 'all' slightly overpromises given the limit parameter, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_app for a single app or other list tools. There is no mention of use cases, prerequisite conditions, or exclusions, so an agent receives no decision support.
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 states 'List all' but does not disclose that the 'limit' parameter (default 10) actually restricts the result set, nor does it mention pagination, rate limits, or required permissions. The description is misleading regarding the 'all' claim.
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, concise sentence that gets straight to the point. It is front-loaded with the key verb and resource, and contains no filler or redundant information.
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 four parameters, no output schema, and no annotations, the description is too sparse to fully contextualize behavior. It fails to explain the 'limit' default, the meaning of 'all' in contrast to pagination, or how this tool relates to the broader family of list and get operations.
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 100%, so all four parameters are documented in the input schema. The description itself does not add any parameter-level meaning beyond what the schema already provides, meeting the baseline for schema-heavy definitions.
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 ('App Store versions') with an implicit scope ('for an app'), making its primary function immediately clear. It also distinguishes itself from sibling tools like 'get_app_version' (singular) and 'list_builds' (different resource).
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 over siblings such as 'get_app_version' or 'list_builds'. It does not mention any exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'List customer reviews for an app'. It does not mention default ordering, pagination, filtering options, response structure, or any side effects, leaving important behavior 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?
The description is a single, clear sentence with no filler. Every word contributes to identifying the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, and the description is only one line. It leaves the agent without information about return format, pagination, default sort order, or typical usage. Given the tool has 5 parameters and many siblings, this is insufficient for reliable invocation.
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 covers all 5 parameters with descriptions (100% coverage), including enums and ranges, so the description adds little parameter meaning. The baseline of 3 applies because the structured schema does the heavy lifting.
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 specific resource ('customer reviews') and scope ('for an app'), making it easy to distinguish from sibling tools like respond_to_review or list_apps.
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 about when to use this tool versus alternatives, or when it should not be used. The description only states the action without 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 provided, the description must fully disclose behavioral traits. It only states the action without mentioning that this is a write/mutation operation, whether responses are public, any rate limits or permission requirements, or whether responses can be edited/deleted. The verb 'Respond' implicitly suggests a write, but no explicit context is given.
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, concise sentence with no filler or redundancy. It communicates the essential purpose immediately, making it well-suited for quick agent parsing.
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 simple 2-parameter tool with no output schema, but the description lacks critical context such as when to use it, potential side effects of responding, or any restrictions. Given no annotations, the agent would have to infer the tool's mutating nature and any prerequisites solely from the action verb, which is insufficient for reliable invocation.
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 input schema has 100% description coverage, with both parameters (reviewId, responseBody) clearly explained. The description itself adds no additional parameter semantics, but since the schema already covers the meaning, a baseline score of 3 is appropriate.
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 ('Respond') and the resource ('a customer review'), with a specific verb and target. It distinguishes itself from sibling tools like list_customer_reviews (listing) and submit_for_review (submitting an app), 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 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, nor does it mention any prerequisites or exclusions. It does not indicate that this is the appropriate tool for posting a reply as opposed to listing reviews or submitting an app for review.
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?
Without annotations, the description must expose behavior; it only says 'add' which implies mutation but does not disclose side effects, idempotency, permission requirements, or what happens if the tester already exists. This is a significant gap for a write 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, front-loaded sentence with no filler. Every word contributes to understanding the tool's 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?
For a simple add operation, the description is basic but misses important context such as whether optional names are needed for new testers and what the response/result is. The absence of annotations and output schema leaves gaps, but the core action is clear enough for a minimum viable description.
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 input schema fully describes all four parameters with descriptions (100% coverage), so the description adds little beyond schema. 'by email' hints at the key identifier, but does not clarify the optional first/last name usage, so a baseline of 3 is appropriate.
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 the specific verb 'Add' and identifies the resource 'beta tester' and destination 'beta group', with 'by email' indicating the identifier. This clearly distinguishes it from sibling list tools like list_beta_testers and list_beta_groups.
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, nor any prerequisites such as requiring an existing beta group or tester. The description simply states the action without contextual cues.
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 full responsibility for behavioral disclosure. It only states the listing action and scope, but does not mention pagination, ordering, response format, or any other behavioral traits. The description is too sparse to provide meaningful 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 a single concise sentence that is front-loaded with the key verb and resource. Every word contributes to the meaning, with no unnecessary filler or repetition.
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 list tool with fully documented optional parameters, the description is minimally adequate but lacks context about response behavior, potential use cases, or relationship to sibling tools. Given no output schema and no annotations, a bit more detail would be helpful, but the core function is clear.
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 input schema has 100% description coverage for both parameters, so the schema already documents limit and filterCertificateType. The description adds no additional parameter information, warranting the baseline score of 3.
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 a clearly defined resource ('signing certificates in your developer account'), which distinguishes it from sibling list tools like list_profiles or list_devices. The resource is 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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply states what it does without contextual usage direction.
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 burden of behavioral disclosure. It only says 'List', which implies a read-only action, but provides no additional details such as default limit, pagination behavior, or what response to expect. The verb is already implied by the tool name, so the description adds minimal transparency beyond the structured data.
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, concise sentence that immediately conveys the tool's purpose with no wasted words. It is appropriately front-loaded and 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?
Given the tool is a simple list operation with fully documented parameters, the description is minimally viable. However, the absence of an output schema and any behavioral annotations means the overall context is incomplete—an agent would not know the structure of the returned data or default behaviors such as sorting or default limit.
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 100%, so the schema already fully documents all three parameters (limit, filterProfileType, filterProfileState). The description adds no parameter-specific meaning beyond what the schema provides, so it meets the baseline for schema-heavy 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 'List provisioning profiles' uses a specific verb ('List') and a precise resource ('provisioning profiles'), immediately distinguishing it from sibling tools that list other entities (apps, builds, beta groups, etc.). It unambiguously states what the tool does.
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 gives no explicit guidance on when to use this tool vs. alternatives. It does not mention exclusions or related tools for different profile-related operations. While the resource name implies the intended context, it lacks explicit usage direction.
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. 'Get' clearly signals a read-only operation, and 'detailed information' implies a response payload. However, it does not disclose response format, error behavior, or any auth requirements. This is minimally transparent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and easy to scan. It could arguably be more informative, but it is not verbose or redundant.
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 minimally adequate: the schema fully covers the parameter, and the purpose is clear. However, there is no output schema and no annotations, so the description should have mentioned what 'detailed information' includes or how to obtain the build ID from sibling tools like list_builds.
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 already fully documents the only parameter buildId with a clear description. The tool description adds no additional semantic context, such as where to obtain the ID or expected format. With schema coverage at 100%, the baseline of 3 applies.
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?
Clearly identifies a read operation for a single build ('Get detailed information about a specific build'), which distinguishes it from list_builds (all builds) and other resource-specific getters. The verb 'Get' and resource 'build' are specific.
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 on when to use this tool versus alternatives. It does not mention that this should be used after obtaining a build ID from list_builds, nor does it exclude cases where list_builds is more appropriate. The description provides no decision-making context.
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 only states that it gets information, without detailing what data is returned, whether any permissions are needed, or any side effects. For a read operation, it could at least mention the kind of fields returned, but it does not.
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 of seven words, immediately front-loaded with the action and object. There is no fluff or repetition, and every word earns its place.
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 with one well-documented parameter, the description is minimally viable. However, since there is no output schema, the description should clarify what 'detailed information' means (e.g., app metadata, bundle ID, pricing). This gap leaves the return value ambiguous.
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 100% (appId is well described). The description adds minimal semantic value beyond the schema, merely indicating the app is 'specific,' which aligns with the appId parameter. Baseline of 3 is appropriate.
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 'Get detailed information about a specific app' clearly states a specific verb (Get), resource (detailed information about an app), and scoping (specific app). This distinguishes it from siblings like list_apps and get_build, which operate at different levels of granularity.
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 by the phrase 'specific app,' suggesting it is used when you need details for a particular app, as opposed to listing all apps. However, there is no explicit guidance on when to use this over get_app_version or get_build, nor any stated 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 burden. The verb 'List' implies a read-only operation, but the description does not disclose pagination behavior, default/max limits, or response structure. It is minimal but not misleading.
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?
One concise sentence that is front-loaded with the verb and resource, containing 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?
For a simple list tool, the description is adequate but lacks details about return values or any constraints beyond the app ID. Given the absence of an output schema, a bit more context would help, but the tool's simplicity limits the impact of the gap.
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 100% with both parameters documented. The description adds no additional meaning beyond reinforcing that the operation is scoped to an app via appId.
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 the resource 'TestFlight beta groups' and scope 'for an app', clearly distinguishing it from sibling tools like list_beta_testers.
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 to retrieve beta groups for a given app, but it does not explicitly mention alternatives or when not to use it. The clear purpose partially compensates for lack of explicit 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?
With no annotations, the description carries the burden of behavioral disclosure. It communicates that this is a read-only listing operation and that filtering by beta group is possible, but it does not mention default limits, pagination behavior, or whether all testers are returned when no filter is provided. It adds some context beyond the bare name but lacks depth.
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 states the action and the key optional filter. No unnecessary words or redundancy.
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, read-only list tool with zero required parameters and full schema coverage, the description is largely sufficient. It does not describe the return format, but no output schema exists; for a list operation the implication is clear. It is missing some usage nuance but is complete enough for its 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?
Schema description coverage is 100%, so the schema already documents all three parameters with meaningful descriptions. The description adds value by emphasizing the beta group filter, but it does not explain limit or filterEmail behavior beyond what the schema already provides. Baseline 3 is appropriate.
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 ('beta testers'), and notes an optional filter by beta group. This clearly distinguishes it from sibling tools like list_beta_groups (groups), list_users (users), and add_beta_tester (mutation).
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 phrase 'optionally filtered by beta group' implies a use case for listing testers with or without a group filter, but it does not explicitly state when to prefer this over similar tools like list_users or list_beta_groups. There is no when-not-to-use guidance or mention of alternatives.
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 present, so the description must carry the transparency burden. It only states the read operation and filtering, but does not disclose pagination, defaults, response format, or any prerequisites. For a benign list tool this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb and resource. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with four well-documented parameters and no output schema, the description is sufficiently complete. It could mention pagination or a note to use get_build for a single build, but the core behavior is clear.
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 100%, so the baseline is 3. The description mentions filtering by state/version, which maps to schema parameters but adds no new semantics beyond rephrasing what the schema already provides.
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 clearly states 'List builds for an app' with a specific verb and resource. It also mentions filtering by state or version, which distinguishes this listing operation from singular get_build and other 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The filtering context implies usage for browsing builds by state/version, but it does not contrast with sibling tools like get_build or list_app_versions.
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 full burden. 'List' implies a read-only operation, and 'registered devices' scopes the action. However, it does not disclose pagination, response format, or any potential side effects, leaving key behavioral traits unstated.
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 action and resource. It contains no redundant words and is highly scannable.
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?
There is no output schema, and the description does not explain what fields a returned device contains, whether results are paginated, or how the optional filters and limit parameter affect the response. For an agent to effectively use the tool, this missing context is significant.
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 100% for all three parameters (limit, filterStatus, filterPlatform), so the baseline is 3. The description itself adds no additional parameter-specific information, so no bonus beyond the schema is provided.
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 'registered devices' with clear scope 'in your developer account', making it distinct from sibling tools like list_apps and list_builds. It clearly communicates what the tool does.
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 (for listing devices), and the resource focus distinguishes it from alternatives. It does not explicitly state when-not-to-use or name alternatives, but the context is clear enough for an agent to select it appropriately.
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 the tool lists users and roles, but does not disclose behavioral details such as pagination, default limits, sorting, or error behavior. The phrase 'all users' could mislead given the limit parameter, and no response format is described.
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, clear sentence that fully conveys the purpose. There is no unnecessary repetition or filler, making it highly concise.
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 list tool, the description is adequately complete given the schema includes parameter descriptions and constraints. It lacks details about return format or pagination, but these are not critical for a straightforward list operation and no output schema exists.
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 100%, so each parameter is already well-documented in the schema. The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate because the schema carries the load.
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: 'List all users (team members) and their roles in App Store Connect.' It clearly identifies the tool's function and scope, and there is no sibling tool for user listing, so it stands alone unambiguously.
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 needing to list users/team members and roles). It doesn't provide explicit exclusions or alternatives, but since no sibling tool overlaps with this function, explicit guidance is not necessary.
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 disclose behavior. It states the required state and the action, but does not mention potential errors, reversibility, or impact of submission. This is minimal but adequate for a simple 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?
Two short sentences, no fluff. Every word earns its place: one states the action, the other adds the key precondition. Highly efficient.
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 tool with only one parameter and no output schema, the description covers the essential context: what it does and the required state. It could mention what happens after submission, but that may be self-evident or handled by App Store Connect.
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 already fully describes the parameter ('The app store version ID to submit') with 100% coverage. The description adds the READY_FOR_REVIEW requirement, but does not need to add more. Baseline of 3 applies since schema handles the 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 ('Submit') with a clear resource ('app store version') and purpose ('for App Review'), which distinguishes it from sibling tools like respond_to_review or get_app_version. It leaves no ambiguity about what the tool does.
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 provides a clear prerequisite ('version must be in READY_FOR_REVIEW state'), which helps the agent know when the tool is applicable. It does not explicitly discuss alternatives, but sibling names are mostly list/get tools, making this the obvious action tool.
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:

[![asc-mcp-server MCP server](https://glama.ai/mcp/servers/mohn93/asc-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mohn93/asc-mcp-server)

Score Badge

Copy to your README.md:

[![asc-mcp-server MCP server](https://glama.ai/mcp/servers/mohn93/asc-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mohn93/asc-mcp-server)

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/mohn93/asc-mcp-server'

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