tcg-mcp

by seanlok

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation5/5
Each tool has a clear, distinct purpose grouped by domain (catalog, collection, pricing, PSA, watchlist). For example, tcg_collection_list and tcg_collection_search are differentiated by filter scope. Stubbed tools are explicitly marked as not implemented, avoiding confusion.
Naming Consistency5/5
All tools follow a consistent tcg_<category>_<action> pattern in snake_case (e.g., tcg_catalog_get_set, tcg_collection_add_card). Even combined tools like tcg_psa_add_to_collection adhere to the convention. The naming is predictable and uniform.
Tool Count4/5
33 tools cover a broad domain (catalog, collection, pricing, grading, watchlist) without being excessive. While some specialization exists (e.g., separate value vs value_with_market), the count is reasonable for the feature set and not overwhelming.
Completeness5/5
The tool surface covers the full lifecycle: catalog search, collection CRUD, pricing with history and snapshots, PSA grading lookup and population trend, and watchlist management. Gaps like BGS/CGC are acknowledged via stubbed tools. No dead ends hinder an agent's workflow.
Average 3.9/5 across 33 of 33 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal hints (readOnlyHint=false, destructiveHint=false, etc.), so the description should clarify behavior. It only says 'update mutable fields', omitting whether partial updates merge, whether nulls clear fields, or what happens to omitted fields. This is insufficient for mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks structure (e.g., bullet points for parameters). While brief, it could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter (a nested object with 6 sub-fields), complex update semantics, and an output schema (not shown), the description should explain behavior like merge vs replace, return value, and possible errors. The current description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool description does not elaborate on any parameter (e.g., meaning of horizon enum, target_price format). The description adds zero value beyond parameter names, failing to compensate for the schema gap.
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 verb 'Update' and the resource 'watchlist entry', with 'mutable fields' adding specificity. It clearly distinguishes from sibling tools like tcg_watchlist_add (create) and tcg_watchlist_get (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., tcg_watchlist_close or tcg_watchlist_add). The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is clear. Description adds only that a horizon filter is optional, missing behavioral details like pagination, default open_only, or that it returns a list. Minimal added value.
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?
One sentence of 6 words is extremely concise with no wasted words. Front-loaded key information. However, lacks detail but achieves conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. But the tool has four parameters (horizon, open_only, limit, offset) and the description only addresses one. For a list tool with pagination and filtering, this is incomplete. Annotations cover safety but not parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It only mentions 'horizon filter', ignoring open_only, limit, and offset parameters. The schema itself lacks descriptions for most fields except open_only. The tool's description fails to explain key parameters.
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?
Description clearly states the tool lists watchlist entries with an optional horizon filter, specifying the resource and action. It distinguishes from siblings like tcg_watchlist_get (single entry) and tcg_watchlist_add, but could be more explicit about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tcg_watchlist_get or tcg_watchlist_search (not listed but possibly exists). Implied usage from name but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond what the schema provides, such as default status or pagination behavior. Minimal additional value.
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 a single, concise sentence that front-loads the verb and resource. Every word carries meaning, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with annotations, the description suffices in stating the basic purpose. However, it lacks usage guidance and parameter details, which are partially covered by the schema. Sibling tools exist that could cause confusion without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (though subject_like has a description). The description mentions 'optional filters and pagination' but does not explain the filter parameters (status, grading_provider, subject_like) or pagination parameters (limit, offset), leaving the agent to rely solely on schema names.
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?
The description clearly states the tool lists cards in the local collection with optional filters and pagination. It uses a specific verb and resource, but does not explicitly differentiate from similar sibling tools like tcg_collection_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions or context for when to use tcg_collection_list over tcg_collection_search or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: explains multi-row creation for graded levels and payload storage policy. No contradiction with annotations.
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?
Three sentences, front-loaded with main purpose, no fluff. Could be more concise but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral aspects (multi-row, payload) but omits parameter explanations. With an output schema, return value explanation is less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No description of parameters (listing_id, provider) despite 0% schema coverage. The schema provides enums and defaults, but agent needs to infer meaning.
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 that the tool fetches a price quote and persists it as a row, with specific behavior for graded providers. It distinguishes from siblings like 'tcg_pricing_get' by adding the persistence aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., 'tcg_pricing_get' for just fetching). The description implies use for storing snapshots, but lacks explicit when/when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds only that it returns specific fields, which is minimal beyond annotations.
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?
Single sentence with clear verb and object; front-loaded and no wasted words.
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?
Given the presence of an output schema and the simple search functionality, the description is adequate. It mentions return fields and implies search behavior, but could note pagination or ordering.
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?
Input schema contains detailed descriptions for the 'query' parameter and constraints for 'limit'. The tool description does not add any parameter information beyond the schema, so baseline score of 3 is appropriate.
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?
Description clearly states the tool searches Pokemon TCG sets and lists what is returned. It distinguishes from sibling tools like tcg_catalog_get_set (specific set) and tcg_catalog_list_cards_in_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of when not to use or context like prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint. The description adds critical context that the tool is stubbed and returns an error, which goes beyond the annotations. No contradiction.
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?
Two sentences with no fluff: first states purpose and stub status, second explains why. Front-loaded and concise, though could be restructured to emphasize the non-functionality first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stub tool, the description is mostly adequate, but it lacks details about the exact error format or how the agent should handle it. With an output schema likely describing the error, completeness is decent but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), yet the tool description provides no additional meaning for the 'cert_number' parameter. The agent only has the parameter name and constraints from the schema; description should clarify format or purpose.
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?
Description clearly states it is a 'stubbed' implementation for CGC cert lookup, which returns a 'not supported' error. The verb 'lookup' and resource 'graded card' are implied, but no explicit differentiation from sibling tools like tcg_psa_get_cert or tcg_bgs_get_cert.
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?
Implies the tool is non-functional due to 'No official public API' and 'stubbed', but does not explicitly tell the agent when to avoid it or suggest alternatives. More direct guidance such as 'Do not use; use PSA/BGS tools instead' would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the return value (watchlist_id) but does not disclose other behavioral traits such as side effects, authorization needs, or rate limits. The annotations (readOnlyHint=false, destructiveHint=false) provide minimal safety context, and the description does not add significant behavioral insights beyond the return.
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 two sentences, front-loading the core action and return value. Every sentence provides essential information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (1 required), an output schema, and moderate complexity, the description is too brief. It omits explanation for horizon and target_currency, and does not clarify how the target price interacts with the watchlist. While the output schema may return the ID, the description should provide more context for the agent to correctly fill parameters.
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?
With 0% schema description coverage, the description compensates partially by mentioning 'target buy price + thesis', which corresponds to two key parameters. However, it does not explain other parameters (horizon, target_currency) or their constraints (e.g., enum values, validation).
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 verb 'add' and the resource 'card to watchlist', and specifies the key parameters (target buy price, thesis) and return value (watchlist ID). This effectively distinguishes it from sibling tools like tcg_watchlist_close, tcg_watchlist_get, etc.
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?
The description implies usage for adding a card to the watchlist, which is distinct from listing or closing. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no additional behavioral traits beyond stating the operation, such as side effects or authorization requirements. It does not contradict annotations.
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?
The description is a single sentence that front-loads the verb 'Mark'. It is concise but could be more specific (e.g., 'Close a watchlist entry'). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations cover destructive and idempotent hints and an output schema exists, the description provides minimal context. Missing details on return values, prerequisites, or examples, but adequate for a simple mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters explicitly. The input schema provides descriptions for 'reason' but not for 'watchlist_id'. With 0% schema description coverage, the description adds no value beyond the schema.
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 action (Mark a watchlist entry closed) and lists specific reasons (bought, thesis_invalidated, manual). This distinguishes it from sibling tools like tcg_watchlist_add or tcg_watchlist_get.
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?
The description implies usage for closing watchlist entries but provides no explicit guidance on when to use it versus alternatives or when not to use it. No context on prerequisites or error scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with annotations (readOnlyHint false, destructiveHint false) and confirms mutation. No additional behavioral details beyond what annotations already provide, such as error handling or partial update behavior.
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?
Single sentence with ellipsis is concise but borderline too brief. No structural issues, but could benefit from brief parameter grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13+ parameters with 0% schema description and many sibling tools, the description is insufficient. Does not explain partial update semantics or required identifiers, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description only mentions 'cost basis, notes, status, ...' which vaguely hints at parameters but fails to explain all fields, formats (e.g., dates, currencies), or that card_id is required.
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?
Clearly states it updates mutable fields on a collection card, listing examples like cost basis, notes, and status. Distinguishes from sibling tools such as add, remove, and search.
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?
Implicitly indicates when to use (update existing cards) versus siblings. Lacks explicit prerequisites (e.g., card must exist) or when not to use, but context from siblings clarifies the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description's 'fetch' is consistent but adds no additional behavioral context beyond what annotations provide.
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?
One short, front-loaded sentence with no wasted words every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with an output schema, the description is minimally adequate. However, it lacks guidance on error handling (e.g., non-existent id) and does not differentiate from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only says 'by id', adding minimal value. It does not clarify format, examples, or constraints beyond schema's minLength:4.
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 verb 'fetch', the resource 'watchlist entry', and the identifier 'by id'. It distinguishes from sibling tools like tcg_watchlist_list and tcg_watchlist_add.
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?
The description implies usage when a specific watchlist_id is known, but does not explicitly state when to use this vs alternatives like tcg_watchlist_list or when not to use it, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations by stating that the tool is stubbed, returns a 'not supported' error, and that implementation is deferred. This clearly communicates the tool's current non-functional status.
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?
The description is very concise (two sentences) and front-loaded with the key fact 'stubbed'. Every sentence is relevant, with no wasted words. However, it could be slightly more structured by adding parameter info, but given the stub nature, it is appropriately sized.
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 the tool is a stub and has an output schema (likely for error responses), the description is complete. It explains the current state, the expected behavior (error), and the reason. No further details are needed for an agent to understand how to handle this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no parameter-level details about 'cert_number' (e.g., format, purpose). The schema only shows length constraints. The description fails to add meaning beyond the schema, which is insufficient for proper parameter usage.
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 identifies the tool as a BGS cert lookup that is stubbed, distinguishing it from sibling tools like tcg_psa_get_cert and tcg_cgc_get_cert. It explicitly states that Beckett has no official public API and that it returns a 'not supported' error, making the purpose precise.
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?
The description implies the tool should not be used for actual lookups because it returns an error, but it does not explicitly recommend alternative tools or provide when-to-use guidance. The annotation title includes 'STUB', which helps, but the description lacks direct usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds minor context about search fields but lacks depth on pagination or result handling.
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?
Single efficient sentence with front-loaded action and scope, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a detailed input schema and output schema, the description covers the essential purpose and differentiation but could elaborate on pagination or filtering nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description repeats the search fields already covered in the 'query' parameter's schema description, adding minimal new value. Schema descriptions are present but not exhaustive.
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 tool searches owned cards across multiple fields and distinguishes it from sibling tcg_collection_list, providing a specific verb and resource.
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?
The description explicitly compares to tcg_collection_list, indicating when to use this tool for richer searches, but does not mention when not to use it or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the effect (enabling live market value computation) beyond annotations. Annotations indicate idempotent and non-destructive, which aligns with 'map' action. The description adds context about future snapshot calls, which is useful.
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 two sentences, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value.
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?
Given the complexity (a mapping operation) and presence of an output schema, the description adequately explains the tool's role and post-condition. It could mention prerequisites (e.g., card must exist), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters; schema coverage is 0%. The schema itself provides descriptions for two of three parameters, but the description offers no additional meaning beyond what is in the schema.
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 tool's purpose: 'Map an owned card to a pricing listing for live valuation.' It uses a specific verb-resource combination and distinguishes this tool from siblings by explaining the subsequent use of `tcg_pricing_snapshot` for valuation.
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?
The description implies the tool is a prerequisite for valuation (via `tcg_pricing_snapshot`), but it does not explicitly state when to use it versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by stating it's free, requires no API key, and lists example output fields, going beyond the annotations.
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?
Two sentences no wasted words. Key purpose and unique selling point (free, no API key) are front-loaded.
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 simple single-parameter fetch tool with an output schema and safety annotations, the description is nearly complete. The example output fields add helpful context.
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?
The single parameter 'set_id' has a minimal schema description ('e.g. 'sv8''), so the tool description adds no further meaning. With the schema already covering the basics, a 3 is appropriate.
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 'Fetch a Pokemon TCG set's metadata' with specific examples of fields (name, total cards, release date). It distinguishes from siblings like tcg_catalog_search_set (search) and tcg_catalog_list_cards_in_set (list cards).
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?
The description implies use for a known set ID but does not explicitly state when to use this vs. alternative tools like search or list cards. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that sealed product shares the same table as singles with a different product_type, and that one row is inserted per quantity unit for cost basis tracking. It also states the return format (list of card_ids). This adds value beyond the annotations, which only indicate non-read-only status.
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 concise, with three sentences that front-load the main purpose. The second and third sentences provide necessary context without fluff. Every sentence earns its place.
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?
The description adequately covers the essential behaviors for adding sealed product, including internal storage and return values. However, it does not elaborate on error conditions or prerequisites (e.g., set existence), but these are common and the schema covers required fields.
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?
The input schema already contains descriptions for most parameters (e.g., acquisition_price: 'Per-unit price'). The tool description adds no new parameter-specific information beyond the schema. Given the schema's existing coverage, a baseline score of 3 is appropriate.
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 tool records sealed product as owned, and explains the internal storage distinction from singles. This directly addresses the purpose and differentiates from sibling tools like tcg_collection_add_card.
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?
The description implies use for sealed products but does not explicitly state when to use this tool versus alternatives. It provides context but lacks clear when-not guidance or explicit reference to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses soft-delete default (status->'sold') and hard-delete option. Pairing with sold fields is explained. Annotations already mark destructiveHint and idempotentHint, so description adds context on the soft/hard behavior beyond the annotations.
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?
Two sentences, no unnecessary words. First sentence states core behavior, second provides a contextual hint. Efficient and front-loaded.
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?
Given the presence of an output schema, return value details are not needed. Description covers the main behavior, default mode, and optional disposition capture. Missing explicit mention of idempotency but that's covered by annotation. Reasonably complete for the tool's simplicity.
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 already describes some parameters (e.g., hard has a description). The description adds value by suggesting pairing sold_price and sold_date with the remove action. However, most parameter meaning is already in schema.
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?
Clearly states 'Remove a card' with the resource (card) and action (remove). Title in annotations adds 'Remove (or soft-delete)' which further clarifies. Distinguishes from sibling tools like tcg_collection_update or tcg_collection_add_card.
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?
Implies usage for removing a card, and hints to pair with sold_price and sold_date for disposition. However, does not explicitly state when not to use it or compare with alternatives like tcg_collection_update or tcg_collection_attach_pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds return structure details (market, variants, graded_levels, raw), which adds value but not critical beyond annotations and output schema.
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?
Two sentences: first sets purpose, second outlines returns. No extraneous words, front-loaded.
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?
With output schema present, the description sufficiently explains return fields and provider-specific behavior. Minor gaps like error handling are not needed.
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 already describes listing_id (provider-specific ID) and provider (enum with default). Description does not add new parameter info beyond what schema provides, so baseline 3 is appropriate.
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 uses specific verb 'Fetch' and resource 'full PriceQuote' for 'one listing on the chosen provider', clearly differentiating from siblings like tcg_pricing_search or tcg_pricing_get_history.
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?
The context (fetching for one listing) is clear, but no explicit when-not-to-use or alternatives are mentioned, though implicit via sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds return type (list of CardListing rows) but no further behavioral traits beyond annotations.
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?
Two sentences: first states purpose, second states return type and follow-up. No wasted words, front-loaded.
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?
Output schema exists, description mentions return rows. For a search tool with limit parameter, it's adequate. Could optionally note pagination or provider differences, but not necessary.
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 has detailed descriptions for all parameters (query, provider, kind, limit). Tool description adds no parameter details. Baseline 3 due to high schema coverage.
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 it searches a pricing provider for matching products, uses specific verb 'search' and resource. It differentiates from sibling tool tcg_pricing_get by advising to use it afterward.
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?
Provides clear context by suggesting the next step (use tcg_pricing_get with listing_id). Lacks explicit when-not-to-use or alternative search tools, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, signaling safety. The description adds valuable context that older slabs yield an empty list without error, which is not inferable from annotations alone.
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?
Two sentences in a single paragraph: one for the primary action, one for a critical behavioral note. No wasted words; the important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be detailed. However, the description omits the format of the URLs, error handling for invalid cert numbers, and any additional prerequisites beyond the date constraint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'cert_number' parameter (e.g., it is the PSA certification number). The agent must rely on the parameter name and schema constraints, which are insufficient for full understanding.
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 uses specific verb 'Fetch' and clearly identifies the resource as 'front/back image URLs for a PSA graded card.' It distinguishes from siblings like 'tcg_psa_get_cert' which retrieves certificate metadata.
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?
The description provides a key usage note: PSA only attaches images to cards graded after October 2021, so older slabs return an empty list. This guides the agent on when results are meaningful. However, it does not compare with alternatives or explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no extra behavioral context beyond stating the fetch action, but is consistent with annotations.
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?
Single sentence with no wasted words. Front-loaded with action and resource.
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 the tool's simplicity (one parameter, output schema exists), the description fully covers what the tool does. Return values are documented in output schema.
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 has 0% description coverage, so description must compensate. It mentions 'card_id' as the identifier but adds little beyond the schema's minLength constraint. However, it does clarify that card_id identifies an owned card.
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?
Description uses specific verb 'Fetch' and resource 'single owned card', clearly indicating the action and object. The parameter 'card_id' is specified, distinguishing it from list/search siblings.
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?
While no explicit when-not or alternatives are given, the description clearly implies usage when you have a specific card_id and need the owned card details. The context of 'single' vs siblings like list/search is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context: it notes that population data is returned 'when PSA exposes them,' which informs the agent about potential variability in results. This goes beyond annotations without contradiction.
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 concise, consisting of two clear paragraphs. The primary action is stated in the first sentence, and the second paragraph lists returns efficiently. No redundant or unnecessary information.
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 the tool's simplicity, the presence of an output schema, and clear annotations, the description covers all necessary context: what the tool does, what it returns, and an important caveat about data availability. No gaps.
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?
The input schema already provides descriptions for both parameters (cert_number and response_format). With schema description coverage effectively high (100% at the property level), the description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate.
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 tool's purpose: 'Look up a single graded card by its PSA cert number.' It lists the returned data (card metadata, grade, population data), and the title from annotations reinforces this. It distinguishes from sibling tools like tcg_bgs_get_cert and tcg_cgc_get_cert by explicitly mentioning PSA.
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?
The description implies usage for PSA card lookups but does not explicitly state when to use this tool versus alternatives (e.g., for other grading companies) or provide any exclusion criteria. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, open-world hints. Description adds that market prices are included when available, and optional rarity filtering. No contradictions. Could mention pagination via limit/offset, but schema covers that.
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?
Two sentences, first describes action, second gives use cases. No unnecessary words, highly efficient.
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?
Given output schema exists, description does not need to detail return values. It covers filtering and market prices. Lack of explicit pagination mention is minor; overall sufficient for a listing tool.
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?
Description explains the optional rarity filter but does not mention limit or offset parameters. Schema coverage is low, so description should do more; it partially compensates but leaves pagination implicit.
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?
Description clearly states 'List every card in a set (optionally filtered by rarity)' with specific verb and resource. Distinguishes from sibling tools like tcg_catalog_get_set and tcg_catalog_search_set.
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?
Description mentions use cases: 'useful for set-completion analysis and rarity-tier breakdowns'. Provides clear context but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds only the ordering ('oldest-first'), which is useful but not substantial.
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 concise sentences with the main action front-loaded. No unnecessary words.
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?
Given the existence of an output schema and good annotations, the description covers the essential context (prerequisite, ordering). Minor missing details like pagination are acceptable for a simple read-only tool.
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?
The description adds context about requiring prior snapshots and ordering, but does not explain each parameter in detail beyond what the schema already provides. The schema includes descriptions for grade, days, and limit, but provider and listing_id lack descriptions.
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 tool returns a time series of pricing snapshots for one listing. It distinguishes from siblings by noting it only works for listings that have been snapshotted via specific tools.
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?
Provides specific use case examples (e.g., 'is PSA 10 trending up?') and a prerequisite (must have snapshotted the listing), guiding when to use and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds context about the local SQLite database and return value (UUID), which is useful beyond annotations.
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 two sentences: one functional statement and one return value. It is concise, front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of many optional parameters, the description is minimal. It doesn't summarize required fields or typical usage patterns, though the schema object description partially compensates.
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?
With schema description coverage at 0% (many parameters lack descriptions), the description does little to explain the numerous optional fields. However, the input schema object description provides some context on usage scenarios.
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 'Record a card as owned in the local SQLite DB' with a specific verb and resource, and distinguishes from the sibling `tcg_psa_add_to_collection` via the input schema's object description.
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 input schema object description explicitly tells when to use this tool (raw cards or unsupported graded providers) versus the alternative `tcg_psa_add_to_collection` for PSA graded cards, providing excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral details: matching logic (by pricing_listing_id or subject+card_number) and watchlist cross-reference. No contradictions.
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 concise with a clear structure: purpose sentence, then bullet points for each card logic, then return values. Every sentence adds information without repetition or fluff.
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?
Despite no output schema shown, the description lists all key return values (owned/missing counts, completion percentage, gap cost, per-card breakdown). The tool has few parameters and the logic is fully explained. It is complete for a read-only computation tool.
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 partial (rarity has description, set_id has none). The description mentions optional rarity filter but does not add significant meaning beyond the schema. The matching logic description does not directly enhance parameter semantics. Score is baseline 3 because schema coverage is moderate but description doesn't fully compensate.
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 'Compute set-completion progress for a Pokemon TCG set' with a specific verb and resource. It distinguishes itself from sibling collection tools like tcg_collection_get or tcg_collection_list by focusing on set completion and gap pricing.
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?
The description explains the matching logic (ownership, watchlist, missing) and optional rarity filter, providing clear context. However, it does not explicitly state when not to use this tool or suggest alternatives, which is minor given the clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds minimal behavioral context (lists providers enabled in process). No contradictions.
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?
Two sentences, front-loaded with purpose, no redundant words. Very concise and well-structured.
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?
For a simple list tool with output schema and no parameters, the description fully covers what the tool does and when to use it. No gaps.
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?
Input schema has one parameter (params) that is an empty object, effectively no parameters. Description does not need to add parameter info; schema handles it. Score reflects no parameter details needed.
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 it shows enabled grading/pricing providers, which is a specific verb+resource. It distinguishes from sibling tools that deal with individual certifications, collections, pricing, etc.
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?
Explicitly suggests using it as a first call for introspection. Provides clear context but does not specify when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the description correctly adds that it writes to the local SQLite DB and returns a new card_id. It also mentions error handling for duplicates and normalizes the PSA response. This goes beyond the annotation signals, providing valuable behavioral context.
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 concise, front-loaded with the main purpose, and structured with a clear separation of the workflow nature and error handling. Every sentence adds value without redundancy.
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?
Given the complexity (a workflow tool combining two operations) and existence of an output schema, the description covers the key points: the combination, normalization, DB write, return value, and duplicate handling. It could mention error handling for invalid cert numbers, but overall it is fairly complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having some parameter descriptions (acquisition_price, acquisition_date, acquisition_source), the context signals indicate 0% schema description coverage, so the description should compensate. However, the description only mentions 'cost basis' and does not elaborate on other parameters like notes, tags, or acquisition_source. This leaves the agent to rely on the schema alone, which is insufficient given the low coverage.
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 it looks up a PSA cert and records it in the local collection, distinguishing itself from siblings by explicitly mentioning it combines tcg_psa_get_cert and tcg_collection_add_card. The verb 'look up' and 'record' are specific, and the resource (PSA cert and local collection) is well-defined.
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 provides explicit when-to-use (workflow for adding a PSA cert with cost basis) and when-not-to-use (if already added, returns error and suggests tcg_collection_update instead). It clearly presents an alternative, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, consistent with the description's mention of inserting a row. The description adds behavioral context beyond annotations, such as what data is extracted (SpecID, grade, etc.) and where it is stored (pop_snapshots table). No contradictions.
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 very concise: two sentences that front-load the core action and then provide necessary process details. Every sentence serves a purpose without redundancy.
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?
For a simple tool with one parameter and an output schema, the description is complete. It explains the purpose, the data flow, and how it integrates with the sibling tool tcg_psa_pop_trend, ensuring the agent understands the tool's role.
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?
The input schema provides a description for the single parameter cert_number, so schema coverage is high (100%). The tool description does not add significant new meaning beyond the schema; it only contextualizes the parameter within the overall process.
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 tool's action: 'Capture today's PSA pop data for the spec backing this cert.' It specifies the verb (capture), resource (PSA pop data), and distinguishes from siblings like tcg_psa_get_cert and tcg_psa_pop_trend.
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?
The description explains the usage context: 'Repeat over time and tcg_psa_pop_trend will surface the trajectory.' This implies periodic use and references an alternative tool for analysis. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds detail about provider selection logic (always queries Pokémon TCG API, conditionally queries PriceCharting) that goes beyond annotations (readOnlyHint, etc.). No contradiction.
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?
Very concise; two short paragraphs. First sentence nails purpose, rest explains logic. No filler.
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?
Covers routing behavior well. Output schema exists, so return format need not be explained. Could mention error handling or fallback behavior, but not necessary given annotations.
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 descriptions are already thorough (query format, grade conditions, provider enum). The tool description adds context about the smart‑routing strategy but doesn’t repeat param details.
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 tool does 'smart-routed price lookup' for a single card, combining multiple providers. It is distinct from siblings like tcg_pricing_search (search) and tcg_pricing_get (likely similar but less intelligent).
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?
Describes the routing strategy and when `prefer_provider` can override. Implicitly suggests this is the go‑to for single card pricing, but does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by specifying the exact return values (counts, cost basis) and confirms it is a read-only summary. No contradictions.
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?
Two sentences, no redundant words. Front-loaded with key purpose, then lists returned data, then points to alternative. Every sentence adds value.
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?
The tool is simple, has output schema, and description covers purpose, return values, and sibling distinction. No missing information for an agent to use correctly.
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?
The input schema has one required parameter which is an empty object (no properties). Description does not mention parameters, but there are none to describe. No parameter information is needed beyond the schema.
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 explicitly states the tool provides a cost-basis summary with specific returned data (counts, total cost basis). It clearly distinguishes from the sibling `tcg_collection_value_with_market` by noting that the sibling does live market valuation with pricing snapshots.
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?
The description advises when to use the alternative tool for live market valuation, providing clear context for choosing between tools. It lacks explicit 'when not to use' for this tool, but the alternative mention is sufficient for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, confirming safety. The description adds behavioral detail: it joins collection cards with pricing snapshots, matches grades, and tracks unpriced cards. It also notes dependency on snapshot freshness, which is valuable beyond annotations.
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 three short sentences: purpose, logic, and maintenance advice. It is front-loaded with the core function, avoids redundancy, and every sentence adds value. No wasted words.
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 an empty input schema (no parameters), safety annotations, and an output schema (not shown but present), the description sufficiently explains the tool's behavior, output clues (unpriced_count), and dependency on pricing snapshots. It is complete for a read-only valuation view.
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 defines a single required 'params' object with no properties, meaning the tool takes no user parameters. With zero parameters to describe, the description correctly omits parameter details, and the baseline score of 4 is raised to 5 because no explanation is needed.
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 tool computes 'Cost basis + live market value across the collection,' specifying it looks up the most recent pricing snapshot per card, matching grade. This distinguishes it from sibling tools like tcg_collection_value (likely without market data) and tcg_pricing_snapshot (which captures snapshots).
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?
The description explains that cards without pricing attachments or snapshots are counted in 'unpriced_count,' and advises running tcg_pricing_snapshot periodically to keep data fresh. While it doesn't explicitly name alternatives, it provides clear context on prerequisites and maintenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavior beyond annotations: rate limit respect, deduplication via max_age_hours, per-card failure handling, summary output. No contradictions.
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, focused sentences. First sentence states purpose, second explains key behaviors, third describes return value. No wasted words.
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?
Covers essential aspects: what it does, how it handles failures, and output format. Could mention if there are any safety limits on volume, but sufficient given output schema.
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?
Description reinforces key param (max_age_hours) with usage context. Schema own descriptions are thorough, so added value is moderate but helpful.
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?
Clear verb and resource: 'snapshot every owned card with an attached pricing listing'. Distinguishes from sibling tools that snapshot a single card or attach pricing.
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?
Provides context on when to use (bulk snapshot) and behavior (skips recent snapshots, fails per-card). Could explicitly compare to single-card snapshot alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds critical behavioral context: the tool requires prior snapshot data and returns historical time series, which is beyond the annotations. No contradictions.
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?
Two sentences: first states the core action, second provides a usage example and a prerequisite. Front-loaded, no wasted words.
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 the rich input schema, annotations, and output schema (present), the description covers the tool's purpose, use case, and dependency. It is sufficient for an agent to use correctly.
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?
The description does not mention any parameters (schema description coverage is 0%), but the input schema provides detailed descriptions for all four parameters (spec_id, cert_number, grade, days). Baseline 3 is appropriate as schema compensates.
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 tool returns a time series of pop snapshots for a card spec, uses a specific verb ('Return'), and distinguishes from siblings like tcg_psa_snapshot_pop by noting the prerequisite. The example 'Has PSA 10 pop for this card grown a lot?' adds clarity.
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?
Explicitly tells when to use ('for answering population growth questions') and when not to use ('only works for specs you've snapshotted via tcg_psa_snapshot_pop'), naming the prerequisite sibling tool. No alternative tools listed, but the condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tcg-mcp MCP server](https://glama.ai/mcp/servers/seanlok/tcg-mcp/badges/card.svg)](https://glama.ai/mcp/servers/seanlok/tcg-mcp)

Score Badge

Copy to your README.md:

[![tcg-mcp MCP server](https://glama.ai/mcp/servers/seanlok/tcg-mcp/badges/score.svg)](https://glama.ai/mcp/servers/seanlok/tcg-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seanlok/tcg-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server