Skip to main content
Glama
Crossdeckhq

Prism

Official
by Crossdeckhq
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Prism — Crossdeck's intelligence layer for AI

Ask your app anything — revenue, errors, database read-cost, growth — in plain English, and get rendered charts and dashboards back.

npm version License: MIT MCP OAuth 2.1 Read-only

"Which paying customer did this crash hit, and how much revenue is at risk?" — one question, answered across error, identity, and revenue. No single-layer tool can do that.

Why Prism is different

Most MCP servers are a connector to one system. Prism is an intelligence layer over your whole app — because Crossdeck already joins the layers about your users (identity · revenue · entitlements · errors · analytics · database read-cost) into one source of truth, by identity.

The point isn't "let AI read my data." It's the crossing: one question can span layers no other tool joins —

"This error a1b2c3 — who did it hit, and how many of them pay us?" → the named paying users behind the crash, each with their monthly revenue at risk, sorted by what's on the line.

That's the moat sentence. Prism gives it a voice in Claude, ChatGPT, Cursor, or any MCP client.

Related MCP server: SLayer

Permissions & data access

Secure, read-only access to your live Crossdeck workspace. Prism reads; it never writes.

Prism can see (the layers Crossdeck already owns about your app):

💷 Revenue

MRR, paying-customer counts, per-rail split

🐛 Errors

issues, blast radius, who was affected

📈 Analytics

per-host page views, unique visitors, top pages/referrers

🗄️ Read-cost

per-user-vs-overhead database reads, by operation

🧭 Customer journeys

the cross-layer view of one customer (pay × entitlements × cost)

Row-level customer identity is returned only when your connection was explicitly granted that scope — otherwise Prism answers from aggregates and tells you so. That boundary is enforced by Crossdeck, not left to the model.

Prism cannot create, modify, delete, or configure anything in your projects. There is no write path — every tool is read-only (readOnlyHint: true). Ask it to change something and it will tell you it can't.

Data is fetched live at question time over an OAuth-protected endpoint; the connector stores nothing.

Connect in 60 seconds

Remote (recommended) — one-click OAuth, no keys to paste

Prism is a hosted, OAuth-protected MCP endpoint:

https://api.cross-deck.com/mcp

Add it as a connector in your client, sign in with your Crossdeck account, pick a project, and approve. That's it — the client receives a short-lived, scoped workspace credential automatically.

  • Claude (web / desktop): Settings → Connectors → Add custom connector → paste the URL above.

  • ChatGPT: Settings → Connectors → Add → paste the URL.

  • Cursor: Settings → MCP → Add → paste the URL.

Or open your dashboard at app.cross-deck.com → Developers → Prism → Connect AI for one-click "Add to Claude / ChatGPT / Cursor".

Local (Claude Desktop / Cursor / Claude Code) — stdio + a secret key

No install step — npx fetches the package and its dependencies on each launch, so it self-heals and stays current (nothing local to go stale):

{
  "mcpServers": {
    "crossdeck": {
      "command": "npx",
      "args": ["-y", "@cross-deck/ai"],
      "env": { "CROSSDECK_SECRET_KEY": "cd_sk_live_…" }
    }
  }
}

Use a secret key (cd_sk_) from your dashboard → API keys — never a publishable (cd_pub_) one. CROSSDECK_API_BASE overrides the endpoint (e.g. sandbox).

If the connector shows "failed" / "Server disconnected" — two known causes, both fixable:

  1. spawn npx ENOENT / command not found. Desktop clients launch with a minimal PATH that often excludes your Node bin (common with nvm). Fix: use the absolute path to npx as command — run which npx and paste the full path (e.g. /Users/you/.nvm/versions/node/vX/bin/npx).

  2. ERR_MODULE_NOT_FOUND … @modelcontextprotocol/sdk. This only happens if args points at a hand-built local checkout (…/dist/server.js) — that folder's node_modules can be cleaned out from under you (e.g. anything under /tmp). Fix: never point at a local build. Let npx -y @cross-deck/ai (above) resolve the published package, so its dependencies are always present.

Simplest of all: use the remote connector at the top of this section — it runs no local Node at all, so neither failure can occur.

Try these first

Ask

Tool

You get

"What's our MRR and paying-customer count, split by Stripe/Apple/Google?"

get_revenue

MRR, paying count, three-rail split, optional daily trend

"This error a1b2c3 — who did it hit and do any of them pay us?"

get_error_affected_users

The named paying users behind the crash, each with monthly revenue at risk

"Show me everything about customer agent_8842."

open_moat_dashboard

A rendered dashboard: what they pay × entitlements × read-cost, joined by identity

"Draw our user growth over the last 30 days."

draw_user_growth

A rendered interactive line chart of visitors + page views

"What's driving our database reads — per-user vs overhead?"

get_read_cost

The per-user-vs-overhead split + reads by operation

Data tools return clean JSON; draw_user_growth and open_moat_dashboard render interactive charts/dashboards inline in hosts that support MCP Apps (and fall back to a text summary elsewhere).

Tools

Thirteen tools — all read-only (readOnlyHint), each with a human-readable title, scoped/paginated output, and actionable errors. Every read is a point-read of a maintained ledger, so asking questions never runs up your database bill.

Every number is self-describing: values come back with a meta.semantics briefing and a coverage state, so a metric is reported as exactly what it is, and a blind spot (not_instrumented) is never mistaken for a real zero.

Portfolio

  • list_projects — list every app this connector can read (your portfolio).

  • get_portfolio — the coverage map: for each app, which surfaces are instrumented vs a blind spot. Load it first so a later blank reads as a known blind spot, not a fact.

  • use_project — set the current app for subsequent tools ("switch to ").

Revenue & cost

  • get_revenue — MRR, paying-customer count, per-rail split (Stripe/Apple/Google), optional daily trend.

  • get_customers — the customer census: the paying-customer count (plus total / active where instrumented). The canonical "how many customers does this app have" answer.

  • get_read_cost — database read-cost split into per-user reads vs un-attributed overhead, by operation.

The moat — error × identity × revenue

  • get_error_impact — for one error: how many distinct users hit it, and how many are paying (counts).

  • get_error_affected_users — the named paying users an error hit, each with monthly revenue and last-hit, sorted by revenue at risk. Returns your own identifiers only — never emails/names you didn't provide.

  • get_customer — one customer across every layer Crossdeck joins by identity: what they pay × active entitlements × read-cost.

Analytics

  • get_host_analytics — page views + unique visitors for a host/subdomain you own (optional daily series).

  • get_host_top_pages — top pages or referrers for a host you own.

Rendered UI (MCP Apps)

  • draw_user_growth — an interactive line chart of visitors + page views over time.

  • open_moat_dashboard — a customer's cross-layer dashboard (pay × entitlements × read-cost) rendered as cards.

Security

Prism is built on Crossdeck's bank-grade outbound-read spine. See SECURITY.md for the full model. In short:

  • OAuth 2.1 + PKCE (S256), dynamic client registration, short-lived (1h) workspace credentials with refresh-token rotation and reuse detection. No long-lived secret leaves your dashboard.

  • Read-only. Every tool is readOnlyHint: true — no writes, no config mutations.

  • Scoped & fail-closed. A token resolves to one owner and their own projects; a missing/invalid token returns an actionable 401, never silent data.

  • Your data only. Prism reads your own project's data, scoped by your token. It does not read your conversation history or local files, and returns your own identifiers — never PII you didn't provide.

Known limitations

  • Read-only in v1 — writes/config are a later, separately-gated stage.

  • Per-host analytics require the host to be a verified origin of your project.

  • Rendered charts require an MCP-Apps-capable host; others get a text summary.

  • Reporting reflects data from when Crossdeck was connected (historical backfill is separate).

Links

License

MIT © Crossdeck

Available Tools

11 tools
draw_user_growthDraw user growth over timeA
Read-only
Inspect

Render an interactive line chart of unique visitors and page views over time for a host you own, and return the period totals as text. Returns a rendered chart in MCP-Apps-capable hosts (a text summary elsewhere) plus the totals. Use when asked to chart, graph, draw, or visualize growth or traffic for a subdomain. The host must be a verified origin of the project, or the request is rejected.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days (1–90, default 30).
hostYesThe host to chart, e.g. 'wes.example.com'. Must be a verified origin of the selected app.
projectNoThe app to read (its project id, from list_projects). Required with a workspace key unless set via use_project.

TDQS

A4.7/5.0
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.

get_customerGet a customer's full pictureA
Read-only
Inspect

Cross-match one customer across every layer Crossdeck joins by identity. Returns what they pay (monthly cents), their active entitlement count, and their database read-cost — in one view. Identify the person by ANY ONE of the identifiers below; they all resolve to the same canonical customer. Use for 'how much does this user pay and what do they cost us?'. If no customer resolves, returns a no-match result, not an error.

