Skip to main content
Glama

bo3_team_ranking_dates

Read-only

Returns the days for which Valve published an official ranking for a game (newest first) and the region labels accepted by bo3_team_rankings for that game. Provide game (cs2 by default). Use it to pick date and region values for bo3_team_rankings.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bo3_team_ranking_dates"
  }
}

Input Schema

NameRequiredDescriptionDefault
gameNoOptional game: cs2 (default), valorant, lol, dota2, r6siege or mlbb.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds the useful non-obvious detail that results come back newest first and that the payload mixes two things (dates and region labels). It does not mention pagination or coverage limits, but for a small read-only lookup helper that is a minor omission.

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?

Three short sentences: what it returns, what to provide, why to call it. The ordering hint and the routing instruction are both front-loaded with no filler or restated title.

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?

Complete for a one-parameter lookup whose output schema already defines the return shape. The description covers what is returned, its ordering, the optional parameter, and the intended role as a value source for the sibling tool.

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 coverage is 100% and the single 'game' parameter already documents its enum values and the cs2 default, which the description merely repeats. Baseline 3 is appropriate — the description adds no format or behavior detail about the parameter beyond the schema.

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?

States a specific verb and resource — returns the published ranking dates plus the accepted region labels per game — and front-loads the newest-first ordering. An agent can distinguish it from bo3_team_rankings immediately, since the description explicitly frames it as the lookup feeding that tool.

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?

Explicitly instructs: 'Use it to pick date and region values for bo3_team_rankings.' That names the downstream tool and the exact condition that selects this one, leaving no inference needed about when to call it versus the rankings endpoint.

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.