Skip to main content
Glama

Vaeo AI Discovery Reports

One part of the report

ask_about_report
Read-only

One part of a finished report, from the saved results (no new AI questions, no cost). Topics: short_answer, who_the_ais_named (who is named more), each_ai, each_question, pages_the_ais_read (which sites to get on), website, start_here (what to do first).

Input Schema

NameRequiredDescriptionDefault
topicYes
order_keyYesThe order_key that order_report gave.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that - it is a cached, zero-cost read that does not trigger new AI work - but says nothing about return shape, size, or failure modes for a missing/expired order_key.

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?

Two sentences, front-loaded with the core purpose before the topic enumeration. The dense parenthetical topic list earns its space by defining enum values, though it is slightly cluttered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only retrieval tool with annotations carrying the safety profile, the main gap is the absence of any output schema or description of what a returned section looks like, plus no mention of error behavior when the order_key is invalid. Adequate but not complete.

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?

The topic enum is undocumented in the schema, but the description compensates by glossing every value (e.g., 'who_the_ais_named (who is named more)', 'pages_the_ais_read (which sites to get on)', 'start_here (what to do first)'). The order_key relies on the schema's own description ('the order_key that order_report gave'), so coverage is adequate overall.

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 makes clear this retrieves a single section of an already-finished report from saved results, and explicitly negates the misleading verb in its own name ('no new AI questions'). It implicitly distinguishes from get_report (full report) and order_report, though it never names those siblings directly.

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

Usage Guidelines3/5

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

The phrase 'from the saved results (no new AI questions, no cost)' signals the context for choosing this over a live-query tool, and the topic list implies what each call returns. However, it never states when to prefer this over get_report or how it relates to the other report tools, leaving routing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources