Measure card centering and check PSA, BGS, CGC and SGC centering ceilings and standards.
Scored across 3 tools
The three tools cover distinct stages: lookup of centering standards, conversion of known ratios into grade ceilings, and photo-based measurement. While get_centering_standards and grade_centering both involve thresholds, their descriptions clearly separate source lookup from ratio calculation, so selection is unambiguous.
All tool names use consistent snake_case with verb-led phrasing: get_centering_standards, grade_centering, and measure_card_centering. The slight variation in noun length is minor and does not break the predictable pattern.
Three tools are well suited to this narrow centering-analysis domain. Each tool earns its place by covering standards lookup, grade-ceiling conversion, and image measurement without redundancy.
The set covers the core lifecycle: retrieving standards, converting ratios to grade ceilings, and measuring centering from photos. Minor gaps remain, such as excluding TAG and lacking a batch or multi-card workflow, but agents can work around these for typical use.
Look up card centering thresholds for PSA, BGS, CGC and SGC, optionally by house and front/back. Use for threshold/rules questions and source checks. Returns per-band official/interpreted/approximate status, source links, verification date/provenance and rounding rule. TAG is excluded. These are centering ceilings, not grade predictions.
| Name | Required | Description | Default |
|---|---|---|---|
| face | No | ||
| house | No |
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| tag_note | Yes | |
| standards | Yes | |
| disclaimer | Yes | |
| rounding_rule | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine non-obvious behavior: per-band official/interpreted/approximate status, provenance/verification dates, rounding rule, and the TAG exclusion. Pagination/rate limits are irrelevant for a static reference lookup, so this is close to sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly packed fragments, front-loaded with the lookup purpose and ending with the key caveat. Dense but essentially waste-free; the return-value enumeration could be trimmed slightly given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter static reference tool with an output schema, the description covers purpose, usage, caveats, exclusions and result semantics. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the burden, and it does: it names the four houses and front/back and the word 'optionally' signals both filters are non-required. It adds little about how combined filtering behaves, keeping it below a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (card centering thresholds) with the exact scope (PSA, BGS, CGC, SGC, optional house/front-back). The closing line 'centering ceilings, not grade predictions' explicitly separates it from grade_centering, so an agent can pick it apart from its siblings without reading their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for threshold/rules questions and source checks' gives clear selection context, and the TAG exclusion narrows applicability. It stops short of naming the sibling tools or stating when-not to use it, but the domain is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert known card centering ratios into the maximum grade permitted by centering at PSA, BGS, CGC and SGC. Use for questions such as “is 58/42 a PSA 10?” without needing a photo. Accept reversed ratios and percentages. At least one axis is required. Missing axes or faces may lower the ceiling; never describe it as a predicted grade. BGS uses both axes. Return provenance, limiting face/axis and distance to the next step.
| Name | Required | Description | Default |
|---|---|---|---|
| back_lr | No | A percentage (55 or 45), or two percentages summing to 100 ("55/45" or "45/55"). Normalized to the larger side. | |
| back_tb | No | A percentage (55 or 45), or two percentages summing to 100 ("55/45" or "45/55"). Normalized to the larger side. | |
| front_lr | No | A percentage (55 or 45), or two percentages summing to 100 ("55/45" or "45/55"). Normalized to the larger side. | |
| front_tb | No | A percentage (55 or 45), or two percentages summing to 100 ("55/45" or "45/55"). Normalized to the larger side. |
| Name | Required | Description |
|---|---|---|
| back | Yes | |
| front | Yes | |
| summary | Yes | |
| combined | Yes | |
| disclaimer | Yes | |
| incomplete | Yes | |
| missing_faces | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds real behavioral context beyond them: partial-input behavior ('Missing axes or faces may lower the ceiling'), the BGS-both-axes rule, and the framing constraint ('never describe it as a predicted grade'). These caveats meaningfully guide correct interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then usage, then caveats. Sentences are dense but each carries distinct information (input formats, requirements, output framing). Slightly packed but no wasted clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail needn't be spelled out, yet the description still notes provenance, limiting face/axis, and distance to the next step. Input requirements and caveats are covered, making it complete for a multi-provider grading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds semantics the schema lacks: it accepts reversed ratios and requires 'at least one axis' even though the schema marks zero required parameters. That requirement and reverse-order acceptance are genuinely new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Convert known card centering ratios into the maximum grade') across four named grading companies. The phrase 'without needing a photo' implicitly distinguishes it from the sibling measure_card_centering, letting an agent route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage trigger ('questions such as "is 58/42 a PSA 10?"') and states input constraints ('At least one axis is required'). It does not explicitly name the alternatives (get_centering_standards, measure_card_centering) or state when-not to use it, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure worst-station left/right and top/bottom card centering from one photograph. Ask front or back before calling. Request a whole card, flat on a dark surface, straight from above and out of its sleeve. The photo is processed on the server in memory and discarded, unlike the local-only website. Use a public HTTPS URL or image bytes supported by the client. If a chat attachment cannot be passed to this remote tool, send the user to https://centeringlab.com/. needs-review or failed means no grade ceilings: suggest a retake or manual website adjustment. Never predict a final grade.
| Name | Required | Description | Default |
|---|---|---|---|
| face | Yes | Required: ask the user whether the photo shows the front or back if unclear. | |
| card_size | No | standard = 63×88 mm; small = 59×86 mm. | standard |
| image_url | No | Public HTTPS image URL, port 443. Private network addresses and non-image responses are rejected. | |
| image_base64 | No | Raw base64 encoded raster image, without a data-URL prefix. Intended for clients that can supply image bytes. |
| Name | Required | Description |
|---|---|---|
| lr | Yes | |
| tb | Yes | |
| code | Yes | |
| face | Yes | |
| advice | Yes | |
| status | Yes | |
| summary | Yes | |
| ceilings | Yes | |
| warnings | Yes | |
| card_size | Yes | |
| adjust_url | Yes | |
| confidence | Yes | |
| disclaimer | Yes | |
| elapsed_ms | Yes | |
| image_bytes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld) by disclosing that the photo is processed in memory and discarded server-side, how status outputs (needs-review/failed) map to action, and a hard constraint against predicting a grade.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then preconditions, privacy note, input options, fallback, and status handling. Every sentence is actionable and none repeats another.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't explain return values, yet it still clarifies status meanings and the acceptable input forms. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, including detailed descriptions for face, image_url, and image_base64, so the baseline is 3. The description's 'public HTTPS URL or image bytes' and 'ask front or back' largely restate the schema and add no card_size detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Measure ... card centering from one photograph') and even names the exact metric reported ('worst-station left/right and top/bottom'). The closing rule 'Never predict a final grade' implicitly separates it from the grade_centering sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit preconditions ('Ask front or back before calling'), photo requirements (whole card, flat, dark surface, straight from above, out of sleeve), and a concrete fallback (send user to the website if an attachment cannot be passed). Also tells the agent what to do on needs-review/failed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_centering_standardsgrade_centeringmeasure_card_centeringTrading card prices and grading ROI for 1.5M+ Pokémon, Magic, Yu-Gi-Oh! and sports cards. Read-only.
Real sold prices, history & PSA population for graded Pokémon cards (EN/JP/CN). Knows nicknames.
MCP tools: collectible price-fairness, recall safety, drop tracking, card grading, settlements.
Connect to your CollectHolo Pokémon card collection. Check your portfolio value, look up card, sealed and graded (PSA/BGS/CGC) prices from Cardmarket, TCGplayer, eBay, Goldin and Fanatics, search the catalog in six languages, import a whole collection from a spreadsheet, and add or update holdings in plain language. Every change asks for confirmation.
Add one secure layer between your agents and this server.