Skip to main content
Glama
thyn-ai

Algenta MCP

Official
by thyn-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

query_data

Read-onlyIdempotent

Run governed metric queries on any dataset with natural-language intent, filters, aggregation, and grouping. Resolves columns statistically and returns confidence, decision path, and plan.

Instructions

Execute a structured query against connected data sources. Convert the user's question to a structured intent and call this tool — do NOT try to write SQL or parse column names yourself. The engine resolves column meaning from mathematical relationships and statistical structure only. It works on any dataset without configuration. The governed filter shape is a record-predicate contract over normalized rows, not a SQL predicate language, so it also applies to Redis and other non-SQL sources.

Structural roles (use in metric.role):

  • derived_measure: the main financial/operational aggregate (revenue, spend, value)

  • base_measure: counts, quantities, discrete amounts

  • unit_measure: per-unit prices, rates

  • ratio: percentages, margins, fill rates (0-1 range)

  • metric: let the engine pick the best numeric column

If clarification_required is true, or if confidence < 0.85, check the candidates list and ask the user to clarify. Never fabricate column names or SQL. Read-only against the engine; executes under the active API key with no separate per-route rate limit. Returns the query envelope: result, result_type, row_count, confidence, resolved_column, decision_path, and plan, with candidates and clarification_required set when the engine cannot resolve deterministically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoTop-N limit. Use for 'top 5 customers' type questions.
orderNodesc
filterNo
metricNoWhat to measure.
sourcesNoData sources to query. Usually omitted when dataset_id is provided.
group_byNoDimension words from the user's question (e.g. ['customer', 'region']). The engine finds the best matching column.
dataset_idNoPreferred path. dataset_id returned by connect_data or list_data.
aggregationNoHow to aggregate the metric column.sum

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses that it executes under the active API key with no separate rate limit, never fabricates columns/SQL, and returns a specific envelope including candidates and clarification_required. This adds meaningful behavioral context beyond what annotations provide.

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?

The description is long but well-structured, front-loading purpose and usage, then roles, then return behavior. Every section earns its place given the tool's complexity, though the prose could be tightened slightly.

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-parameter tool with nested objects and no output schema, the description covers the clarification workflow, return envelope fields, and safety/auth behavior. It does not explain the semantics of each envelope field, but the high-level list plus schema descriptions are sufficient for an agent to invoke it correctly.

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 75% schema coverage, the baseline is 3, but the description compensates by defining the structural roles for metric.role (derived_measure, base_measure, unit_measure, ratio, metric) and explaining that filter is a record-predicate contract rather than SQL. This adds real semantics beyond the schema's enum labels.

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 states a specific verb and resource: 'Execute a structured query against connected data sources.' It goes further to differentiate itself by explicitly saying it is not SQL and works on any dataset without configuration, which helps an agent distinguish it from query_sql_report and similar siblings.

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

Usage Guidelines4/5

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

It gives explicit usage direction: 'Convert the user's question to a structured intent and call this tool — do NOT try to write SQL or parse column names yourself.' It also notes non-SQL applicability, which implies an alternative for SQL, though it never names a specific sibling like query_sql_report.

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

Deploy Server

Other Tools