Skip to main content
Glama

CrunchJunkie

by io.crunchjunkie.app
OverviewDiscussionsAdmin

get_cited_url

Read-only

Drill into one page the AI engines use as a source: how many of a project's answers cited it and how many retrieved it during search, its share of chats (answersUsingUrl ÷ answersInWindow), which tracked prompts and engines those answers came from, when it was first and last seen, how often the brand and which tracked competitors were named in the same answers, and the ids of the most recent answers (open with get_ai_answer). Also the page title (Peec AI data), page type, domain category, and a lifetime block with the page's citation status, its citation rate before and now, weekly series, per-engine split and evidenced causes. Page URLs come from get_citations or list_citation_lifetimes. The URL matching, Peec AI chat, Gemini site-only and lifetime-frame rules arrive in howToRead.

Input Schema

NameRequiredDescriptionDefault
urlYesThe page URL, with or without https://.
daysNoWindow in days (default 30, max 180).
modelNoFilter to one engine, by its id (e.g. gpt-4o-search-preview), counted as the app's URLs tab counts it: our scans of that engine and its Peec AI chats, then the source lens. Every count follows it; the lifetime block stays across every engine whatever this is (its byEngine splits it). Our Gemini scans name sites, never pages: when every answer of the engine is one of them there are no page counts (emptyReason sites_only).
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

A4.3/5.0
Behavior5/5

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

Annotations already establish a safe read-only operation, but the description adds substantial behavior: data-source blending rules, lifetime block behavior across engines, Gemini site-only caveats, emptyReason=sites_only, and howToRead rules. These are real behavioral disclosures beyond structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and most content is relevant given there is no output schema. However, the first sentence is an extremely dense run-on that packs metrics, sources, and caveats together, making it harder to scan than necessary.

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?

With no output schema and a complex analytical return shape, the description does the necessary work: it explains the returned metrics, lifetime block, data-source semantics, answer ID usage, and edge cases like Gemini site-only scans. An agent has enough context to invoke and interpret the tool correctly.

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 all six parameters are already documented thoroughly, including model, source enum, and clientId/projectId. The description adds only the URL-source hint and howToRead note, not additional parameter-level meaning beyond 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 states a specific verb and resource: drill into one cited page and return citation/retrieval metrics, prompt/engine sources, first/last seen, competitor mentions, and recent answer IDs. It also distinguishes itself from get_citations/list_citation_lifetimes (URL sources) and get_ai_answer (opening answer IDs), so an agent can tell what this tool is for without opening the schema.

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

Usage Guidelines4/5

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

It clearly says page URLs come from get_citations or list_citation_lifetimes and that recent answers should be opened with get_ai_answer, giving explicit prerequisite and follow-up routing. It does not state explicit when-not-to-use conditions, but the usage context is clear.

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