Skip to main content
Glama

Ask Verse anything

ask_void
Read-only

Ask Verse a question in plain words and get its answer: a short, direct answer from Verse's answer engine (a-to-mind.com), citing the Wikipedia pages it drew on when they match. Ask about Verse itself ("what are you building?") and it answers from its own live facts. Up to 12 model answers a minute per caller; a repeated question may come from the 7-day cache.

Input Schema

NameRequiredDescriptionDefault
askYesThe question, in plain words (3 to 600 characters).
response_typeNoWhat to get back: 'text' (default) or 'raw_data' (the structured result as JSON). 'image' is not offered yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / response_type
      Added value: +{
      +  "description": "What to get back: 'text' (default) or 'raw_data' (the structured result as JSON). 'image' is not offered yet.",
      +  "enum": [
      +    "text",
      +    "raw_data",
      +    "image"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real context on top: a 12-answers-per-minute-per-caller rate limit, a 7-day cache for repeated questions (which explains the idempotentHint=false), and the fact that citations appear only when Wikipedia matches. Auth/identity requirements are not addressed, 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 purpose, then behavior, then limits and caching; every sentence carries information. Slightly dense in the final sentence where the rate limit and cache are combined, but nothing is wasted.

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?

With no output schema, the description correctly covers the return shape (short answer plus conditional citations) and the operational constraints. The only material gap is authentication/identity expectations and what the raw_data response contains, but annotations already signal a safe read-only call.

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% and both parameters are documented in the schema, so the schema does the heavy lifting. The description restates 'plain words' and the text default but adds no syntax, length, or format detail beyond what the schema already gives. 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?

Names a specific verb (ask) and resource (Verse's answer engine at a-to-mind.com), and describes what comes back: a short direct answer with Wikipedia citations. None of the sibling tools (drive_time, moon_phase, skill_*) are similar, so there is no ambiguity to resolve and the scope is unambiguous.

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?

Usage is implied rather than stated: the agent can infer it is for plain-word factual questions and for questions about Verse itself, which is a genuinely useful hint. But there is no explicit when-to-use vs when-not, no guidance on alternatives, and the 'image' option is only mentioned in the schema, not routed around in the description.

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.