Prism

Official

by Crossdeckhq

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation4/5
Most tools target distinct resources (projects, customers, errors, hosts, revenue, costs). However, get_customer and open_moat_dashboard both return overlapping customer info (payment, entitlements, read-cost) with different output formats, which could cause selection ambiguity.
Naming Consistency4/5
Tools follow a consistent imperative_underscore pattern with verbs like get_, list_, draw_, open_, and use_. The naming is clear and predictable, though the verb choice varies appropriately across actions.
Tool Count5/5
With 11 tools covering project management, customer insights, error analysis, host analytics, and revenue/costs, the set is well-scoped for a product analytics platform. Each tool serves a distinct purpose without redundancy.
Completeness4/5
The core analytics needs are covered: customer overview, error impact, traffic analysis, revenue tracking, and cost breakdown. Minor gaps like user-level event logs or data export are acceptable given the server's focus on cross-layer analytics.
Average 4.4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 29, 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.
This repository includes a glama.json configuration file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool sets session state and persists across calls, implying mutation. However, annotations declare readOnlyHint: true, which contradicts this. Per guidelines, description contradicts annotations, so score is 1 and annotation_contradiction is true.
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?
Three sentences with no wasted words. Front-loaded with action and behavior, then return value and usage context, ending with an edge case. Efficient and well-structured.
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?
Description covers purpose, behavior, return value, prerequisites, and edge cases. No output schema exists, but return format is described. The annotation contradiction creates some confusion, but the description itself is complete for an agent to use correctly.
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?
Schema coverage is 100% for the single parameter. Description adds meaning by specifying the source ('copied from list_projects') and providing an example ID format. This goes beyond the schema's type-only definition.
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 sets the current app/project for the conversation, using verbs 'Set' and 'defaults'. It distinguishes from sibling list_projects by explaining it selects rather than lists. Sibling context confirms uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('switch to <app>'), prerequisite ('call list_projects first'), and an edge case ('No effect with a single-app key'). Provides complete 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?
Annotations already declare readOnlyHint=true. The description adds context beyond annotations, explaining per-user attribution via Crossdeck and SDK identity, and lists the return structure (totals and breakdown). No contradictions.
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 three sentences, front-loading the main purpose. It is efficient without being overly verbose, but could be slightly more concise by removing the redundant statement about returns.
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 no output schema, the description adequately explains what is returned (per-user vs overhead totals and by-operation breakdown). Parameter documentation is complete in schema. The description is sufficient for the tool's moderate 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 baseline is 3. The description does not add significant extra meaning beyond the schema; it mentions 'last `days` days' but doesn't elaborate on the project parameter or provide additional constraints.
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 it gets an app's database read-cost over a period, split into per-user reads vs overhead, and breakdown by operation. It uses specific verb 'Get' and resource 'database read-cost', and distinguishes from siblings like get_revenue or get_error_affected_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'what's driving our database reads' or 'which operation costs the most'. It does not explicitly state when not to use or compare to alternatives, but the context is clear enough for an agent to decide.
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?
Annotations already mark readOnlyHint=true. The description adds that it returns aggregates and daily series, and warns of 403 for unverified hosts, providing useful behavioral context beyond annotations.
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?
Three concise sentences, front-loaded with verb and resource, no unnecessary 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 adequately explains return values and constraints. Given the tool's 4 parameters and no output schema, it provides sufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats parameter info (e.g., granularity adds daily series) without adding new meaning beyond what's 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 clearly states the tool gets headless web analytics for one host/subdomain, specifies output (page views, unique visitors, daily series), and differentiates from sibling tools like get_host_top_pages or draw_user_growth.
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 says 'Use for per-tenant or per-subdomain traffic questions' and mentions the host verification constraint. However, it does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description adds behavioral guarantees: it's a point-read (never a scan), implying cheap and consistent. It also explains behavior for empty revenue (returns zeros, not error). No contradiction with annotations.
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?
Description is three sentences with no wasted words. Front-loaded with main purpose, followed by return details and usage examples. Perfectly 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?
No output schema, but description partially compensates by listing return fields. Covers behavior for zero revenue. However, does not specify exact output format or structure, leaving some inference needed. Adequate for a simple read 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?
Schema description coverage is 100%, so baseline is 3. Description reinforces the relationship between granularity and days but adds minimal new parameter-level info beyond schema. It does provide high-level context for how parameters interact.
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 'Get an app's recurring revenue' with specific verb and resource. It specifies it's a point-read, not a scan, and lists exact return fields (MRR, customer count, per-rail split). This differentiates it from siblings like draw_user_growth or get_customer.
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?
Description explicitly states use cases: 'what's our MRR', 'how many paying customers', or revenue-trend questions. It also notes that zero revenue returns zeros, not an error. However, it does not explicitly mention when not to use it or name alternative 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?
Annotations already declare readOnlyHint=true, so the description adds value by describing output format variation (rendered vs. text depending on host) and the no-match behavior. No contradictions with annotations.
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?
Description is concise, front-loaded with the core purpose, and every sentence adds value. No redundant or unnecessary information.
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 the complexity (7 optional params, no output schema), the description covers key aspects: dashboard contents, identifier interchangeability, output format variation, and no-match handling. It could mention the project dependency (covered in schema) but overall is sufficient.
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?
Schema description coverage is 100%, so parameters are well-documented. The description adds useful context that only one identifier is needed and they all resolve to the same customer, which is not in the schema. This clarifies usage patterns.
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 the tool renders a customer's cross-layer dashboard with specific components (pay, entitlements, read-cost) and returns a text summary or rendered dashboard. It distinguishes from siblings like get_customer, get_revenue, and get_read_cost which focus on individual pieces.
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?
Explicitly says 'Use when asked to show, open, or visualize a customer's full picture.' It doesn't explicitly state when not to use or mention alternatives, but the context from sibling tools provides differentiation. The guidance is clear and actionable.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds behavioral value by specifying that the tool returns only counts and not named users, detailing the exact output fields. However, it does not disclose additional behavioral traits like pagination or performance, so it falls short of a 5.
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 plus a third for alternative guidance. It is front-loaded with the core action and outputs, with no extraneous information. Every sentence serves a purpose: defining the tool, specifying outputs, and directing to a sibling when needed.
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?
Despite lacking an output schema, the description fully describes the return values (distinct users, paying customer count, error type, status, counts, timestamps). It also specifies the input as a fingerprint from the Crossdeck Errors view and mentions the sibling tool for detailed data. For a tool of this complexity, this is 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?
Schema description coverage is 100%, with each parameter having a detailed description (e.g., project explains required vs. ignored conditions). The tool description only adds 'by fingerprint/issue id' for the fingerprint parameter, which is already implied by the schema description. Hence, the description adds minimal semantic value beyond the schema, warranting a baseline 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 clearly states the tool gets blast radius for one error by fingerprint, listing specific outputs (distinct users, paying customers, error metadata). It distinguishes itself from sibling 'get_error_affected_users' by noting that this tool returns only counts, while the sibling provides named users and revenue. This meets the criteria for a specific verb+resource and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('Use to size an error's impact') and when to use an alternative ('For the NAMED paying users... call get_error_affected_users instead'). This provides clear context and exclusion, which is the top tier of 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?
Annotations declare readOnlyHint=true, and the description adds behavioral context: returns sorted paginated rows, host ownership requirement, and dimension switching for referrers. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences), front-loaded with the main purpose, and every sentence adds necessary information without fluff.
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?
No output schema, but the description sufficiently explains the return shape ({key, views} rows). Covers pagination, ranking, host ownership, and parameter use. Complete for the tool's complexity.
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?
Schema has 100% coverage with descriptions. The description adds value by explaining the dimension parameter's specific usage ('Set dimension='top_referrers' for traffic sources') and clarifying the output format.
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 it retrieves top pages or referrers for a host, with specific verb and resource, and distinguishes from siblings like get_host_analytics by specifying the exact output and use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('most-viewed pages on this subdomain' or 'where its traffic comes from'), implying when to use. It does not explicitly mention when not to use or alternatives, but the context is clear enough.
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?
Annotations already mark the tool as read-only. The description adds behavioral context: it returns specific fields (monthly cents, entitlement count, read-cost) and explains the no-match handling. This goes beyond the annotations but does not cover permissions 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 concise (about 120 words) and structured logically: first sentence for purpose, second for outputs, third for parameter usage, fourth for use case, fifth for edge case. No wasted words, front-loaded with key information.
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?
Despite no output schema, the description clearly states what is returned (monthly cents, entitlement count, read-cost). It also covers the no-match case. With 7 optional parameters, the description explains how to use them (any one). This makes the tool's behavior fully comprehensible for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with individual descriptions, but the description adds crucial semantics: 'Identify the person by ANY ONE of the identifiers below; they all resolve to the same canonical customer.' This clarifies mutual exclusivity and selection logic, which is valuable beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to cross-match a customer across identity layers and return billing and cost data. It specifies the resource (customer) and the verb (cross-match/get), and distinguishes from siblings like get_revenue by offering a combined view.
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 explicitly says 'Use for how much does this user pay and what do they cost us?' which gives a clear use case. It also mentions that a no-match returns an informational result rather than an error. However, it does not explicitly mention when not to use this tool or reference sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the tool returns a rendered chart in MCP-Apps-capable hosts and a text summary elsewhere, plus the period totals. It also reveals rejection behavior for unverified hosts, adding critical context annotations alone do not provide.
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: the first precisely states function and output, the second gives usage guidance and a condition. Every sentence adds value, and the key action is front-loaded. No superfluous words.
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 three parameters, no output schema, and no nested objects, the description fully covers the tool's behavior: it explains the return format (chart/text + totals), the environmental dependency (MCP-Apps-capable), and the host verification requirement. This is sufficient for the agent to handle diverse contexts.
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 coverage is 100%, so baseline is 3. The description adds no new parameter information beyond what the schema already provides (e.g., days default, host verification). However, it does not contradict or omit schema details, so a 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 tool renders an interactive line chart of unique visitors and page views over time for a verified host, and returns period totals as text. This specific verb-resource pairing distinguishes it from sibling tools like get_host_analytics or get_host_top_pages, which provide raw data without visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: 'Use when asked to chart, graph, draw, or visualize growth or traffic for a subdomain.' It also sets a precondition: 'The host must be a verified origin of the project, or the request is rejected,' guiding the agent on necessary validation before invocation.
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?
Description adds behavioral context beyond the readOnlyHint annotation, detailing joins across layers and sorting by revenue. No contradictions with annotations.
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?
Four sentences pack all essential information without fluff, front-loaded with the core purpose.
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 no output schema, description adequately describes return structure (user id, revenue, last hit time) and behavior. Complete for a 3-param read-only tool.
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?
Schema coverage is 100%, but description adds useful context: limit default, project parameter usage conditions, and that results are sorted by revenue. Adds value beyond 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?
Description clearly states the tool retrieves paying users affected by a specific error, sorted by revenue, with explicit distinction from sibling get_error_impact which only provides counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you need the actual customers, not just the counts from get_error_impact') and clarifies identifier handling.
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?
Description adds behavioral details beyond annotation (readOnlyHint=true): returns array of {id, name}, behavior with different key types, and that it takes no arguments.
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?
Five sentences, front-loaded with purpose, each sentence provides essential information without redundancy.
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?
Description fully covers purpose, usage, return format, and behavioral nuances for a simple read-only tool with no parameters and no output schema.
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?
Tool has zero parameters, baseline is 4. Description adds no param info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'apps/projects', clearly distinguishes from sibling tools like 'use_project' by stating return format and read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call this tool ('FIRST'), how to use results ('pass an id to other tools or set a default with use_project'), and behavior variance based on key type (single-app vs multi-app).
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:

[![crossdeck-prism MCP server](https://glama.ai/mcp/servers/Crossdeckhq/crossdeck-prism/badges/card.svg)](https://glama.ai/mcp/servers/Crossdeckhq/crossdeck-prism)

Score Badge

Copy to your README.md:

[![crossdeck-prism MCP server](https://glama.ai/mcp/servers/Crossdeckhq/crossdeck-prism/badges/score.svg)](https://glama.ai/mcp/servers/Crossdeckhq/crossdeck-prism)

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/Crossdeckhq/crossdeck-prism'

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