Provides tools for searching Shopify apps, retrieving app details and reviews, analyzing review sentiment and pain points, comparing apps, listing categories, and getting top-ranked apps. With a paid plan, also accesses private app metrics like installs, uninstalls, and revenue.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@partnerlens-mcp Who are the top 10 apps in email-marketing right now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Shopify App Store intelligence — give Claude, Cursor, or any MCP client access to 17,000+ Shopify apps, 829,000+ reviews, category rankings, and AI-analyzed review sentiment, powered by the PartnerLens dataset.
Ask things like:
"What are merchants complaining about in Klaviyo's 1-star reviews this year?"
"Compare Judge.me, Loox, and Yotpo on rating trend and top pain points."
"Who are the top 10 apps in email-marketing right now?"
"Find underserved pain points in the upsell category I could build an app for."
"Did my uninstalls spike last month, and what are competitors' users complaining about?" (paid plan)
1. Get a free API key — sign up at partnerlens.app,
then Settings → API Keys → New Key (keys look like as_…).
2. Add the server to your client:
claude mcp add partnerlens -e PARTNERLENS_API_KEY=as_your_key -- npx -y partnerlens-mcpmcpServers JSON){
"mcpServers": {
"partnerlens": {
"command": "npx",
"args": ["-y", "partnerlens-mcp"],
"env": { "PARTNERLENS_API_KEY": "as_your_key" }
}
}
}Related MCP server: Store Scraper MCP
Tool | What it does |
| Search apps by name, developer, or slug |
| Full app detail: rating, categories, Built-for-Shopify, latest rank |
| Individual reviews, newest first, filterable by star rating |
| Rating distribution, sentiment, 12-month velocity, top pain points |
| 2–5 apps side by side with review summaries |
| All App Store categories with app counts |
| Current top-ranked apps in a category |
With a PartnerLens Unlimited plan and the Shopify Partner integration connected (Settings → Integrations), two more tools unlock your private Partner Dashboard data:
Tool | What it does |
| Your apps synced from your Shopify Partner organization |
| Your daily installs, uninstalls, active shops, revenue, MRR + movements, churn |
So Claude can answer things like "did my uninstalls spike after the price change, and how does my rating trend compare to my top competitor's?" — your data and market data in one conversation. Free keys get a clear message explaining the requirement; the public tools above work for everyone.
The same binary serves stateless Streamable HTTP for remote deployment:
partnerlens-mcp --http --port 3333
# endpoint: http://localhost:3333/mcpIn HTTP mode each request's Authorization: Bearer as_… header is forwarded to
the PartnerLens API — the server stores nothing and keeps no sessions.
Variable | Purpose |
| Required in stdio mode. Free at partnerlens.app |
| Override API base (default |
| HTTP port when |
60 requests/minute and 1,000 requests/day per key. Responses carry
X-RateLimit-* headers. Need more? Talk to us.
pnpm install
pnpm test # vitest
pnpm typecheck
pnpm build # tsup → dist/PRs welcome — tools live in src/tools.ts as plain data and are unit-tested without a transport.
MIT
Compare 2-5 Shopify apps side by side: metadata plus each app’s aggregate review summary. Ideal for competitor analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | 2-5 app slugs to compare |
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 describes the action but does not disclose behavioral traits such as read-only nature, error handling for invalid slugs, or any side effects. The description is insufficient for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a short tagline, both concise and front-loaded. Every part adds value: the core action, the scope, the output, and a usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the purpose and input range. However, it lacks any detail about the output format or behavior on invalid input, which are gaps for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'slugs' parameter well-documented (pattern, note about search_apps). The description adds meaning beyond the schema by specifying the comparison includes metadata and review summaries, and the use case for competitor analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2-5 Shopify apps side by side, listing what is compared (metadata and aggregate review summary). It distinguishes itself from siblings like get_app (single app) and get_app_reviews (reviews for one app) by specifying the comparative nature and the number of apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Ideal for competitor analysis,' which provides context for when to use the tool. However, it does not explicitly state when not to use it or name alternative tools. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for one Shopify app by slug: description, developer, rating, review count, categories, Built-for-Shopify status, launch date, and its latest rank in its primary category.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | App Store slug — the last path segment of apps.shopify.com/<slug>. Use search_apps first if you only know the app name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses returned fields but does not explicitly state read-only nature or any restrictions, though 'Get' implies safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 22 words, front-loaded with action and output, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description lists all returned fields and provides sufficient context for usage, though it lacks error handling info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter with description; the tool description adds context by explaining the slug format and linking to search_apps, exceeding the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for one Shopify app by slug' and lists specific fields (description, developer, rating, etc.), distinguishing it from sibling tools like search_apps and get_top_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use search_apps first if you only know the app name,' providing clear when-to-use and alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read individual reviews for a Shopify app, newest first. Optionally filter by star rating (e.g. rating=1 surfaces complaints and churn reasons; rating=5 surfaces what users love). Paged.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | App Store slug — the last path segment of apps.shopify.com/<slug>. Use search_apps first if you only know the app name. | |
| rating | No | Filter to one star rating | |
| page | No | Page number (default 1) | |
| per_page | No | Reviews per page (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it reads reviews (read-only), pages, and orders newest first. It does not mention rate limits, authentication, or empty results, but the core behavior is clear. This is adequate, not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first defines purpose and ordering; the second adds filtering guidance. No superfluous words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, the description could optionally mention return structure, but it covers the essential aspects: what it reads, filtering, paging, and ordering. Given the tool's simplicity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds value by giving concrete examples for the rating parameter (e.g., complaints, churn reasons). This enhances understanding beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'individual reviews for a Shopify app', and specifies ordering 'newest first'. It distinguishes from siblings like search_apps and get_review_summary by focusing on individual reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for using rating filters with examples (e.g., rating=1 for complaints, rating=5 for positive). It does not explicitly state when to use this tool versus siblings, but the examples imply usage for sentiment analysis. The schema note about using search_apps first is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List YOUR OWN apps synced from your Shopify Partner organization (name, handle, partner app id). Requires a PartnerLens Unlimited plan and the Shopify Partner integration connected in Settings → Integrations. Returns an empty list until the integration has synced. Use the returned id with get_my_metrics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds context about plan requirement, sync dependency, and return behavior. However, lacks details on read-only nature, rate limits, or error states. Barely adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then prerequisites, then usage hint. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, description covers purpose, prerequisites, synchronization behavior, and next-step usage. Complete for agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters; schema covers 100%. Baseline score of 4 is appropriate as no additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists the user's own apps with specific attributes (name, handle, partner app id). Distinct from siblings like get_app (single app) and search_apps (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies prerequisites (PartnerLens Unlimited plan, integration connected) and behavior until sync. Also advises using returned id with get_my_metrics. Lacks explicit when-not-to-use but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YOUR OWN private daily Partner Dashboard metrics: installs, uninstalls, active shops, gross/net revenue, MRR with movement breakdown (new/expansion/contraction/churned), and churn rate. Defaults to the last 30 days (max 366). Requires a PartnerLens Unlimited plan with the Shopify Partner integration connected. Combine with public tools to compare your performance against competitors.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Partner app id from get_my_apps (omit for all your apps) | |
| from | No | Start date (default: 30 days ago) | |
| to | No | End date (default: today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses private nature, plan requirement, and return metrics. Falls short of detailing exact behavior like read-only (implied), error states, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph with no fluff. Every sentence adds information: what, defaults, requirements, and usage hint. Could be slightly more structured (e.g., separate prerequisites), but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all essential aspects: what metrics are returned, default time range, parameter behavior, prerequisites, and suggested combination with other tools. Comprehensive for a data-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, baseline 3. Description adds value beyond schema by explaining 'app' as 'Partner app id from get_my_apps (omit for all your apps)' and clarifying date defaults (30 days ago, today).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'get' and resource 'metrics' with clear scope ('YOUR OWN private daily Partner Dashboard metrics'). Distinct from sibling tools like 'get_top_apps' (public) and 'search_apps' (public), making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides key context: defaults to last 30 days (max 366), requires PartnerLens Unlimited plan with Shopify integration, and suggests combining with public tools for comparison. Lacks explicit 'when not to use', but the contrast with sibling tools is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate review intelligence for a Shopify app: rating distribution, sentiment breakdown (positive/negative/neutral), review velocity per month for the last 12 months, and the top AI-extracted pain points. Much cheaper than reading raw reviews — start here for app health.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | App Store slug — the last path segment of apps.shopify.com/<slug>. Use search_apps first if you only know the app name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It lists outputs but does not disclose authentication needs, rate limits, or side effects. The behavior is implied to be read-only but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence lists the outputs and the second gives a usage suggestion. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage and no output schema, the description lists the return values adequately. It provides context with sibling tools and suggests this as a starting point, but could mention error handling or data availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'slug' has 100% schema description coverage with a clear explanation. The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it aggregates review intelligence and lists specific analytics (rating distribution, sentiment, velocity, pain points). It distinguishes from raw reviews by saying 'Much cheaper than reading raw reviews' and implies it's for app health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by saying 'start here for app health' and contrasting with raw reviews. However, it does not explicitly exclude other sibling tools like compare_apps or get_app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current top-ranked apps in a Shopify App Store category, from the latest scrape. Returns position, app metadata, rating, and review count.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug from list_categories | |
| limit | No | Max apps (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the data source ('from the latest scrape') and output fields, but doesn't mention auth needs, rate limits, or if data is cached. However, it adequately describes the tool's behavior for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no redundant words. Efficiently communicates purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with low complexity, the description is complete. It specifies input (category, optional limit), output contents, and data freshness. No output schema needed given the clear output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by noting the category slug comes from list_categories and that limit defaults to 25, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current top-ranked apps in a Shopify App Store category, specifying it's from the latest scrape and listing output fields (position, app metadata, rating, review count). This distinguishes it from siblings like get_app (single app) and search_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when wanting top-ranked apps by category, but provides no explicit guidance on when not to use or compare to alternatives like search_apps. No exclusion criteria or usage context beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Shopify App Store categories with app counts, largest first. Use the returned slugs with get_top_apps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool lists categories with counts and ordering. It does not describe side effects (none expected) or rate limits, but the behavior is simple and fully described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose and a follow-up usage hint. Every word earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple list return, the description is complete enough. It explains what is returned and how to use it. Could add detail on pagination or total count, but not necessary for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter details. The baseline of 4 is appropriate as the description adds value beyond the schema by explaining the output ordering and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Shopify App Store categories with app counts, sorted largest first. It differentiates itself from siblings by specifying a unique purpose and output usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on what to do with the output ('Use the returned slugs with get_top_apps'), which helps the agent understand the tool's role in a workflow. It lacks explicit when-not-to-use instructions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Shopify App Store dataset (17k+ apps) by app name, developer name, or slug. Returns matching apps with rating, review count, and categories. Use this first to resolve an app name to its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | App or developer name to search for | |
| limit | No | Max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It describes the dataset size and return fields, but lacks disclosure of potential behaviors like rate limits, pagination, or error handling. For a simple search, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose and scope, second provides actionable guidance. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description covers the action, returned data, and usage context. It lacks details about response format or no-result handling, but is mostly complete given the tool's simplicity and the presence of sibling tools that provide further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described in the input schema. The description adds context about return fields but does not enhance parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Shopify App Store by app name, developer name, or slug, and specifies the returned fields (rating, review count, categories). It also distinguishes itself by indicating its role in resolving app names to slugs, which differentiates it from siblings like get_app that require a slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first to resolve an app name to its slug,' providing clear guidance on when to use this tool before others. It does not mention when not to use or list alternatives, but the directive is strong enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0compare_appsget_appget_app_reviewsget_my_appsget_my_metricsget_review_summaryget_top_appslist_categoriessearch_appsEach tool targets a distinct operation: comparing apps, fetching details, reviews, summaries, searching, listing categories, top apps, and private metrics. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_app, list_categories, search_apps), making it easy for agents to infer functionality.
Nine tools cover the domain of Shopify app analytics and partner metrics comprehensively without unnecessary bloat or missing essentials.
The set provides full lifecycle coverage: discovery (search, categories, top apps), detailed info (get_app), reviews (get_app_reviews, get_review_summary), comparison (compare_apps), and partner private metrics (get_my_apps, get_my_metrics). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shopify App Store intelligence: keyword ranks, competitors, reviews, revenue. Free tier.
Scrape Shopify App Store apps, full review histories and catalog. E-commerce market research.
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
Track app-store rankings, history, listing metadata, reviews and competitors across four stores.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seven-hills-software/partnerlens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