ParametersJSON Schema
NameRequiredDescriptionDefault
userIdNoYour own user id for this person — the value you pass to identify() in the SDK (e.g. 'user_847').
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
customerIdNoA Crossdeck customer id ('cdcust_…').
anonymousIdNoA pre-login anonymous/device id captured before the user signed in.
stripeCustomerIdNoStripe customer id ('cus_…').
googlePurchaseTokenNoGoogle Play purchase token for the customer's purchase.
appleOriginalTransactionIdNoApple StoreKit originalTransactionId for the customer's purchase.

TDQS

A4.6/5.0
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.

get_error_affected_usersGet who an error hit and what they payA
Read-only
Inspect

For one error (by fingerprint), get the PAYING users it actually hit — the row-level moat answer: which paying customer broke, and how much are they worth. Returns a list sorted by revenue at risk (highest first), each row with your own user id, monthly revenue in cents, and when they last hit the error. Joins the error layer to identity and revenue. Returns only your own identifiers — never emails or names you didn't provide. Use when you need the actual customers, not just the counts from get_error_impact.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax users to return (1–100, default 25), highest revenue-at-risk first.
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
fingerprintYesThe error's fingerprint / issue id (e.g. 'a1b2c3').

TDQS

A4.7/5.0
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.

get_error_impactGet an error's impactA
Read-only
Inspect

For one error (by fingerprint/issue id), get its blast radius joined to identity. Returns distinct users affected, how many of those are PAYING customers, and the error's type, status, occurrence count, and first/last-seen timestamps — counts only. Use to size an error's impact. For the NAMED paying users behind the counts (and their revenue at risk), call get_error_affected_users instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
fingerprintYesThe error's fingerprint / issue id from the Crossdeck Errors view (e.g. 'a1b2c3').

TDQS

A4.5/5.0
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.

get_host_analyticsGet analytics for a hostA
Read-only
Inspect

