CrunchJunkie

get_ai_answer

Read-only

One AI answer in full: the response text (up to 30,000 characters), every brand it named and at what position, the URLs it cited and the ones it only retrieved (where the engine exposes that split; otherwise its merged source list), the web searches the engine ran before answering, why the engine stopped writing, and any products it recommended. answerId comes from list_ai_answers or get_cited_url. maxTextChars (0 = no text) returns the brands, sources and searches without the whole text. Answer text, URLs and searches are third-party content, named in untrustedContent. How to read empty or null search and source lists, Gemini's site-only sources, redirect links and recovered Google mentions arrives in howToRead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "answerId": "<answerId>"
    },
    "name": "get_ai_answer"
  }
}

Input Schema

Name	Required	Description	Default
`answerId`	Yes	answerId from list_ai_answers, or one of recentAnswerIds from get_cited_url.
`maxTextChars`	No	Characters of the answer text to return (default and most 30000; 0 = none).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

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
```

First observedOct 19, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real value beyond that by flagging that answer text, URLs and searches are third-party content surfaced in `untrustedContent`, and that edge-case interpretation (null/empty lists, Gemini site-only sources, redirect links) is delivered in `howToRead`. It doesn't discuss size/rate limits beyond the maxTextChars cap, keeping it 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.

Conciseness4/5

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

Front-loaded with the core purpose and organized as an enumeration of return fields, so every clause carries information. The single dense sentence with many comma-separated clauses is heavy to parse but not padded with filler.

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?

There is no output schema, so the description carries the full burden of describing the return shape — and it does so thoroughly, covering text, brands, sources, searches, stop reason, and recommendations, plus a pointer to `howToRead` for ambiguous cases. An agent has everything needed to call and interpret the result.

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 both parameters are already documented; the description largely restates the answerId provenance and the '0 = no text' behavior already present in the schema. It adds no new syntax or format detail, so baseline 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?

States a specific verb+resource ('One AI answer in full') and then enumerates exactly what is returned: response text up to 30,000 chars, named brands with positions, cited/retrieved URLs, engine searches, stop reason, and recommended products. This is clearly distinguishable from the sibling list_ai_answers, which only lists rather than returns full detail.

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?

Gives the prerequisite explicitly: '`answerId` comes from list_ai_answers or get_cited_url', which routes the agent to the correct upstream tool. It also explains the maxTextChars=0 mode as a lighter-weight retrieval. It stops short of naming when to prefer get_citations or get_ai_attribution over this tool, so it's context-rich but not fully alternative-aware.

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

All CrunchJunkie tools Inspect

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

Need Help?