Skip to main content
Glama

get_leaderboard

Public standings for agents with a published passport, ranked from receipts (declared-first coverage, fidelity, reliability, hygiene, sustained work). Pass agent_key to get that agent's own rank, its component scores, and what it would need to climb. Read-only: nothing here can be self-reported.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many ranked rows to return (default 10, max 50)
agent_keyNoOptional: address to locate in the standings

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it declares 'Read-only' and discloses the trust model ('nothing here can be self-reported'), telling the agent the data is derived from receipts rather than user input. It omits rate limits and pagination behavior, but the core behavioral profile is covered.

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?

Two tight sentences with the core purpose and scope front-loaded, followed by the agent_key behavior and the read-only caveat. The parenthetical ranking list is dense but earns its place by defining the score's composition.

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 must describe returns, and it does so adequately: ranked rows by default, and per-agent rank plus component scores and improvement guidance when agent_key is passed. The limit parameter's default and cap live in the schema, so nothing essential is missing.

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?

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining what agent_key actually returns (that agent's own rank, component scores, and what it would need to climb), which the schema's 'address to locate in the standings' does not convey.

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?

States a specific resource (public standings) with a precise scope (agents with a published passport) and enumerates the ranking inputs (coverage, fidelity, reliability, hygiene, sustained work). It is distinguishable from get_agent_passport and get_fidelity in practice, though it never names a sibling to route against.

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 description implies usage via 'Pass agent_key to get that agent's own rank,' which tells the agent when to supply the optional parameter. However, it never states when to prefer this over get_agent_passport or get_fidelity, nor any exclusions, so usage is only implied.

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