MAScope MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 6 of 6 tools scored.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/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 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and 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.
Usage Guidelines4/5
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.

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:

[![mascope-mcp MCP server](https://glama.ai/mcp/servers/bbb-build/mascope-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bbb-build/mascope-mcp)

Score Badge

Copy to your README.md:

[![mascope-mcp MCP server](https://glama.ai/mcp/servers/bbb-build/mascope-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bbb-build/mascope-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bbb-build/mascope-mcp'

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