Skip to main content
Glama
Sign In
OpenPowerlifting MCP

OpenPowerlifting MCP

by sebastianpantin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

lifter_history

Read-onlyIdempotent

Retrieve every meet and attempt for a named powerlifter in date order, with candidate names returned when no exact match exists.

Instructions

Every meet for one lifter in date order, with each attempt per lift.

A fourth attempt is a record attempt and does not count toward the total.

If the name has no exact match, returns found=false and a list of candidates.

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

Input Schema

NameRequiredDescriptionDefault
nameYesExact lifter name including any '#N' suffix

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world behavior, so the bar is lower, yet the description still adds real domain context: results are date-ordered, a fourth attempt is a record attempt excluded from the total, and a failed exact match returns found=false with candidates. It does not cover empty-history cases, but the added behavioral detail is meaningful.

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, front-loaded statements: the result shape first, then a scoring caveat, then failure behavior. No filler and nothing that could be trimmed without losing information.

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 single-parameter read-only lookup with an output schema, the description covers the return shape, a subtle domain rule, and the not-found path, which is nearly everything an agent needs. Minor gaps like whether candidates are exhaustive or how large histories paginate keep it from a 5.

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?

Only one parameter and the schema already documents it at 100% coverage, including the '#N' suffix convention. The description reinforces the exact-match requirement but adds no new syntax or formatting detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: every meet for one lifter, in date order, with each attempt per lift. It is clearly distinct from search_lifters and compare_lifters in substance, but it never names those siblings or explicitly says to use them instead when exact names are unknown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the 'exact match' requirement plus the candidate fallback hints that a name lookup may be needed first, but there is no explicit when-to-use guidance or exclusion versus search_lifters or compare_lifters.

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