Skip to main content
Glama

Data Nola

by io.github.pipeworx-io

Ask Pipeworx — Grounded

ask_pipeworx_grounded
Read-onlyIdempotent

Hallucination-resistant answer mode for high-stakes reads. Same routing as ask_pipeworx — picks the right tool from 5,738 across 1499 sources, fills arguments, fetches the data — then EXTRACTS the answer using ONLY what the tool result contains. Returns {answer, evidence (verbatim quote), confidence, source, fetched_at, refusal_reason:null} on success, OR an explicit refusal {answer:null, refusal_reason:"not_in_source"|"no_tool_match"|"tool_error"|"data_truncated"|"llm_error"} when the data doesn't directly answer. Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements). Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoAlias for question.
textNoAlias for question.
inputNoAlias for question.
queryNoAlias for question.
promptNoAlias for question.
questionYesYour question in natural language. Accepts query, q, prompt, text, input as aliases.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this read-only, idempotent, and non-destructive, so the description adds substantial behavioral detail: explicit refusal shapes, refusal_reason enum values, evidence extraction from verbatim quotes, and the success response object with fetched_at and source. It clearly communicates when the tool will refuse rather than guess, which is central to its behavior.

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?

The description is dense but every sentence earns its place: it defines the mode, explains routing and extraction behavior, specifies the response/refusal contract, gives concrete use cases, and closes with a cost-based routing tip. The most important qualifier, 'Hallucination-resistant,' is front-loaded.

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 fully compensates by enumerating both success and refusal response shapes, including refusal_reason values and evidence/verbatim quote semantics. Combined with the usage and cost guidance, an agent has everything needed to invoke this tool correctly and interpret its 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% and the only semantic parameter is 'question,' which is already documented as a natural-language query with five aliases. The description adds little parameter-specific detail, but none is really needed given the high schema coverage and single meaningful parameter.

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?

The description opens with a clear, specific purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It explains that the tool routes like ask_pipeworx but extracts the answer only from tool results, which distinguishes it from the sibling ask_pipeworx without ambiguity.

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?

Usage guidance is explicit: use when answers will be quoted, cited, or acted on and must not invent facts, with examples like financial verdicts and legal claims. It also names the alternative for casual lookups: 'prefer ask_pipeworx for casual lookups,' and discloses the cost tradeoff of one extra LLM call.

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

All Data Nola toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation2/5

Several tool boundaries blur: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research all serve overlapping query/research entry points, and ask_pipeworx_beta is currently identical to ask_pipeworx by the server's own description. entity_profile, recent_changes, and compare_entities also cover overlapping company-investigation territory, forcing agents to parse long descriptions to avoid mis-selection.

Naming Consistency4/5

Names are uniformly snake_case and mostly follow a predictable verb-object or domain-prefix pattern (ask_pipeworx_*, polymarket_*, nola_*, subscribe/unsubscribe). Minor deviations like nola_datasets, polymarket_edges, and ai_visibility_check are noun-first rather than verb-first, but the overall convention is still readable and coherent.

Tool Count2/5

34 tools is well above the 15-25 heavy range and includes multiple near-duplicate query modes, four closely related Polymarket analysis tools, and memory/subscription utilities layered on top of the core data-access surface. While the server appears to be a broad data platform, the count is bloated for an agent to navigate efficiently.

Completeness4/5

The tool surface is remarkably broad: discovery, single-answer lookup, grounded verification, deep research, entity resolution, entity profiles, comparisons, claim validation, NOLA querying, prediction-market analytics, memory, subscriptions, and feedback are all covered with few obvious dead ends. The main gap is that the NOLA-specific surface is thin relative to the server name, though nola_query plus nola_datasets provides a flexible escape hatch.

Resources