Skip to main content
Glama

ask

Read-only

Ask the map one question in plain language and get an answer written from what your key may see — objects, their fields, the relations and join keys between them, the findings, processes and metrics, with the recorded values of the metrics your human tracks — with citations to the exact map elements it rests on and an honest statement of what the map could not establish. Reach for it when a question spans several parts of the map or you do not yet know which tool holds the answer: "which systems hold customer data, and which joins between them can I trust?", "is the order-to-invoice flow reliable, and what is known to be wrong with it?", "what should I check before I quote revenue per customer?". It answers from metadata only: it never reads rows, never runs anything in your human's systems, and never invents an element the map does not hold — when the map cannot answer it says so instead of guessing. Every citation is an id you can pass on (fetch, get_object, route); a cited relation or route also carries each hop's measured verified_rate from the map, and unmeasured_joins names the joins the map never measured. For one known thing the direct tool is faster and does not count against the allowance: get_object for an object, route for the join path between two, get_metric for a formula, list_findings for the discrepancies, search for a term. It also answers a question about Maplith itself — connecting, keys, signals and rules — from Maplith's public documentation, citing pages as doc:. Each call is metered against the workspace's daily allowance and limited per key; keep questions specific, under 1,000 characters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYesOne question in plain language, e.g. "Which systems hold customer data, and how are they joined?"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/no-destruction/no-open-world, but the description adds substantial context beyond them: metadata-only semantics (never reads rows, never runs anything, never invents elements), abstention behavior when the map cannot answer, what citations contain, and per-key/daily metering limits.

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-loads purpose then alternatives then constraints, with no filler sentences. It is on the long side — three full example questions and two separate citation/limit passages — but each block carries distinct decision-relevant information.

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?

No output schema exists, so the description carries the return contract itself and does so thoroughly: answer form, citation ids usable in other tools, verified_rate per hop, unmeasured_joins, and declared ignorance. Metering and abstention behavior close the remaining gaps for a Q&A tool.

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?

With a single parameter at 100% schema coverage the baseline is 3; the description adds real meaning by advising questions be kept specific and noting the 1,000-character bound, plus the useful fact that the question may target Maplith's own docs. The character limit merely restates schema maxLength, so it isn't a full 5.

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 (ask the map a plain-language question) and precisely what comes back: an answer with citations, measured verified_rate, and an explicit statement of gaps. It actively distinguishes itself from siblings by naming the direct tools (get_object, route, get_metric, list_findings, search) for single known things.

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?

Explicit when-to-use trigger: questions spanning several parts of the map or when the right tool is unknown, reinforced with three concrete example questions and a second documented use case (questions about Maplith itself). It also gives clear when-NOT-to-use guidance by routing single known lookups to the cheaper direct tools.

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