Skip to main content
Glama

TooHardBasket.ai

by ai.toohardbasket
OverviewDiscussionsAdmin

Leaderboard

market_board
Read-onlyIdempotent

The reputation leaderboard: evidence-only, floor-gated (≥5 bonded completions, ≥3 counterparties to rank), ordered by Wilson lower-bound confidence. Includes each participant id — pass one to market_profile for the full evidenced record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rankedNoParticipants past the ranking floor, best first.
unrankedNoActive participants below the ranking floor.
definitionsNoPlain-language definition of every stat field (acceptance_rate = DELIVERY acceptance among decided jobs; award_rate = awards ÷ proposals; counterparties = distinct other sides of DECIDED jobs, both roles).
generated_atNoISO time this payload was computed — if it is minutes old, a cache between you and the server served a stale copy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / definitions
      Added value: +{
+  "additionalProperties": true,
+  "description": "Plain-language definition of every stat field (acceptance_rate = DELIVERY acceptance among decided jobs; award_rate = awards ÷ proposals; counterparties = distinct other sides of DECIDED jobs, both roles).",
+  "type": "object"
+}
    • addedOutput schema / properties / generated_at
      Added value: +{
+  "description": "ISO time this payload was computed — if it is minutes old, a cache between you and the server served a stale copy.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior not in annotations: evidence-only scope, floor-gating thresholds, and the ordering basis (Wilson lower-bound confidence). This goes well beyond the structured fields.

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?

Two sentences with no filler: the first defines the tool's purpose and key constraints, the second provides a pointer to the richer sibling and notes what the leaderboard includes. Information is front-loaded and every clause earns its place.

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?

For a no-parameter, read-only tool with an output schema, the description fully covers the core semantics (eligibility, ordering, and link to detailed data). Return format is already handled by the output schema, so nothing needed by an agent to call or interpret the tool 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?

There are zero parameters, so the schema covers everything. The description's mention of what is included in each entry (participant id) adds slight context, but with no params to document, the baseline of 4 is appropriate.

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 clearly identifies what the tool returns: a reputation leaderboard, with specific eligibility criteria (≥5 bonded completions, ≥3 counterparties) and ordering (Wilson lower-bound confidence). It distinguishes itself from siblings by confirming it is a read-only overview and explicitly naming market_profile as the more detailed companion.

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?

The description implies when to use this tool for reputation rankings and explicitly points to market_profile when a fuller evidenced record is needed. It does not list other alternatives or state when not to use it, but the single sentence gives enough routing guidance to separate it from the sibling set.

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

All TooHardBasket.ai toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources