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., "@MAScope MCP Server search for meditation mini apps"
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 MAScope — World MiniApp reviews and analytics data, powered by verified humans.
Every review on MAScope is posted by a human verified through World ID proof-of-personhood. No bots. No fakes. Real reviews.
Tool | Description |
| Search World MiniApps by keyword, category, or sort criteria |
| Get detailed info about a specific MiniApp (rank, users, trend) |
| Get verified reviews with ratings, comments, and distribution |
| Get trending apps sorted by growth rate |
| Category breakdown with app count and top apps |
| Compare 2-5 apps side by side |
Related MCP server: mcp-store-scraper
Add to claude_desktop_config.json:
{
"mcpServers": {
"mascope": {
"command": "npx",
"args": ["-y", "mascope-mcp"]
}
}
}claude mcp add mascope -- npx -y mascope-mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"mascope": {
"command": "npx",
"args": ["-y", "mascope-mcp"]
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"mascope": {
"command": "npx",
"args": ["-y", "mascope-mcp"]
}
}
}Free tier: 100 API calls/day per IP address. Rate limit headers are included in all responses.
MIT
Compare 2-5 World MiniApps side by side. Returns rank, users, opens, rating, review count, and trend data for each app. Useful for competitive analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Comma-separated MiniApp UUIDs (2-5 apps). Get IDs from search_miniapps. | |
| locale | No | Description language (default: en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly says 'Returns...' which implies a read-only operation, and lists the output fields, giving a clear picture of behavior. It does not mention rate limits or error handling, but for a comparison read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and each sentence adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is reasonably simple with two parameters and no output schema. The description compensates by listing the specific return fields and the use case. It lacks explicit output structure or error behavior, but overall it gives a clear and sufficient picture for an agent to use the 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 100% coverage with descriptions for both parameters. The description adds the count constraint (2-5 apps) which is also present in the ids parameter description. No additional semantic meaning is provided beyond what the schema already documents.
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 MiniApps side by side, which is a specific verb+resource. It also enumerates the returned data (rank, users, opens, rating, review count, trend), differentiating it from sibling tools like get_app_details or search_miniapps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('useful for competitive analysis') and implies a multi-app comparison context. It does not explicitly exclude siblings or state when-not-to-use, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific World MiniApp, including rank, user metrics, verified ratings, trend data (7-day sparkline), and developer info.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | MiniApp UUID (get from search_miniapps results) | |
| locale | No | Description language: en, ja, es, ko, pt, zh, zh-TW (default: en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly says 'Get detailed information', indicating a read-only operation, and lists the specific data returned (rank, metrics, ratings, sparkline, developer info). This conveys key behavioral traits, though it does not mention potential errors or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, and efficiently lists the included data points without any redundant or irrelevant content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 2-parameter read tool with rich schema coverage and no output schema. The description explains what is returned (rank, metrics, ratings, trend, developer info), making it complete for a basic get-details scenario. It lacks mention of error handling or edge cases, but given the simplicity, this is not a significant gap.
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 clear descriptions for app_id (including source hint) and locale (enumerated values and default). The description adds no additional parameter detail beyond what the schema provides, so baseline 3 applies.
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 'Get' and the resource 'detailed information about a specific World MiniApp', listing specific data points (rank, user metrics, verified ratings, trend data, developer info). This distinguishes it from sibling tools like search_miniapps (list) and get_app_reviews (reviews only).
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 a workflow by referencing 'specific' app and the app_id parameter says 'get from search_miniapps results', providing clear context for when to use this tool (after search). It does not explicitly name alternatives or exclusions, but the link to search_miniapps gives usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get World ID-verified reviews for a MiniApp. Every review is posted by a human verified through proof-of-personhood. Includes ratings, comments, sub-ratings (usability/recommendation/reliability), and a summary with rating distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by: recent (default) or helpful (most helpful first) | |
| limit | No | Reviews per page (1-50, default 10) | |
| app_id | Yes | MiniApp UUID | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful context about World ID-verified reviews and the inclusion of sub-ratings/summary, but it does not disclose pagination behavior, default values, or edge cases (e.g., no reviews found). This is a moderate disclosure level.
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 long, with the main purpose in the first sentence and supporting content in the second. No fluff or repetition of schema details. Perfectly front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward review-listing operation. The description covers the key return content (ratings, comments, sub-ratings, summary) even without an output schema. It could mention pagination explicitly, but the schema already provides pagination parameters, making it sufficiently complete for the complexity level.
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 provides 100% coverage with detailed descriptions for all four parameters (sort, limit, app_id, offset), so the description needs to add minimal extra. It does not elaborate on parameter semantics beyond what the schema already contains, keeping the baseline score.
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 gets reviews for a MiniApp, with specific verb+resource (Get ... reviews). It lists the exact content (ratings, comments, sub-ratings, summary) and distinguishes it from sibling tools like search_miniapps or get_app_details by focusing solely on 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 clearly implies this is for retrieving reviews of a specific MiniApp, which sets expectations against get_app_details. However, it does not explicitly state when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a breakdown of all World MiniApp categories with app count, total weekly users, and top 3 apps per category. Useful for understanding the MiniApp ecosystem landscape.
| 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 burden of disclosing behavior. It clearly states the output contents (app count, total weekly users, top 3 apps per category), implying a read-only aggregate operation. It does not mention data freshness, sorting, or potential limitations, but for a simple analytics tool this is adequate.
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 redundancy, front-loaded with the primary action and outcome. Every word contributes to understanding the tool's purpose and 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?
Given the tool's simplicity (no parameters, no output schema, no nested objects), the description is complete. It specifies the returned breakdown, and sibling tools clearly cover different use cases, so no missing context is evident.
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 tool has zero parameters, so there is nothing to explain. The baseline for 0 parameters is 4, and the description appropriately focuses on the output rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource: a breakdown of all World MiniApp categories, including app count, total weekly users, and top 3 apps per category. This distinguishes it from sibling tools like get_app_details or search_miniapps, which focus on individual 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?
It provides a clear usage context: 'Useful for understanding the MiniApp ecosystem landscape.' While it doesn't explicitly contrast with alternatives, the context implies this tool is for high-level category analytics rather than individual app lookups. A more explicit comparison would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently trending World MiniApps sorted by growth rate. Shows which apps are gaining users or opens the fastest, with trend direction, change percentage, and sparkline data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of trending apps (1-20, default 10) | |
| locale | No | Description language (default: en) | |
| metric | No | Metric to measure trends: users (default) or opens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses what data is returned (trend direction, change percentage, sparkline data) and the sorting logic (by growth rate). It does not discuss rate limits or refresh cadence, but for a read-only list tool this is acceptable.
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, information-dense sentence that communicates purpose, scope, sorting, and output data. It is front-loaded and contains no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and the nature of its output well. There is no output schema, so the mention of trend direction, change percentage, and sparkline data is valuable. It could mention pagination or refresh cadence, but for a simple trending list with optional limit, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete parameter descriptions, covering limit, locale, and metric. The description adds no additional parameter semantics, so the baseline score of 3 applies since schema coverage is 100%.
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's function: retrieving currently trending World MiniApps sorted by growth rate. It also includes the key differentiator (trending vs. search/details/reviews), making it easy to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for identifying trending apps by growth rate. It does not explicitly name alternatives or state when not to use it, but the unique 'trending' focus sufficiently implies its use case relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search World MiniApps by keyword, category, or sort criteria. Returns app name, description, rank, weekly users, rating, and review count. All reviews on MAScope are verified by World ID (proof-of-personhood).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by: rank (default), users (weekly active), opens (weekly opens) | |
| limit | No | Results per page (1-50, default 20) | |
| query | No | Search keyword (matches app name or description) | |
| locale | No | Description language: en, ja, es, ko, pt, zh, zh-TW (default: en) | |
| offset | No | Pagination offset (default 0) | |
| category | No | Filter by category name (e.g., "DeFi", "Social", "Gaming", "Utilities") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly lists the returned fields (app name, description, rank, weekly users, rating, review count) and adds a unique trust statement about World ID verification. However, it does not mention pagination, authentication, or rate limits, though the read-only nature of 'search' is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and search criteria, and includes valuable output field details without unnecessary fluff. Every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description compensates by enumerating the returned fields, which is critical for agent expectations. The 6-parameter tool is well-covered by the schema, and the description adds the verification context. It lacks minor details like default sort order or error behavior, but these are not essential for a read-only search 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 schema already provides 100% coverage of all six parameters with descriptions, so the baseline is 3. The description reinforces the roles of query, category, and sort but adds no new details beyond what the schema already states. It does not explain limit, offset, or locale, but those are adequately documented in 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 uses the specific verb 'Search' and clearly identifies the resource 'World MiniApps' along with the search dimensions (keyword, category, sort). It differentiates itself from sibling tools like get_app_details and get_trending_apps by focusing on general search/filter rather than specifics or trending lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering apps via search and filtering, but it does not explicitly mention when to prefer this over siblings. There is no 'when not to use' or alternative tool guidance, so the usage context is inferred from the action rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1compare_appsget_app_detailsget_app_reviewsget_category_analyticsget_trending_appssearch_miniappsScored across 6 tools
Each tool has a clear, non-overlapping purpose: search, get details, get reviews, get trending, category analytics, and compare. No two tools appear to do the same thing, reducing agent misselection.
All tool names follow a consistent snake_case verb_noun pattern (search_miniapps, get_app_details, get_app_reviews, get_trending_apps, get_category_analytics, compare_apps). The dominant get_ prefix and consistent style make naming predictable.
With 6 tools, the server is well-scoped for a MiniApp directory/analytics service. Each tool covers a distinct aspect of discovery and analysis without redundancy or bloat.
The tool set covers the core read-only workflows: search, details, reviews, trends, category ecosystem, and comparison. A minor gap is lack of a direct 'list all apps in category' endpoint, but category analytics partially addresses this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server registry — validated by live handshake, scored on reliability, monitored continuously.
Trust verification for MCP servers. Check scores, scan for security issues, search 4,200+ servers.
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
