Skip to main content
Glama
lappi

rttf-mcp

by lappi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_player

Fetch a table tennis player's rttf.ru profile: ratings by category, rating history, stats, and recent tournaments with place and win/loss balance.

Instructions

Профиль игрока rttf.ru: рейтинги по категориям, история рейтинга, сводка и последние турниры с местом и балансом. Один запрос к сайту.

player_id — число из адреса профиля на сайте (rttf.ru/players/28415). Поиска по имени нет ни в одном режиме: сайт закрыл его в robots.txt. Выйти на игрока можно через list_players или через итоговую таблицу турнира (get_tournament).

Анкета: player_id, name (ФИО как на сайте), city (город со страной в скобках, как на сайте), sports_rank (спортивный разряд, например "МС"), playing_hand ("левая" | "правая") — каждое null, если игрок его не указал. equipment — инвентарь: blade (основание), rubber_right и rubber_left (накладки), каждое {item_id, name} или null.

categories — словарь по коду категории; ключ есть, только если у игрока есть такая вкладка на сайте. Отсутствие ключа означает «категории у игрока нет», а не сбой. Замеренные коды:

  • "s" — одиночный разряд, основной рейтинг RTTF;

  • "d" — парный разряд. Своего рейтинга у пар на сайте нет: rating_current, rating_max и rating_max_date равны null, а rating_history пуст. В турнирах пары стоят одиночные рейтинги партнёров на момент турнира и их сумма (pair_rating_at_event);

  • "f" — рейтинг ФНТР (федерации), внешний к RTTF. Для него есть только текущее значение, максимум и история; stats, recent_tournaments и recent_tournaments_truncated равны null. Прочие коды (h, p, m, w, r) в замерах не встретились; такая категория придёт под своим кодом с подписью сайта в label. Отдельной категории для нерабочей руки на сайте не найдено; playing_hand — это игровая рука из анкеты.

Рейтинги — целые, и это округление внутреннего дробного значения, а не усечение (проверено на различающем случае). Рейтинг бывает отрицательным: у новичка после неудачного турнира -18, а перед следующим турниром сайт сбрасывает его до 1.

rating_history — полный график рейтинга по датам турниров (у ФНТР — по месяцам). Первая точка может иметь date null: это стартовый рейтинг.

stats — сводка категории; поля, которых на сайте нет (rank_position у пар), равны null.

recent_tournaments — НЕ ВСЕ турниры, а не больше десяти последних по категории: полный список сайт отдаёт только через закрытый /results. recent_tournaments_truncated равно true, когда stats.tournaments_played больше длины списка. Для каждого турнира: rating_before_event и rating_after_event — рейтинг игрока до и после этого турнира, rating_delta — изменение (пустая ячейка сайта — это 0.0), bonus — бонус за призовое место или null, place — место или null, если сайт его не указал (лиги), wins/losses — баланс встреч в турнире.

ДАННЫЕ УРОВНЯ МАТЧА В ЭТОМ РЕЖИМЕ НЕ ВЫДАЮТСЯ: соперники, счёт,
длительность и дельта отдельных встреч, лучшие победы, очные встречи.
Это не поломка и не отсутствие данных на сайте, а сознательное
ограничение: rttf.ru закрыл эти разделы в robots.txt, и сервер
запущен без RTTF_MCP_ALLOW_RESTRICTED. Не делайте вывода, что у игрока нет матчей, —
турниры с местом и балансом побед в ответе есть.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
player_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals many non-obvious behaviors: ratings are rounded rather than truncated, can be negative and are reset to 1, history points may have null dates, recent tournaments are truncated at ten, restricted sections are omitted by design, and absent category keys indicate absence rather than failure. This is exceptionally transparent.

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 long, but every paragraph earns its place by documenting real behavioral nuances and edge cases. It is structured with clear labels and paragraphs for each response component, and the most important usage caveats are placed prominently. No filler or tautological phrasing is present.

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?

Given that there is no output schema stub beyond the input parameters, the description carries the entire burden of documenting the response shape. It comprehensively explains the top-level fields, category structures, rating semantics, stats, tournament fields, and all relevant null/absence behaviors. It is complete enough for an agent to invoke the tool and interpret its results correctly.

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

Parameters5/5

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

The input schema only defines player_id as a string with no explanation. The description compensates fully by specifying that player_id is a number taken from the profile URL, giving a concrete example (rttf.ru/players/28415). This adds critical meaning beyond the schema and leaves no ambiguity about how to obtain and format the parameter.

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 resource (player profile on rttf.ru) and the specific contents returned: category ratings, rating history, summary, and recent tournaments with place and balance. It also explicitly distinguishes itself from sibling tools by noting that name search is unavailable and that list_players or get_tournament should be used to reach a player.

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?

The description gives concrete guidance on when to use this tool versus alternatives: it explains that there is no by-name search, that player_id must be taken from the profile URL, and that list_players or get_tournament are the routes to find a player. It also clarifies that match-level data is intentionally not returned, preventing incorrect use of the tool for that purpose.

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