Read any page or file as clean text, plus live news, weather, market holidays and timezone lookups for agents. Pay-per-call in USDC on Base via x402 — no signup, no API keys.
Scored across 12 tools
Most tools have clearly distinct purposes, but the three news-related tools (news, news_batch, news_poll) could initially be confused by an agent looking for 'latest headlines' before reading their detailed descriptions. Similarly, find_data overlaps slightly with individual data-retrieval tools by acting as a discovery layer rather than a data source itself.
All names use lowercase snake_case, but the pattern is mixed: some are verb_object (find_data, read_url, request_data), some are plain nouns (holidays, news, pricing, weather), and one is object_verb (pdf_extract). The inconsistency is noticeable but the names remain readable and convey their function.
12 tools is a reasonable, well-scoped count for a paid data-access server. Each tool fills a distinct role, and the free utility tools (pricing, find_data, request_data) justify their place alongside the paid data tools.
The surface covers discovery, pricing, payment terms, and a broad set of data-access actions across news, documents, time, weather, and financial calendars. Minor gaps exist—such as no explicit payment-history or account-status tool—but agents can complete the main workflows without dead ends.
Describe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the search order (server datasets first, then catalog) and what the response contains (method, URL, price, call instructions) plus the fact that it is free. It does not mention error handling, rate limits, or authentication, but for a search/discovery tool, this is reasonably transparent and gives the agent a good sense of what to expect.
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 concise: three sentences that front-load examples, state the search behavior, and summarize output. Every sentence earns its place with no filler, and the structure guides the agent from usage examples to process to result format efficiently.
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?
Given a single parameter and no output schema, the description covers the essential context: what to provide, how the search works, and what the response will include. It could mention potential limitations or error cases, but for a tool of this complexity, the description is complete enough for an agent to select and use it correctly. A 5 would require more explicit details on edge cases or failure modes.
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 schema already fully describes the single 'task' parameter with an example. The description adds value by offering multiple plain-language examples ('Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page') and clarifies that the task can be phrased in any way, expanding the parameter's semantics beyond the schema's minimal description.
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 clearly states the tool's function: it searches for data endpoints based on a plain-language description and returns matching endpoints with method, URL, price, and call instructions. The verb 'searches' and 'returns' plus resource scope (server datasets + catalog) distinguishes it from sibling tools that each target a specific data type, so an agent can easily tell when to use it for discovery versus direct retrieval.
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 explains the tool's purpose and search process, implying it should be used when you need to locate an endpoint or data source. However, it does not explicitly state when not to use it or mention alternatives like the specific sibling tools. The guidance is clear enough for an agent to infer usage, but it lacks explicit exclusions or contrast with alternatives, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a market open on a date, and why not if it isn't. view='next_session' finds the next open day; view='settle' computes a T+N settlement date skipping weekends and holidays; view='business_days' counts open sessions in a range; view='year' lists a calendar's whole year. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Range end (view='business_days'). | |
| date | No | Reference date (YYYY-MM-DD). | |
| days | No | N in T+N (view='settle'). | |
| from | No | Range start (view='business_days'). | |
| view | No | Which calendar question to answer. | is_open |
| year | No | Calendar year (view='year'). | |
| market | No | Which calendar to use. | nyse |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It transparently explains the two-step payment requirement and details what each view computes, including 'skipping weekends and holidays' for settle. It does not cover return formats or error handling, but the key behavioral traits are clearly stated.
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 front-loaded with the primary purpose, then condenses view behaviors into a single semicolon-separated sentence, followed by the payment flow and a pointer to a free sibling. Every sentence contributes unique information with no redundancy, making it both concise and well-structured.
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 8 parameters and a payment gate, the description covers all views, the payment two-step, and the free alternative. While no output schema exists, an agent receives sufficient guidance to select the correct view and invoke the tool correctly, including how to handle the paid flow.
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%, setting baseline 3. The description adds relational semantics by connecting parameters to views (e.g., `days` as N in T+N for settle, from/to for business_days, year for year, date for is_open). This integration goes beyond the static schema descriptions, which already partially reference views, by clarifying how the parameters interact and what the view outputs mean.
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 opens with 'Is a market open on a date, and why not if it isn't,' clearly stating the tool's core purpose. It then enumerates the four views (next_session, settle, business_days, year) with specific outputs, making it distinct from siblings like `pricing` which is explicitly called out as the pricing tool.
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 explicitly points users to the `pricing` tool for price listings ('The free `pricing` tool lists every price at once'), providing a direct alternative. It also gives a step-by-step payment workflow (call without x_payment, sign terms, call again with x_payment), telling the agent exactly how to proceed for paid access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe an image to text (OCR) or describe it via a vision model — steerable with your own prompt. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the image. | |
| prompt | No | What to do with it; omit for a straight transcription. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. | |
| max_tokens | No | Output cap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the critical paid, two-step payment behavior ('call without x_payment to receive this call's exact terms... then call again with x_payment') and notes that the `pricing` tool is free. It does not mention output format or failure modes, but the main cost behavior is transparent.
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 three sentences, front-loaded with the primary purpose, followed by the payment workflow and a pointer to the pricing tool. Every sentence adds essential context, and there is no redundant repetition of schema details.
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?
This is a complex tool with a dual OCR/vision behavior and a payment mechanism. The description explains both behaviors and the full payment workflow, and it points to the pricing tool for exact costs. However, it does not explicitly state the return format (e.g., plain text string) or error handling, leaving a minor gap.
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 already provides 100% parameter coverage with detailed descriptions (e.g., x_payment explains the exact two-step flow). The tool description adds little beyond what the schema states, mostly rehashing the x_payment behavior. Baseline 3 is appropriate given the high schema coverage.
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 clearly states the tool's function with specific verbs: 'Transcribe an image to text (OCR) or describe it via a vision model'. It also indicates steerability with a custom prompt, and this function is unique among the siblings (no other OCR/image description tool).
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 provides explicit guidance on the payment workflow: call without x_payment to receive terms, then call again with x_payment to settle. It also directs users to the free `pricing` tool for price lists, offering a clear alternative for pricing inquiries. It does not explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Newest headlines from a deduped, tiered direct-feed pile (official press, wires and majors). Pass q to keyword-search the retained multi-day archive instead; category='ai' or 'crypto' return the high-signal curated cuts. Snapshot of ingested feeds, not a live web search. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keyword query — switches to archive search. | |
| limit | No | Max headlines. | |
| since | No | Only items after this instant (ai/crypto cuts). | |
| category | No | Headline category; 'ai' and 'crypto' are curated high-signal cuts. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the data source nature (deduped, tiered direct-feed), that it's a snapshot not live search, and the complete paid invocation flow (call without x_payment to get terms, sign, then call again). This goes beyond typical descriptions by explaining an unusual two-step payment mechanism.
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 dense but each sentence adds essential information. It is front-loaded with the primary purpose, then shifts to mode variations, then payment. While it is more than two sentences, every clause serves a purpose. Slightly run-on in spots, but overall efficient and well-structured.
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?
The tool has moderate complexity (5 params, payment flow, multiple modes) and no output schema. The description covers the main usage patterns, payment terms retrieval, and caveats. However, it does not specify the exact structure of returned headlines (e.g., fields like title, URL, date), which would be useful given there is no output schema. Still, it answers most practical invocation questions.
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%, providing a baseline of 3. The description adds meaningful context beyond the schema by explaining how parameters interact: q switches to archive search, category='ai'/'crypto' are curated cuts, and x_payment requires a specific handshake. This helps the agent understand the parameter interplay, justifying a score above baseline.
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 clearly states it provides 'Newest headlines from a deduped, tiered direct-feed pile' and explains the alternative archive search via q. It also distinguishes itself from a 'live web search,' clarifying its scope. This is a specific verb+resource with clear differentiation from potential siblings like read_url.
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 explicitly guides when to use each mode: 'Pass q to keyword-search the retained multi-day archive instead' and highlights special curated categories ('ai' or 'crypto'). It also details the payment workflow and points to the 'free `pricing` tool' as an alternative for price lists, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to 10 headlines / ai / crypto / search reads behind ONE payment (POST /news/batch). Each request names a route and carries that route's own parameters — including since with a cursor, so one batch can advance several polls at once. data.results[i] is exactly the single-route answer for requests[i], in order, each with its own next_cursor to store per feed. Every element is validated before any payment is asked for. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| requests | Yes | 1 to 10 reads, answered in order. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses the two-step payment flow (call without x_payment to get terms, sign, then call again), validation before payment, the ordered mapping of results to requests, and cursor semantics (store next_cursor per feed). It leaves no behavioral ambiguity.
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 dense but every sentence earns its place: it front-loads the core value ('Up to 10 ... behind ONE payment'), then efficiently covers mapping, cursor behavior, validation, and payment. No fluff or repetition, and the structure flows logically.
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?
Given the tool's complexity (batching, payment, cursors) and lack of output schema, the description covers all essential aspects: request mapping, response cursors, payment negotiation, validation, and a pointer to the pricing tool. An agent can call it correctly without further inference.
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%, but the description adds substantial meaning beyond schema: it explains that data.results[i] corresponds to requests[i], clarifies the cursor usage for 'since', and details the x_payment parameter's role in the paid flow. This goes far beyond the schema's baseline descriptions.
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 clearly states the tool batches up to 10 news reads (headlines/ai/crypto/search) behind one payment, distinguishing it from single-read siblings like 'news' and 'news_poll'. The verb 'batch' and explicit resource scope make its purpose unambiguous.
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 for multiple reads ('several news reads in one paid call') and mentions the free 'pricing' tool as an alternative for price lists, but it does not explicitly name alternatives like 'news' for single reads or state when not to use the batch tool. It provides clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The polling loop for a news-watching agent. First call: omit since — you get the current page plus a next_cursor. Every later call: pass that next_cursor as since and receive ONLY articles ingested after it, oldest first, plus the next cursor to store. Follow the whole pile (optionally one category) or a curated high-signal topic tape (ai, crypto). The pile refreshes every 15 minutes (suggested_interval_seconds); dedupe by article id, and by cluster_id to keep one record per story. A poll with nothing new is still a complete answer (new_count 0, cursor unchanged). Full loop + a paying Node poller: /skills/news.md. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most articles to return. If new_count exceeds it, call again at once with next_cursor to drain the rest. | |
| since | No | Omit on your FIRST call. After that pass the `next_cursor` from your previous answer (an opaque nc1.… token — store it, never parse it) and only articles ingested after it come back, oldest first, never a repeat or a gap. An ISO date-time also works to start from an instant. | |
| topic | No | Optional: follow a curated high-signal tape instead of the whole pile (marketing, how-tos and chatter filtered out). Not combinable with `category`. | |
| category | No | Optional: follow one category of the whole pile. Not combinable with `topic`. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and meets it thoroughly. It discloses the cursor advancement contract, oldest-first ordering, empty-poll behavior, 15-minute refresh cadence, dedupe rules by `id` and `cluster_id`, and the exact paid-call negotiation flow. Nothing about the tool's behavior is hidden.
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 dense but every sentence earns its place. It front-loads the core loop contract, then filters, cadence, dedupe, and payment details. The reference to `/skills/news.md` is a small bonus, not padding.
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?
This is a stateful, payment-gated polling tool with no output schema, yet the description supplies everything needed to call it correctly across repeated invocations. It covers edge cases like 'nothing new still returns a complete answer' and specifies the exact cursor/payment semantics that would otherwise be opaque.
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 100%, so the schema already documents every parameter. The description still adds meaningful semantics beyond the schema: `since` must be omitted on the first call, `next_cursor` is an opaque token to store and never parse, and `x_payment` requires a sign-then-call sequence. This pushes it above the baseline 3.
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 clearly names the polling loop as a distinct resource and specifies an exact cursor-based protocol, which is far more informative than a generic 'poll news' statement. However, it never explicitly names `news` or `news_batch` as the one-shot alternatives, so sibling differentiation is implied rather than stated.
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 gives an explicit decision tree: first call omits `since`, every later call passes `next_cursor`; the agent may follow the whole pile, one `category`, or a `topic` tape; and the payment flow is spelled out as a two-step dance. It even points to the `pricing` tool as the alternative for listing prices at once.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract any PDF up to 10 MB by URL. format='text' returns one clean plain-text string; format='json' returns a per-page text array plus document metadata. Parsed in-Worker, no upstream service. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the PDF. | |
| format | No | Flat text, or per-page JSON with metadata. | text |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that parsing happens in-Worker with no upstream service, describes exactly what each format returns, and explains the payment behavior including the required x_payment payload and the pricing tool shortcut. This is exceptionally transparent.
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 three sentences, each earning its place: the purpose and size limit, the format behaviors, and the payment workflow. It is front-loaded with the core action and not a single redundant word.
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?
Given no output schema, the description fully covers return values for both formats. It also addresses the payment flow, size limitation, and processing location, making it complete for a tool of this complexity (3 params, payment gate).
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 schema already covers 100% of parameters, so baseline is 3. The description adds meaningful semantics for 'format' by specifying that text returns 'one clean plain-text string' and json returns 'per-page text array plus document metadata.' It also clarifies the x_payment usage context. This exceeds the baseline.
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 opens with 'Extract any PDF up to 10 MB by URL,' a specific verb+resource statement that clearly differentiates this from sibling tools like image_to_text or read_url. It also explains the two format options, making the tool's purpose unambiguous.
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 gives clear context by specifying the file size limit and the exact two-step payment workflow (call without x_payment, then sign and call again). While it doesn't explicitly say 'use this instead of X,' the tool's purpose and the mention of the 'pricing' tool provide adequate usage guidance. Missing explicit alternatives, hence 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every endpoint this server fronts, with its exact per-call USD price (x402, USDC on Base) and a one-line summary, read live from the route table. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and states it reads live from the route table, indicating a read-only operation. It also discloses the 'Free' aspect. It does not mention auth or rate limits, which are likely irrelevant for a simple introspection tool.
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 entire description is one sentence that packs in the core function, source, and cost. Every word adds value with no redundancy.
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 no-parameter tool, the description conveys what is returned (endpoints, prices, summaries) and the source (live route table). It could specify the output format, but that is easily inferred.
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 has zero parameters, so the schema is fully covered by default. The description adds no parameter details because none exist, warranting the baseline score of 4 for no-parameter tools.
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 clearly states the tool lists every endpoint with its exact per-call price and a one-line summary, read live from the route table. This is a specific, unambiguous purpose and distinguishes it from sibling tools like coverage or fx_rate.
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 usage for discovering costs before calling other endpoints by emphasizing 'exact per-call USD price' and 'Free.' It provides clear context about what the tool does, though it does not explicitly name 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.
Render a URL in a real headless browser (JavaScript executed) and return clean, LLM-ready markdown. Use this when fetch() gives you an empty shell or a bot wall. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to read. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full disclosure burden. It explains that JavaScript is executed in a headless browser, that the output is markdown, and it details the payment flow (call without x_payment to get terms, sign, then call again). This is substantial behavioral context, though it omits potential edge cases like error handling or rate limits.
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 only three sentences, each earning its place. The core functionality is first, followed by a use case, then the payment mechanism. No filler or redundancy.
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 two-parameter tool with a straightforward read operation, the description is largely complete. It explains the payment workflow, which is the main complexity. It does not detail return value beyond 'markdown', but no output schema exists, so a brief format note would help; still, the essentials are covered.
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% (both parameters are described in the schema). The description reinforces the purpose of x_payment but does not add new meaning beyond what the schema already states. Baseline of 3 is appropriate when the schema fully documents parameters.
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 clearly states the tool's function: 'Render a URL in a real headless browser' and 'return clean, LLM-ready markdown'. This specific verb and output format distinguish it from siblings like screenshot_url (captures an image) and request_data (likely simpler fetching).
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 gives a concrete when-to-use: 'Use this when fetch() gives you an empty shell or a bot wall'. It also points to the pricing tool for alternative cost info. However, it does not explicitly state when not to use this tool (e.g., if a simple fetch is sufficient), so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The suggestion box: ask for data we don't have (a pre-2015 filing, an uncovered ticker, an unsupported chain, a whole dataset). Requests feed the nightly ingestion queue — filings are usually available within ~24h. Include contact if you want to hear back. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Optional: URL/email/handle for follow-up | |
| use_case | No | Optional: what you're building | |
| description | Yes | What data you need, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the nightly ingestion queue, ~24h turnaround, the need for optional contact, and that the service is free. It does not mention potential limitations or success criteria, but the behavior is reasonably transparent for a request tool.
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 sentences, front-loaded with the core purpose, followed by concrete examples and behavioral notes. Every clause earns its place; no fluff.
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 request tool with no output schema, the description covers the workflow, timing, and cost. It could mention how to track request status or what happens if a request is rejected, but it is largely complete given the tool's simplicity.
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%, so the baseline is 3. The description adds context around the 'description' parameter (examples of what to ask for) and 'contact' (optional follow-up), but it does not substantially extend what the schema already provides. It reinforces rather than enriches.
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 clearly identifies the tool as a request mechanism for missing data, with specific examples (pre-2015 filing, uncovered ticker, unsupported chain) that distinguish it from sibling retrieval tools. The verb 'ask for' and resource 'data we don't have' make the purpose unambiguous.
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 conveys when to use it (when data is missing from existing coverage) and gives concrete examples, but it doesn't explicitly reference sibling tools or state 'use this if find_data/coverage fails.' The implied guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current local time, UTC offset and DST state for an IANA zone. view='offset' answers at a specific instant; view='convert' moves a wall-clock time between two zones; view='business_hours' says whether an instant is inside local business hours. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Instant for offset/business_hours. | |
| to | No | Target zone (view='convert'). | |
| open | No | Business day start hour. | |
| time | No | Wall-clock time to convert, no offset (view='convert'). | |
| view | No | Which time question to answer. | now |
| zone | Yes | IANA zone. | |
| close | No | Business day end hour. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior. It explains the paid nature: 'call without x_payment to receive this call's exact terms ... then call again with x_payment.' It also reveals that the free `pricing` tool lists all prices, which is useful behavioral context. The description warns that a call without payment returns terms, not data, making the workflow transparent.
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 about 90 words and front-loaded with the primary purpose. It efficiently explains the views and the payment model without unnecessary filler. It is a bit dense, but every sentence contributes meaningful information. A slight grouping of the payment details could improve scannability, but it's well-structured.
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?
The tool has 8 parameters, no output schema, and a paid workflow. The description covers the main views, the payment flow, and directs users to the `pricing` tool. It doesn't explicitly state the return format for each view, but enough is implied (e.g., 'offset' returns the offset, 'convert' returns the converted time). For the default 'now' view, it says 'current local time', which is sufficient. Given the complexity, this is fairly complete.
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%, so the baseline is 3. The description adds semantic meaning by connecting parameters to views: 'at' for offset/business_hours, 'time' and 'to' for convert, and 'open'/'close' for business hours. It also clarifies the x_payment workflow, which the schema describes but the description reinforces. This exceeds baseline.
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 opens with a clear statement of what the tool does: 'Current local time, UTC offset and DST state for an IANA zone.' It then enumerates the distinct views ('offset', 'convert', 'business_hours'), each with a specific behavior, which distinguishes it from sibling tools like weather or holidays. The verb 'answers', 'moves', and 'says' are specific and action-oriented.
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?
Although no alternative tools are explicitly named, the description makes the usage context clear: use 'offset' for a specific instant, 'convert' to move wall-clock time between zones, and 'business_hours' to check if an instant is within business hours. The default view 'now' is implied. This provides clear context but doesn't explicitly state when not to use the tool or point to alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current conditions for a named place or coordinate. view='forecast' returns the hourly series; view='alerts' returns active severe-weather alerts (US coverage). Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (with lon). | |
| lon | No | Longitude (with lat). | |
| view | No | Which weather read to perform. | current |
| hours | No | Forecast horizon in hours. | |
| place | No | Place name — resolved via the built-in gazetteer. Use this or lat+lon. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the paid x402 payment flow, the US coverage limitation for alerts, and that forecast returns an hourly series. This is significant behavioral context, though it omits details like error handling or units.
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 four sentences, each earning its place. It front-loads the core purpose, then provides necessary detail on views and the payment process, with no fluff.
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 output schema and no annotations, the description covers the main behaviors, payment workflow, and coverage limits. It lacks mention of error cases or units, but overall it is sufficiently complete for an AI agent to use 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the x_payment flow (omit to get terms, then call again) and clarifying the view options. It does not elaborate on lat/lon or hours, but those are already well-described in the schema.
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 clearly states the tool provides current conditions for a named place or coordinate, and distinguishes its forecast and alerts views. It also differentiates from the sibling `pricing` tool by noting it is free and lists all prices.
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 gives clear context on when to use the paid feature vs the free `pricing` tool, and explains the two-step payment flow. However, it does not explicitly state when to use weather over other data-related siblings, so not a 5.
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.
icon_searchnews_batchnews_pollscreenshot_urlfind_dataholidaysicon_searchimage_to_textnewspdf_extractpricingread_urlrequest_datascreenshot_urltimezoneweather
Add one secure layer between your agents and this server.