Get the hour this advertiser holds: the UTC hour, the same hour on their target country's clock, the country itself, and the card that runs in it with its review status. Also reports whether the ad is actually live right now, which needs all three of a held hour, an approved card and a paying subscription. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only' and discloses the condition for the live status (held hour, approved card, paying subscription). This explains the tool's output semantics without hiding side effects, as it is a pure read operation.
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 sentences, front-loaded with the primary purpose and followed by the live-status condition. Every sentence contributes value—no redundant phrasing or filler. It is compact and immediately readable.
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 no-parameter read tool without an output schema, the description fully covers what the agent needs: it lists all returned fields (UTC hour, local hour, country, card, review status) and explains the live status logic. No essential detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. Per calibration, the baseline for 0 parameters is 4. The description doesn't need to add parameter meaning since none exist, and it appropriately focuses on output details.
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 ('Get') and resource (the hour the advertiser holds), and enumerates exactly what is returned: UTC hour, local hour, country, card, review status, and live status. This clearly distinguishes it from siblings like list_free_slots or get_my_stats, which serve different purposes.
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 when to use it: when you need details about the advertiser's held slot. It does not explicitly mention alternatives or exclusions, but the context is clear—this is a read-only query for the current slot. Sibling names suggest different functions, so no ambiguity remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.