Skip to main content
Glama
Sign In
OpenPowerlifting MCP

OpenPowerlifting MCP

by sebastianpantin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

percentile_for_total

Read-onlyIdempotent

Calculate where a powerlifting total ranks as a percentile among lifters in a filtered cohort, using each lifter’s best total and ignoring disqualified entries.

Instructions

Where a total ranks among lifters' best totals in a filtered cohort.

Each lifter counts once, with their best total. Disqualified entries are ignored. Weight classes differ between federations and eras, so leave weight_class out for a broad comparison.

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": {
      "total_kg": "<total_kg>",
      "sex": "<sex>"
    },
    "name": "percentile_for_total"
  }
}

Input Schema

NameRequiredDescriptionDefault
sexYes
eventNoSBD
testedNotrue for drug-tested only, false for untested only
total_kgYes
equipmentNo
weight_classNoOpenPowerlifting class label, e.g. '93' or '120+'

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower. The description adds genuinely non-obvious semantics beyond them: de-duplication to one best total per lifter and exclusion of disqualified entries, both of which materially change the result. It does not discuss cost, latency, or result shape, but the output schema covers the latter.

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?

Four short sentences, purpose front-loaded, no filler. The cohort rules follow the purpose in the right order. The weight_class advice could arguably live in the parameter description instead of the main text, but it is still worth stating.

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 six-parameter statistical query with annotations and an output schema in place, the description covers what an agent can't get elsewhere: cohort semantics, de-duplication, DQ handling, and the weight-class caveat. The remaining gap is the unexplained event enum and untested/equipment filtering behavior.

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 description coverage is only 33%, so the description has to carry meaning, and it does for weight_class: it explains that class labels vary by federation and era and that omitting the field widens the comparison. The other parameters get nothing — notably event, whose enum values (SBD, BD, SD, SB, S, B, D) are abbreviations an agent must infer.

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 first sentence states a specific verb and resource: it ranks a given total against lifters' best totals within a filtered cohort. That is unmistakably distinct from the siblings (search_lifters, lifter_history, compare_lifters), which retrieve or compare named lifters rather than compute a standing.

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?

It gives clear usage context: the comparison is against a filtered cohort, each lifter appears once with their best total, and disqualified entries are dropped. It also advises leaving weight_class out for a broad comparison, which is a practical exclusion. It stops short of naming when to prefer compare_lifters or lifter_history instead.

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