Skip to main content
Glama

KlickyMart

check_domain

Can my agent shop here? Verdict for one domain from the index (reachable, checkout-blocked, agents-not-welcome, blocked-tos, error, not-in-index; see verdict_reason and primary_reason), with checkout depth, pay methods, BTC grade, record time and evidence URL. Never triggers a live crawl.

Input Schema

NameRequiredDescriptionDefault
zipNo5-digit US ZIP: adds landed-cost estimate (tax estimate by state, shipping signals)
domainYesHostname, e.g. example.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that the result comes from an index, that it never triggers a live crawl, and which verdict classes may be returned. It does not cover permissions, rate limits, or failure behavior beyond the 'error' verdict, but the key behavioral constraint is stated.

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 front-loaded with the user-facing question and is appropriately sized for the amount of information conveyed. The long parenthetical list is dense but functional; slightly more structural separation would improve readability.

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?

There is no output schema, so the description needs to explain return content, and it does: verdict states, checkout depth, pay methods, BTC grade, record time, evidence URL, and reason fields. It is complete enough for an agent to understand what it will get back, though not exhaustive about field formats.

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 coverage is 100%, so both the required domain and optional zip are fully documented in the input schema. The description adds only that the lookup is for 'one domain' and does not mention the ZIP landed-cost behavior, so it meets the baseline rather than extending parameter meaning.

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 a specific lookup: a verdict for one domain from the index. It enumerates verdict states and returned fields, making the resource and scope clear. It does not explicitly name the sibling alternative such as recheck_domain, so it stops short of a 5.

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 question 'Can my agent shop here?' and 'from the index' imply the usage context, and 'Never triggers a live crawl' hints that this is a cached lookup. However, it does not explicitly say when to use this versus recheck_domain or other siblings, nor does it state exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.