Skip to main content
Glama
Sign In
Unique Domains MCP server

Unique Domains MCP server

Official
by UniqueDomains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Seven auction venues with their verified rules and today's counts

ud_list_market_auction_venues
Read-onlyIdempotent

Lists seven auction venues with verified rules and today's auction counts, answering how a venue works or how many auctions it runs today. Requires no input.

Instructions

The seven auction venues with their verified rules and today's counts. Use it when someone asks how an auction venue works, or how many auctions it runs today. Takes no input.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ud_list_market_auction_venues"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsNoComma-separated top-level keys to keep: id, label, currency, kinds, closeRule, paymentRule, bidderRule, firstYear, today.

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNoThe day of the answer, and the page cursor of a list.
linksNoLinks of the answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful scope ('seven venues') and freshness ('today's counts') that annotations do not convey. However, the closing claim 'Takes no input' is inaccurate, since the schema exposes an optional fields projection parameter, which a caller could easily misread as unusable.

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 short sentences with the content summary front-loaded and usage stated immediately after. There is no filler. The only wasted line is the final 'Takes no input,' which is both unnecessary and incorrect.

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?

This is a simple, closed-world, read-only listing tool, and an output schema exists, so return values need no explanation. What remains is the scope and freshness of the data, both of which are stated. The one completeness defect is the false claim about input, given the optional fields parameter.

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 100%, so the optional fields parameter and its allowed keys are already fully documented. The description could have stayed silent and scored the baseline 3, but instead it states 'Takes no input,' which actively misrepresents the presence of an optional projection argument and could cause an agent to skip a useful parameter.

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 names the resource precisely: the seven auction venues plus their verified rules and today's counts. That is more specific than the title alone and tells the agent exactly what content comes back. It does not distinguish itself from a sibling like ud_list_venues, which plausibly returns a venue list without rules or daily counts.

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?

Two concrete use cases are given: answering how a venue works, and how many auctions it runs today. That is clear context for selection. There is no when-not guidance and no named alternative for related questions such as venue identity or auction listings.

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

Deploy Server

Other Tools