Skip to main content
Glama

CrunchJunkie

by io.crunchjunkie.app
OverviewDiscussionsAdmin

get_ai_attribution

Read-only

A project's AI visibility next to the visits and conversions AI assistants send to the client's website, from the client's connected GA4 property: per-day visibility beside AI-referred sessions, conversions and revenue, window totals, the AI-referred conversion rate against the site-wide rate (with a ± margin), and the correlation between visibility and the chosen metric over the days that have both (from 20 such days, with a 95 % interval). availability states when GA4 is not connected, not readable or not scanned, and those figures are then null. The GA4 caveats (undercounting, tracking changes, correlation) arrive in howToRead.

Input Schema

NameRequiredDescriptionDefault
daysNoWindow in days ending today (default 90, max 365).
metricNoWhat to correlate visibility with (default conversions).
sourceNoData source: "blended" (default — CrunchJunkie scans plus imported Peec data, an engine both track counted once with the CrunchJunkie scan winning), "native" (CrunchJunkie scans only) or "peec" (imported Peec data only).
clientIdNoClient id — uses the AI-Visibility project its Overview opens in the app (the newest).
projectIdNoAI-Visibility project id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changed
    • changedInput schema / properties / source / description
      Previous value: -"Data source: \"blended\" (default — your scans plus imported Peec data, an engine both track counted once with your scan winning), \"native\" (your scans only) or \"peec\" (imported Peec data only)."New value: +"Data source: \"blended\" (default — CrunchJunkie scans plus imported Peec data, an engine both track counted once with the CrunchJunkie scan winning), \"native\" (CrunchJunkie scans only) or \"peec\" (imported Peec data only)."
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false. The description adds useful behavior beyond that: availability states for missing/unreadable/unscanned GA4, null figures in those cases, the 20-day minimum and 95% interval for correlation, and caveats delivered via howToRead.

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 front-loaded and every sentence contributes necessary output or caveat information. The first sentence is very long and clause-heavy, which makes it harder to parse, but it avoids repetition and stays appropriately sized for a tool with no output schema.

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?

Because there is no output schema, the description must explain return values, and it does so thoroughly: per-day visibility, sessions, conversions, revenue, window totals, conversion-rate comparison with margin, correlation with sample threshold and confidence interval, availability, and howToRead caveats. Nothing essential for interpreting the read-only analytics response is missing.

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%, including defaults for days, metric and source, plus enum meanings. The description only mentions the 'chosen metric' and the days window in passing, adding no parameter guidance beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource: AI visibility alongside AI-referred GA4 sessions, conversions and revenue, with conversion-rate and correlation outputs. It does not explicitly contrast with siblings like get_ai_visibility_metrics or get_visibility_trend, but the GA4 attribution focus gives it a clear identity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The GA4 context implies the tool's purpose, but an agent still has to infer when to choose it over sibling analytics tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CrunchJunkie toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources