Skip to main content
Glama

Openpowerlifting

Opl Lifter History

opl_lifter_history
Read-onlyIdempotent

Competition history of one powerlifter from the OpenPowerlifting results database: every meet entered (most recent first) with federation, event, equipment, division, bodyweight and weight class, best squat/bench/deadlift, total, place and Dots/Wilks/Goodlift points, plus career bests. Pass name as shown in results (e.g. "Ray Williams"; case-insensitive, exact name). Lifters who share a name are disambiguated in the data as "Name #1", "Name #2": a name that matches several lifters returns their candidates (name, country, entry count, years, best total) instead of mixing them -- pass the exact "Name #N". equipment (Raw, Wraps, Single-ply, Multi-ply, Unlimited, Straps) narrows the history and the bests. Rows page with limit/offset and report truncated/total_matching. An unknown name returns found:false with data_as_of, never an empty list. Weights are in kilograms.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "Ed Coan",
      "limit": 5
    },
    "name": "opl_lifter_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesLifter name as in results, e.g. "Ray Williams" or "John Smith #2".
limitNoEntries per page, 1-200 (default 50).
offsetNoEntries to skip (default 0).
equipmentNoOnly entries in this equipment category.

Output Schema

NameRequiredDescriptionDefault
sexNo
hintNo
foundNo
careerNo
lifterNo
sourceNo
countryNo
licenceNo
resultsNo
returnedNo
truncatedNo
data_as_ofNo
total_matchingNo
latest_meet_dateNo
copy_refreshed_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses the ambiguity branch (candidate list instead of mixed rows), the unknown-name behavior (found:false with data_as_of, never an empty list), pagination signals (truncated/total_matching), ordering (most recent first), and unit convention (kilograms). This is exactly the non-obvious behavior an agent needs.

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?

Front-loads purpose and output contents, then behavior notes in a logical order with zero filler. Some sentences are long run-ons (the disambiguation sentence), costing a point on structure but not on usefulness.

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?

With an output schema already defining return shape, the description covers all remaining agent-facing unknowns: name resolution, ambiguity handling, missing-name behavior, paging, ordering, and units. Nothing needed to call it correctly 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?

Schema coverage is 100%, so the baseline is 3; the description still adds matching semantics the schema lacks — case-insensitive but exact-name match, the '#N' suffix convention, and example names. It also confirms equipment filters both rows and career bests, which the enum description does not.

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 ('Competition history of one powerlifter from the OpenPowerlifting results database') and enumerates the returned fields. The 'one powerlifter' scoping and career-bests mention distinguish it from meet- or record-centric siblings like opl_meet_results and opl_records.

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?

Explains when the disambiguation path applies ('a name that matches several lifers returns their candidates ... pass the exact "Name #N"') and how equipment narrows both history and bests. It never names an alternative sibling or an explicit when-not-to-use condition, keeping it short of a 5.

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.