Skip to main content
Glama
Sign In
rankedtoday-mcp

rankedtoday-mcp

by RyanKramer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

season_countdown

Calculate days remaining until a ranked season boundary or custom date. Provide a from_date to count from a fixed day, otherwise uses today.

Instructions

Days remaining until a ranked season boundary or any other date.

Pass from_date (YYYY-MM-DD) to compute from a fixed day; otherwise uses today.

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": {
      "target_date": "<target_date>"
    },
    "name": "season_countdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
from_dateNo
target_dateYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

There are no annotations, so the description carries the burden. It discloses that from_date is optional and defaults to today, which is a key behavior. However, it does not mention handling of past dates, timezone, or inclusivity, leaving some gaps for a simple read-only tool.

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?

The description is two short sentences, front-loaded with the core function, and every word serves a purpose. It avoids repetition.

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 a simple countdown tool with an output schema, the description covers the essential usage and parameter behavior, though it could mention edge cases like past dates. It is largely complete for its complexity.

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 0%, so the description must explain parameters. It explains from_date with format (YYYY-MM-DD) and its role, but it does not explicitly name or describe target_date, even though it's required. Context implies target_date is the countdown target, but it's not spelled out.

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 states the tool computes days remaining until a ranked season boundary or any other date, using a specific verb 'compute' and a clear resource (date countdown). This distinguishes it from sibling tools like kda or climb_calculator, which deal with different metrics.

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 gives clear context: use for countdown to a date, with optional from_date to set a fixed reference. It does not explicitly mention alternatives or when not to use, but the use case is clear given the sibling tool names.

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