Scan MTG binder photos. 3 free pages/day then €0.01/page.
Scored across 5 tools
Each tool has a clearly distinct role in the workflow: free key URL retrieval, credit-pack purchase creation, purchase polling, scan starting, and scan-job polling. The descriptions explicitly cross-reference related tools, so the boundary between purchase_credits and get_purchase is clear.
All tools use consistent snake_case verb_noun naming: get_free_key, get_purchase, get_scan_job, purchase_credits, start_scan. The get_* retrieval tools and action-oriented purchase/start tools follow a predictable pattern.
Five tools is well-scoped for a focused scanning-and-payment workflow. Each tool earns its place by covering a distinct step from key acquisition to scan processing.
The core lifecycle is covered: obtain a free key URL, buy or poll credits, start a scan, and poll the job. Minor gaps exist, such as checking account credit balance, listing prior scans, or cancelling a scan, but they do not block the primary workflow.
Returns the URL where a signed-in MTG Trade account creates an API key with 3 free scan pages per day. Never creates a key itself.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does reasonably well: it discloses that the return value is a URL, that key creation happens elsewhere by a signed-in user, and the free-tier quota of 3 scan pages per day. It stops short of saying whether the URL is static or per-user, or whether calling it requires an existing session token, which matters for a tool whose output the agent must hand to a human.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the most important fact (what is returned) leads. The quota detail and the 'never creates a key' caveat each earn their place by preventing a specific misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema utility tool this is close to sufficient: the agent knows the return type (a URL), the account precondition, and the free quota. The remaining gap is authentication state at call time, which the description leaves ambiguous despite emphasizing 'signed-in' accounts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The empty schema is consistent with the description's claim that the tool only returns a URL and takes no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb plus resource: it returns the URL where a signed-in account creates an API key, with the 3-scan-pages-per-day cap stated up front. The closing clause 'Never creates a key itself' rules out the most likely misreading, though no sibling tool is named to sharpen the boundary against start_scan or purchase_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the entry point for obtaining free API access, and the negative clause clarifies what the tool will not do. There is no explicit when-to-use condition versus siblings, no statement of prerequisites (does the caller need to be authenticated already?), and no routing guidance to start_scan once a key exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a credit pack. Returns api_key once when paid.
| Name | Required | Description | Default |
|---|---|---|---|
| purchase_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral-disclosure burden. It usefully states that the tool polls, returns api_key only once, and only after payment, but it does not disclose pending/unpaid behavior, error cases, whether the key is sensitive, or any rate/polling constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and front-loads the core action with no filler. It is appropriately compact, though its brevity contributes to missing operational details rather than being purely efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an undocumented required parameter, the description is too thin. It gives the headline behavior but omits the purchase_id source/format, polling expectations, and handling of unpaid or failed purchases, which an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented purchase_id parameter. It does not explain what purchase_id is, where to obtain it (for example from purchase_credits), or its expected format, leaving the sole required parameter semantically underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: poll a credit pack and return api_key when paid. This distinguishes it from the sibling purchase_credits, which initiates a purchase rather than polling one. It is clear but uses 'credit pack' rather than the parameter's purchase_id terminology, slightly blurring the resource reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after a purchase has been started, since it says to poll and returns api_key once paid. However, it does not explicitly say when to use this versus get_free_key or purchase_credits, nor does it state polling cadence or what to do while unpaid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a scan job until processed or failed. Requires Bearer mgt_….
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the polling loop, the two terminal states, and an authentication requirement, but omits return format, error behavior, and rate-limit or retry guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core polling behavior. The auth note is terse but does not bloat the definition; a slightly clearer phrasing of the token requirement would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter polling tool with no output schema, the description covers the polling semantics and authentication. However, it leaves the caller without information about what a successful poll returns or what job_id refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter 'job_id' is not explained in the description. The text does not clarify that job_id is the identifier returned by start_scan or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'poll' with the resource 'scan job' and states the terminal conditions 'processed or failed'. This clearly separates it from the sibling 'start_scan', though it does not name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The polling instruction implies the tool is used after starting a scan and should be repeated until a terminal state, but it does not explicitly say when to use this versus alternatives or when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a 5€ / 500-credit pack (Mollie checkout, or x402 if PAYMENT-SIGNATURE is sent). Poll get_purchase for the API key.
| Name | Required | Description | Default |
|---|---|---|---|
| redirect_url | No | Mollie redirect after payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full load, and it does disclose price (5€), credit quantity (500), the two payment mechanisms, and that the operation is asynchronous requiring polling. It omits failure/repeat-call behavior — whether a second call charges again, whether the pack expires, or what the caller holds while waiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the price and mechanism, then the follow-up action. No filler, though the parenthetical payment branch is dense enough to require a second read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment-creating, async tool with no output schema and no annotations, the description covers the flow but never states what the call returns (checkout URL, payment id, or nothing). An agent knows what to do next but not what it receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single redirect_url parameter, so the baseline is 3. The description could have added that redirect_url only applies to the Mollie branch and is irrelevant to the x402 flow, but it says nothing about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: creating a 5€ / 500-credit pack, with the two payment rails named. An agent can tell it apart from get_free_key. The only fuzziness is the word 'pack', which is never defined as a purchasable unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear follow-up path ('Poll get_purchase for the API key') and a conditional branch (x402 if PAYMENT-SIGNATURE is sent), which is real usage guidance. It never says when to prefer this over get_free_key, nor what to do if checkout is abandoned or payment fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one binder photo (base64). Requires Authorization: Bearer mgt_…. 3 free pages per day with an account, then €0.01/page. Returns job_id.
| Name | Required | Description | Default |
|---|---|---|---|
| mime | No | image/jpeg | |
| tcg_type | No | mtg | |
| image_base64 | Yes | ||
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does contribute real behavior: auth scheme, daily free quota, per-page pricing, and that it returns job_id. It omits failure modes, whether the image is persisted, max page/upload size, and idempotency behavior for retries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Telegraphic but front-loaded and efficient: upload, auth, pricing, return value, in that order, with no filler. Slightly clipped phrasing ('base64', 'then €0.01/page') trades a little readability for density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so 'Returns job_id' is a useful, necessary disclosure, and pricing/auth context is present. But for a four-parameter job-submission tool it leaves three parameters and the downstream polling step undocumented, which is a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters, and the description explains only image_base64. mime, tcg_type, and idempotency_key get no meaning, defaults, or accepted values from either source, leaving the agent to guess how to control the scan type or safely retry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource: upload one binder photo as base64 to start a scan job, returning job_id. That clearly contrasts with get_scan_job and purchase_credits, though it never names the sibling used to poll results, so the agent must infer the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It signals an account requirement (Bearer mgt_ token, 3 free pages/day, then €0.01/page), which hints at when the tool is usable and points business logic toward get_free_key/purchase_credits. It never explicitly says 'call this first, then poll get_scan_job', so the usage path is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_free_keyget_purchaseget_scan_jobpurchase_creditsstart_scanOrganize and track your Magic: The Gathering collection, decks, prices and imports.
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Download files from URL lists, turn PDFs into Markdown and read text from images. Pay per file.
Search trading card prices, build carts and manage a CardNexus store. You pay on cardnexus.com.
Add one secure layer between your agents and this server.