Get headless web analytics for one host/subdomain the app owns (e.g. a tenant's subdomain). Returns page views and unique visitors with totals; granularity='day' adds a daily series. The host MUST be a verified origin of the project, or the request is rejected (403). Use for per-tenant or per-subdomain traffic questions.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days (1–90, default 30).
hostYesThe host to read, e.g. 'wes.example.com'. Must be a verified origin of the selected app.
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
granularityNo'total' (default) for totals only, or 'day' for a daily series.

TDQS

A4.2/5.0
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.

get_host_top_pagesGet top pages or referrers for a hostA
Read-only
Inspect

Get the top pages or top referrers for one host the app owns, ranked and paginated. Returns rows of { key, views } highest-first, where key is a page path (default) or a referrer. Set dimension='top_referrers' for traffic sources. The host must belong to the selected app. Use for 'most-viewed pages on this subdomain' or 'where its traffic comes from'.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days (1–90, default 30).
hostYesThe host to read, e.g. 'wes.example.com'. Must belong to the selected app.
limitNoMax rows to return (1–100, default 25), highest-first.
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
dimensionNoWhat to rank: 'top_pages' (default) or 'top_referrers'.

TDQS

A4.5/5.0
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.

get_read_costGet database read-costA
Read-only
Inspect

Get an app's database read-cost over the last days days, split into per-user reads vs un-attributed overhead, plus a breakdown by operation. Per-user attribution works because Crossdeck joins read-cost to the SDK's identity, so you can see which operations drive the bill. Returns the per-user-vs-overhead totals and the by-operation breakdown. Use for 'what's driving our database reads' or 'which operation costs the most'.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days (1–90, default 30).
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.

TDQS

A4.1/5.0
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.

get_revenueGet revenueA
Read-only
Inspect

Get an app's recurring revenue from its maintained revenue ledger (a point-read, never a scan). Returns MRR in cents, the paying-customer count, and the per-rail split across Stripe, Apple, and Google; with granularity='day' it adds a daily time series over the window. Use for 'what's our MRR', 'how many paying customers', or revenue-trend questions. An app with no revenue yet returns zeros, not an error.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNoOnly with granularity='day': the trend window in days (1–366, default 90).
projectNoThe app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored.
granularityNoHow to aggregate: 'total' (default) = the latest snapshot; 'day' = a daily time series across the window.

TDQS

A4.4/5.0
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.

list_projectsList your appsA
Read-only
Inspect

List every app (project) in your Crossdeck portfolio that this connector can read — the same set your Pulse dashboard shows. Returns an array of { id, name } per app. Call this FIRST when a workspace key (cd_wk_) is connected, then pass an id to other tools or set a default with use_project. With a single-app key it returns just that one app. Read-only; takes no arguments.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
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.

open_moat_dashboardOpen the cross-layer dashboardA
Read-only
Inspect

Render a customer's cross-layer dashboard — what they pay (monthly), their active entitlements, and their database read-cost, joined by identity — and return the same as a text summary. Returns a rendered dashboard in MCP-Apps-capable hosts (a text summary elsewhere). Identify the customer by ANY ONE of the identifiers below; they all resolve to the same canonical customer. Use when asked to show, open, or visualize a customer's full picture. Returns a no-match result if no customer resolves.

ParametersJSON Schema
NameRequiredDescriptionDefault
userIdNoYour own user id for this person — the value you pass to identify() (e.g. 'user_847').
projectNoThe app to read (its project id, from list_projects). Required with a workspace key unless set via use_project.
customerIdNoA Crossdeck customer id ('cdcust_…').
anonymousIdNoA pre-login anonymous/device id captured before sign-in.
stripeCustomerIdNoStripe customer id ('cus_…').
googlePurchaseTokenNoGoogle Play purchase token for the purchase.
appleOriginalTransactionIdNoApple StoreKit originalTransactionId for the purchase.

TDQS

A4.4/5.0
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.

use_projectSelect the current appA
Read-only
Inspect

Set the current app for this conversation so later tools default to it without repeating project. Behaves as session state: it persists until you call this again and applies to every subsequent tool call. Returns { currentProject } — the project id now in effect. Use when the user says 'switch to ' or names an app to focus on; call list_projects first for valid ids. No effect with a single-app key (the project is fixed).

ParametersJSON Schema
NameRequiredDescriptionDefault
projectYesThe project id to make current, copied from list_projects (e.g. 'proj_3a8f137bccdd4f').

TDQS

A4/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 10 tool updatesv0.3.2
    • Changeddraw_user_growth2 fields changed
      • changedInput schema / properties / days / description
        Previous value: -"Window in days (default 30)."New value: +"Look-back window in days (1–90, default 30)."
      • changedInput schema / properties / host / description
        Previous value: -"The host, e.g. 'wes.example.com'."New value: +"The host to chart, e.g. 'wes.example.com'. Must be a verified origin of the selected app."
    • Changedget_customer7 fields changed
      • changedInput schema / properties / anonymousId / description
        Previous value: -"A pre-login anonymous/device id."New value: +"A pre-login anonymous/device id captured before the user signed in."
      • changedInput schema / properties / appleOriginalTransactionId / description
        Previous value: -"Apple StoreKit originalTransactionId."New value: +"Apple StoreKit originalTransactionId for the customer's purchase."
      • changedInput schema / properties / customerId / description
        Previous value: -"A Crossdeck customer id (cdcust_…)."New value: +"A Crossdeck customer id ('cdcust_…')."
      • changedInput schema / properties / googlePurchaseToken / description
        Previous value: -"Google Play purchase token."New value: +"Google Play purchase token for the customer's purchase."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
      • changedInput schema / properties / stripeCustomerId / description
        Previous value: -"Stripe customer id (cus_…)."New value: +"Stripe customer id ('cus_…')."
      • changedInput schema / properties / userId / description
        Previous value: -"Your own user id for this person (what you pass to identify())."New value: +"Your own user id for this person — the value you pass to identify() in the SDK (e.g. 'user_847')."
    • Changedget_error_affected_users3 fields changed
      • changedInput schema / properties / fingerprint / description
        Previous value: -"The error's fingerprint / issue id."New value: +"The error's fingerprint / issue id (e.g. 'a1b2c3')."
      • changedInput schema / properties / limit / description
        Previous value: -"Max users to return (default 25)."New value: +"Max users to return (1–100, default 25), highest revenue-at-risk first."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedget_error_impact2 fields changed
      • changedInput schema / properties / fingerprint / description
        Previous value: -"The error's fingerprint / issue id from the Crossdeck Errors view."New value: +"The error's fingerprint / issue id from the Crossdeck Errors view (e.g. 'a1b2c3')."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedget_host_analytics4 fields changed
      • changedInput schema / properties / days / description
        Previous value: -"Window in days (default 30)."New value: +"Look-back window in days (1–90, default 30)."
      • changedInput schema / properties / granularity / description
        Previous value: -"'total' (default) or 'day' for a daily series."New value: +"'total' (default) for totals only, or 'day' for a daily series."
      • changedInput schema / properties / host / description
        Previous value: -"The host, e.g. 'wes.example.com'. Must belong to the selected app."New value: +"The host to read, e.g. 'wes.example.com'. Must be a verified origin of the selected app."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedget_host_top_pages5 fields changed
      • changedInput schema / properties / days / description
        Previous value: -"Window in days (default 30)."New value: +"Look-back window in days (1–90, default 30)."
      • changedInput schema / properties / dimension / description
        Previous value: -"'top_pages' (default) or 'top_referrers'."New value: +"What to rank: 'top_pages' (default) or 'top_referrers'."
      • changedInput schema / properties / host / description
        Previous value: -"The host, e.g. 'wes.example.com'. Must belong to the selected app."New value: +"The host to read, e.g. 'wes.example.com'. Must belong to the selected app."
      • changedInput schema / properties / limit / description
        Previous value: -"Max rows (default 25)."New value: +"Max rows to return (1–100, default 25), highest-first."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedget_read_cost2 fields changed
      • changedInput schema / properties / days / description
        Previous value: -"Window in days (default 30)."New value: +"Look-back window in days (1–90, default 30)."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedget_revenue3 fields changed
      • changedInput schema / properties / days / description
        Previous value: -"With granularity='day', the trend window (default 90)."New value: +"Only with granularity='day': the trend window in days (1–366, default 90)."
      • changedInput schema / properties / granularity / description
        Previous value: -"'total' (default) for the latest snapshot, or 'day' for a daily series."New value: +"How to aggregate: 'total' (default) = the latest snapshot; 'day' = a daily time series across the window."
      • changedInput schema / properties / project / description
        Previous value: -"The app to read (its project id, from list_projects). With a workspace key this is required unless you've set one via use_project; with a single-app key it's ignored."New value: +"The app to read, as a project id from list_projects (e.g. 'proj_3a8f137bccdd4f'). With a workspace key (cd_wk_) this is required unless you've set a default via use_project; with a single-app key it is ignored."
    • Changedopen_moat_dashboard6 fields changed
      • addedInput schema / properties / anonymousId / description
        Added value: +"A pre-login anonymous/device id captured before sign-in."
      • addedInput schema / properties / appleOriginalTransactionId / description
        Added value: +"Apple StoreKit originalTransactionId for the purchase."
      • addedInput schema / properties / customerId / description
        Added value: +"A Crossdeck customer id ('cdcust_…')."
      • addedInput schema / properties / googlePurchaseToken / description
        Added value: +"Google Play purchase token for the purchase."
      • addedInput schema / properties / stripeCustomerId / description
        Added value: +"Stripe customer id ('cus_…')."
      • addedInput schema / properties / userId / description
        Added value: +"Your own user id for this person — the value you pass to identify() (e.g. 'user_847')."
    • Changeduse_project1 field changed
      • changedInput schema / properties / project / description
        Previous value: -"The project id to make current (from list_projects)."New value: +"The project id to make current, copied from list_projects (e.g. 'proj_3a8f137bccdd4f')."
  2. 11 tool updatesv0.3.1
    • First observeddraw_user_growth
    • First observedget_customer
    • First observedget_error_affected_users
    • First observedget_error_impact
    • First observedget_host_analytics
    • First observedget_host_top_pages
    • First observedget_read_cost
    • First observedget_revenue
    • First observedlist_projects
    • First observedopen_moat_dashboard
    • First observeduse_project
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
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.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Analytics MCP

    Ninoambaraa
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI-powered analytics from Stripe, PayPal, and Google Analytics 4 (BigQuery) data sources with built-in guardrails and automated workflows for financial and web performance insights.
    -

  • SLayer

    MotleyAI
    A
    license
    A
    quality
    A
    maintenance
    Agent-native semantic layer, letting AI agents query databases through specifying intent instead of writing SQL, then compiling structured queries into correct, dialect-aware SQL. Dynamic and expressive, supporting multi-stage queries, time-shifts, and complex join schemas.
    21
    167
    MIT

  • ai-analyst

    sbdk-dev
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables natural language data queries with statistical rigor and a semantic layer, supporting 23+ analytical tools for product analytics.
    1
    MIT

  • TalkDB

    Nitin-Gupta1109
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables natural language querying of databases with multi-turn conversations, auto-generated charts, and proactive monitoring via scheduled queries and alerts.
    1
    MIT

Latest Blog Posts

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