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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Score is being calculated. Check back soon.
find_dataFind the right data sourceAInspectDescribe 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, the description carries the full burden. It discloses search scope, return contents (method, URL, price, call instructions), and cost ('Free'). It does not mention side effects, but as a search tool, none are apparent.
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 'Describe the data you need in plain language' and followed by concise behavioral details. Every sentence earns its place without 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 single-parameter discovery tool with no output schema and no annotations, the description covers purpose, process, return content, and cost. It is sufficient for an agent to select and invoke the tool 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% with a description for the task parameter. The description adds value by providing explicit plain-language examples and clarifying that the input is the user's own words, reinforcing the schema's meaning.
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 that the tool searches for data sources/endpoints matching a plain-language description and returns matching endpoints with method, URL, price, and call instructions. This specific verb (searches) and resource (datasets/catalog endpoints) distinguishes it from sibling tools like read_url or request_data.
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 examples of appropriate use (e.g., 'Apple risk factors 2023') and explains the search order (server first, then catalog). However, it does not explicitly state when not to use this tool or name alternatives, though the examples imply a discovery use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
holidaysMarket calendars & settlement datesAInspectIs 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 the full burden of behavioral disclosure. It clearly explains the payment flow: call without x_payment to receive terms, then call again with x_payment to get data. It also describes what each view does, including that 'is_open' explains why a market is closed. While it doesn't mention rate limits or output format, the payment mechanism and view semantics are well disclosed.
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 not bloated; every sentence adds necessary information. The views are listed in a compact semicolon-separated manner, and the payment instructions are concise. It is front-loaded with the main purpose, but the payment callout could be slightly better structured. Overall, it earns its length.
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 (8 parameters, no output schema, no annotations), the description covers the essential behavioral aspects: all view modes, the payment workflow, and a pointer to the free pricing alternative. While it doesn't explicitly describe return formats or error handling, it provides enough context for an agent to select and invoke the tool for most calendar-related queries.
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 covers 100% of parameters, so the baseline is 3. The description adds value beyond the schema by elaborating on the 'view' parameter's semantics (e.g., what 'settle' computes) and explaining the 'x_payment' flow. This goes beyond the schema's terse descriptions, particularly for the view enum and the payment 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?
The description opens with a clear question that defines the tool's core purpose: 'Is a market open on a date, and why not if it isn't.' It then enumerates distinct views (next_session, settle, business_days, year), making it obvious this handles market calendars and settlement dates. This is differentiated from siblings like timezone and weather, which deal with time zones and weather rather than financial calendars.
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 for each view, telling the user exactly when to use 'next_session', 'settle', 'business_days', and 'year'. It also mentions the free `pricing` tool as an alternative for price-related needs, which helps avoid unnecessary paid calls. However, it does not explicitly contrast with other sibling tools, so the guidance is strong but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
icon_searchFind an open-licensed iconAInspectSemantic search across 12,900+ open-licensed icons (Lucide, Heroicons, Tabler, Feather, Simple Icons). Returns matches with the ids you can fetch as render-ready SVG. 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 | Yes | What the icon should depict. | |
| set | No | Restrict to one icon set. | |
| limit | No | Max results. | |
| style | No | Restrict to one style. | |
| 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 nature, the two-step x402 payment process, and that it returns matching ids for fetching SVGs. This is valuable behavioral context beyond the schema. It does not mention rate limits or error behavior, but the payment disclosure is particularly strong.
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 3 sentences and packs essential info: what the tool does, what returns, and the payment flow. It is front-loaded with the core purpose, then covers the important usage nuance. No fluff or repetition.
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 5 parameters (1 required), no annotations, and no output schema, the description covers the core functionality, the return value (ids), and the multi-step payment process. It could mention what happens if no matches, but the description is reasonably complete for the complexity. The alternative 'pricing' tool is noted, which helps context.
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, especially for x_payment: 'Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them...' This clarifies a complex parameter. It also names the icon sets supported, aligning with the 'set' enum, adding context without repeating schema 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 gives a specific verb and resource: 'Semantic search across 12,900+ open-licensed icons' and names the icon sets, making it clear this is an icon finder. This distinguishes it from sibling tools like image_to_text and weather, which serve entirely 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 provides clear guidance on the payment flow (call without x_payment for terms, then call with x_payment) and explicitly mentions the free 'pricing' tool as an alternative for listing prices. It does not explicitly say when NOT to use this tool vs other sibling tools, but the use case is obvious from the icon-specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_to_textOCR or describe an imageAInspectTranscribe 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 burden and discloses the paid nature and exact payment flow (call without x_payment to get terms, sign, call again with x_payment). It also notes that the prompt steers the model. It does not mention rate limits or auth details, but the payment behavior is the most critical behavioral trait and is well covered.
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 main purpose, then payment guidance. Every sentence earns its place with zero 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?
The description covers the core functionality, payment flow, and alternative tool. It doesn't describe the return format or error behavior, but for a straightforward OCR/vision tool, the output is inherently clear from the purpose. No output schema exists, but the description is sufficient for an agent to select and invoke it.
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 value by explaining the x_payment flow (omit to receive terms, include to settle) and clarifies that omitting prompt means straight transcription. This goes beyond the schema's parameter 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 opens with a specific verb-resource pair: 'Transcribe an image to text (OCR) or describe it via a vision model.' This clearly distinguishes it from sibling tools like pdf_extract (PDFs) and read_url (web pages).
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 clear context: use for OCR or vision-based description, and it explicitly points to the free `pricing` tool as an alternative for price discovery. It also explains the two-step payment workflow neatly. However, it doesn't explicitly state when not to use this tool versus other image-related tools (e.g., screenshot_url), so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
newsHeadlines and news searchAInspectNewest 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, the description fully discloses key behaviors: deduped and tiered sources, multi-day archive retention, snapshot freshness, and the required two-step x402 payment process. This goes beyond what the input schema reveals and sets accurate expectations for the agent.
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?
Three dense sentences carry high information density. The main purpose is front-loaded, and every clause serves a purpose (source type, archive mode, curated categories, freshness, payment flow, alternative tool). 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?
Despite 5 parameters and no output schema, the description covers all decision points: how to get the newest headlines, how to search the archive, special category behavior, and the exact paid-call procedure. It also notes the tool is not a live web search, which prevents misuse. Enough for an agent to invoke 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?
Even though schema coverage is 100%, the description adds crucial semantics: 'q' switches to archive search, 'category' with 'ai'/'crypto' returns curated cuts, and 'x_payment' has a multi-call payment protocol. This is added meaning beyond the schema's type/examples.
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 starts with 'Newest headlines from a deduped, tiered direct-feed pile' – a specific verb+resource with clear scope. It distinguishes from sibling tools by stating 'Snapshot of ingested feeds, not a live web search' and references the separate `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?
Explicit guidance is given for when to use keyword search ('Pass q to keyword-search...'), curated categories ('category='ai' or 'crypto' return the high-signal curated cuts'), and the payment flow ('call without x_payment to receive this call's exact terms...'). It also names the `pricing` tool as an alternative for price discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pdf_extractPDF to text or JSONAInspectExtract 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 properly carries the burden. It discloses that parsing happens in-Worker without an upstream service (privacy/latency trait) and fully explains the two-step payment protocol: call without x_payment to receive terms, sign them, then call again to settle. This gives agents a clear model of the tool's non-trivial behavior.
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 concise sentences that front-load the core purpose, then detail formats, processing location, and payment. Every sentence earns its place; there is no fluff or redundancy, making it easy for an agent to quickly extract all relevant information.
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 (payment flow, multiple formats, size limit), the description covers all essential aspects: the input method and constraint, return structure, execution environment, and the payment workflow. It even points to the sibling pricing tool for cost transparency, leaving no critical gaps despite the absence of an output schema.
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?
Although schema coverage is 100%, the description adds meaningful semantics beyond the field descriptions: it spells out the exact output structure for each format value (clean single string vs per-page array plus metadata) and explains the x_payment handshake in detail. This is essential for correct invocation and goes well beyond what the schema states.
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 specifies the tool's function: extracting PDFs by URL (up to 10 MB) and returning text or JSON. It explicitly distinguishes itself from siblings by clearly stating the input method and both output formats, making it unmistakable which tool to use for PDF extraction.
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 establishes clear context: when to use this tool (for PDF extraction via URL) and the payload format. It does not explicitly mention alternatives or exclusion criteria, but the context is straightforward and the sibling name 'read_url' could be confused, yet the PDF-specific scope prevents ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricingPrice listAInspectEvery 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?
No annotations are provided, so the description carries the full burden. It discloses that the data is read live from the route table, that it covers every endpoint, and that the call itself is 'Free'. This is sufficient for a read-only informational tool, though it does not describe response structure beyond price and summary lines.
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 scope, content, and cost information without redundancy. The addition of 'Free' is concise and valuable. Every clause earns its place.
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 tool with no output schema, the description is complete: it explains what the tool does, the scope (every endpoint), the data source (live route table), and the cost (free). There is no missing information that an agent would need 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?
The input schema has zero parameters, so there is nothing to explain. The description adds context about what the tool returns (exact per-call USD price and one-line summary), which is helpful. Baseline for no parameters is 4.
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 that the tool lists every endpoint the server fronts, with exact per-call USD price and a one-line summary. It uses a specific verb ('read live') and resource ('route table'), and is clearly distinct from sibling tools that perform data lookups or actions.
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: to discover endpoint prices before calling them. It mentions it is 'Free' and 'read live from the route table', but does not explicitly state when to use it versus alternatives or provide exclusions. Context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlRead a page as markdownAInspectRender 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?
No annotations are provided, so the description carries the full burden. It discloses the headless browser behavior (JavaScript executed) and the two-step payment flow (call without x_payment to get terms, then call again with signed payload). It does not mention potential failure modes, but the disclosures are significant and well-integrated.
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 compact, front-loaded with the core purpose, then provides usage guidance and payment details. Every sentence earns its place; 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?
Given no annotations and no output schema, the description covers key aspects: what it does (renders JS, returns markdown), when to use it, and the payment mechanism. It does not explain all edge cases or error handling, but for a tool with a clear return type and payment flow, it is sufficiently 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 parameters are already well-documented. The description adds value by explaining the payment protocol's two-step process, which the schema only hints at. It also clarifies the purpose of x_payment in the flow, exceeding what the bare schema provides.
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 ('Render') and resource ('a URL in a real headless browser'), clearly distinguishing the tool from siblings like screenshot_url by focusing on markdown output. The purpose is unambiguous and actionable.
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?
Explicitly tells when to use: 'Use this when fetch() gives you an empty shell or a bot wall.' Also references the sibling 'pricing' tool for payment terms, providing clear context for how this tool fits among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_dataRequest missing dataAInspectThe 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 the transparency burden well. It discloses that requests feed a nightly ingestion queue and are usually available within ~24h, and mentions optional contact for follow-up. It doesn't detail response behavior, but for a request tool this is adequate.
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 compact: a purpose phrase, examples, a time-frame, and a note on contact. Every sentence adds value; no fluff or repetition.
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 is complete enough: it explains the request process, expected timing, and optional contact. It doesn't mention what the immediate response looks like, but that's not critical for this type of tool.
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% with descriptions and examples for all three parameters, so the baseline is 3. The description adds only general context (e.g., 'Include contact if you want to hear back') which is redundant with the schema, and does not add new syntax or nuances.
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 'The suggestion box: ask for data we don't have' – a specific verb and resource. It clearly distinguishes itself from siblings like find_data by focusing on missing data, with concrete examples (pre-2015 filing, uncovered ticker).
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 clearly states when to use this tool: when data is not available (pre-2015 filing, unsupported chain, whole dataset). However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it's more implied than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenshot_urlScreenshot a pageAInspectRender a URL in a headless browser and return a PNG screenshot at the size you ask 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 |
|---|---|---|---|
| url | Yes | Absolute URL to capture. | |
| width | No | Viewport width in px. | |
| height | No | Viewport height in px. | |
| full_page | No | Capture the whole scrollable page, not just the viewport. | |
| 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 transparency burden. It clearly discloses the paid nature, the two-step payment mechanism, and the output format (PNG screenshot via headless browser). While it doesn't discuss error handling or timeout behaviors, the key behavioral traits (cost, render method, output) are 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?
Two tightly structured sentences: the first covers core function, the second covers payment specifics. Every word earns its place, and the critical payment flow is front-loaded after the main purpose. No redundancy or 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?
The tool is simple and the description covers the essential facts: headless browser rendering, PNG output, size configurability, and payment requirements. With no output schema, stating the return type is sufficient. The description doesn't explain error conditions or broader use cases, but for a screenshot tool this is adequate.
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 baseline is 3. The description adds value beyond the schema by explaining the two-step x_payment workflow ('call without x_payment to receive exact terms... sign them... call again'), which helps the agent sequence calls correctly. This supplemental guidance pushes it 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 starts with 'Render a URL in a headless browser and return a PNG screenshot', a specific verb+resource combination that clearly identifies the tool's function. This distinguishes it from siblings like read_url or image_to_text, which serve text extraction rather than visual capture.
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 usage guidance for the payment flow (call without x_payment, sign, then call with x_payment) and points to the `pricing` tool as an alternative for viewing all prices at once. It lacks explicit 'when not to use' caveats but gives clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
timezoneTime, offsets & business hoursAInspectCurrent 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 provided, the description carries the full burden of behavioral disclosure. It transparently explains the paid nature of the tool and the exact sign-then-call flow, plus the data each view returns. It does not mention potential errors, rate limits, or idempotency, but the critical paywall behavior is clearly and usefully disclosed.
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 core function, then organized by view modes, then by payment instructions. Every sentence carries essential information and there is no wasted wording or 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?
Despite having 8 parameters, no annotations, and no output schema, the description covers all major use cases, explicitly explains each view mode, and details the payment flow and pricing alternative. It also clarifies the role of `at`, `time`, and `to` within those views, making the tool sufficiently self-contained for an agent 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 coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema by explaining what `view` values do (e.g., 'convert moves a wall-clock time between two zones') and elaborating the `x_payment` workflow. This raises the score above baseline, though it does not deeply describe every 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?
The description opens with a clear statement of the tool's core function: providing 'current local time, UTC offset and DST state' for an IANA zone. It then explicitly enumerates each view mode ('offset', 'convert', 'business_hours'), making the distinct purposes unmistakable and distinguishing this tool from its time/calendar siblings.
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 per-view guidance: 'offset' answers at an instant, 'convert' moves a wall-clock time between zones, and 'business_hours' checks an instant against local business hours. It also gives a clear two-step payment workflow (call without x_payment to get terms, sign, then call again) and points to the alternative `pricing` tool for listing all prices at once.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weatherWeather now, forecast, or alertsAInspectCurrent 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 usage pattern, the two-step payment settlement, and US coverage limitation for alerts. It does not mention rate limits or auth beyond payment, but the disclosed behavior is substantial and goes beyond the schema.
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 core purpose, followed by view details, and then the payment mechanism. Every sentence adds value with no redundancy or 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?
The description covers the main functionality, views, payment flow, and an alternative tool. No output schema exists, so return format is unspecified, but for a weather tool the response shape is reasonably inferable. The payment flow is complex and explained well.
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 meaningful semantics for the x_payment parameter (explains the payment handshake) and clarifies the view parameter's behavior (forecast series, alerts coverage). This goes beyond the schema's field 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 provides current conditions for a named place or coordinate, and specifies that forecast and alerts views are available. This distinguishes it from sibling tools like news or holidays, making the purpose unmistakable.
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 explains the payment flow (call without x_payment to receive terms, sign, then call again), mentions US-only coverage for alerts, and points to the free pricing tool as an alternative for listing prices. This gives clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
