Skip to main content
Glama

Exa grounded answer

exa_answer

Ask a question to receive a short, cited answer from web search for quick facts and verification, avoiding the need to read full sources.

Instructions

Ask a question; Exa searches and writes a short cited answer itself ($0.005). Good for quick facts. For research where you read the sources yourself, use exa_search.

Input Schema

NameRequiredDescriptionDefault
rawNoAlso return the full Exa JSON in structuredContent. Costs many tokens.
textNoInclude full source text in citations (large).
queryYes
noCacheNoSkip the local cache.
maxCharsNoCap on the text returned to you (default 8000).
outputSchemaNoJSON Schema for a structured answer.
systemPromptNo
userLocationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits: the answer is model-synthesized with citations, and each call costs $0.005. However, it says nothing about the local cache that the noCache parameter implies, about latency/rate limits, or about how maxChars truncation affects the returned answer.

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 short sentences, zero waste, with the core behavior and the routing alternative both front-loaded. The parenthetical price is the only aside and it earns its place.

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?

For an 8-param tool with a nested outputSchema object and no annotations, the description covers what the tool does and when to pick it, which is the main risk of misselection. It is thin on the behavioral envelope — caching, output size, and the customization parameters — but not inadequate for correct invocation of the required query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Eight parameters at 63% schema description coverage, and the description mentions none of them. systemPrompt and userLocation are undocumented in both schema and description, and the cost/size tradeoffs of raw, text, and maxChars — the most decision-relevant knobs here — are left entirely to 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?

States a specific verb and resource chain ('Ask a question; Exa searches and writes a short cited answer itself') and distinguishes the result shape from raw-source retrieval by naming exa_search. An agent knows immediately this returns a synthesized, cited answer rather than documents.

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 gives the selection rule: 'Good for quick facts' here, and 'For research where you read the sources yourself, use exa_search' as the alternative with the condition that selects it. Cost is also disclosed, which is decision-relevant for an agent choosing between tools.

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