Skip to main content
Glama

Rank rows by a numeric column

dataset_top

The highest (or lowest) rows of the EntitySearch HQ dataset by a numeric column: "which is the most/least X".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "column": "<column>"
    },
    "name": "dataset_top"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
columnYes
ascendingNotrue for the lowest first; default highest first

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations at all, the description carries the full burden and does not meet it: it says nothing about permission needs, ordering/tie-breaking, behavior when the column contains non-numeric or missing values, or what a returned row contains. The only behavioral hint is that the dataset is a fixed one ('EntitySearch HQ dataset').

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?

A single compact sentence with the core operation front-loaded. The trailing quoted example is slightly informal but earns its place by giving a natural-language use case; there is no filler.

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

Completeness2/5

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

No output schema and no annotations, so the description is the only place an agent can learn about return shape, the default limit, and edge-case behavior for non-numeric columns — and it covers none of these. For a three-parameter ranking tool this leaves material gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only ascending is documented), so the description needs to compensate. It adds that column must be numeric — useful, though it conflicts with the schema's plain string type — and restates the high/low semantics already covered by the schema, while leaving limit (range 1-50, no stated default) entirely unexplained.

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 names a specific operation (return the highest or lowest rows) and the resource (EntitySearch HQ dataset ranked by a numeric column), which is enough to tell it apart from dataset_row or dataset_search. It stops short of naming any sibling explicitly, so the differentiation is inferred rather than stated.

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 quoted 'which is the most/least X' framing gives an implied usage scenario, but there is no explicit when-to-use vs. when-to-use-another-tool guidance and no exclusions. An agent must infer that this is the ranking tool rather than a filter/search tool.

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