OpenWeather data for AI agents: list feeds, sign up, check balance, get a top-up link, fetch data.
Reads the account behind the secret: tier, accepted Terms version, the products it may call, the one balance in credits (granted plus bought, minus spend), the last 30 days of usage per day, product and key, and the 50 latest balance movements. Pass the secret sign_up returned as the secret argument; the data key your client configuration sends cannot read the account and answers 403 wrong_credential. Charges nothing; without a string the platform answers 401 invalid_key.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | No | the account's secret — the string sign_up returned as secret; the client configuration's header holds the data key, which this tool cannot use; when both are present the argument wins |
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, it discloses that the call charges nothing, what happens when secret is omitted (401 invalid_key), and why the data key fails (403 wrong_credential). This gives an agent a realistic picture of 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?
Three dense sentences with no filler; the output list is front-loaded, then required input, then failure modes. Every sentence carries operational value.
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 read tool with a full output schema, the description covers what it returns, how to authenticate, failure modes, and cost. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though the schema covers the secret parameter well, the description adds actionable meaning: the secret must be the one sign_up returned, the data-key header cannot be used, and omitting a string yields a specific 401. This is more than the schema alone 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?
The description names a specific verb and resource: 'Reads the account behind the secret' and enumerates the exact returned data (tier, accepted Terms version, products, balance, usage, movements). This clearly distinguishes it from siblings like list_products or fetch_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?
It gives clear usage context: pass the secret returned by sign_up, not the data key from client configuration, and explicitly warns that the data key yields 403 wrong_credential. It does not name sibling alternatives, but the different purpose is obvious enough that no overlap confusion is likely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches one data response: GET data.openweathermap.org/{product}/{route} with the query parameters you pass, using the data key from your client configuration's Authorization header or the data_key argument — never the secret, which fetches nothing. A successful call is billed the product's price per call; a refused call costs nothing. The result carries the payload with the platform's meta block (licence and attribution) and the response headers x-cost-charged and x-cost-remaining. Every refusal is the platform's error envelope unchanged — a code from https://agents.openweathermap.org/errors.json; 402 payment_required means the balance is spent and a human tops up at its action_url (get_topup_link returns the page).
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | a route from get_product, without the product prefix — e.g. current or timeline/1h | |
| params | No | query parameters, sent as given; the parameters a route requires are in get_product | |
| product | Yes | a product slug from list_products | |
| data_key | No | only when the client cannot send an Authorization header — the data_key.key sign_up returned in this session; when both are present the argument wins |
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses substantial behavior: the auth mechanism and the warning that the secret 'fetches nothing', per-call billing with refused calls free, the exact cost-related response headers (x-cost-charged, x-cost-remaining), and a detailed error-envelope contract with a link to error codes plus 402-specific handling. No contradiction with annotations exists.
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?
All four sentences earn their place: purpose/auth, billing, success response shape, and error handling. The purpose is front-loaded and there is no filler, though the density of the single-block text makes it slightly harder to parse than if broken into bulleted behavioral notes.
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 — auth nuances, billing, error envelopes — the description covers nearly everything an agent needs: how to authenticate, what not to pass, cost behavior, success payload contents (with an output schema present), and the 402 recovery path. Minor gaps remain, such as rate-limit behavior and how the data key enters client configuration.
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 schema already documents all four parameters well, including the precedence rule for data_key and the route/product sources. The description adds only marginal param value: the clarification that the Authorization header uses the data key and the caution that the secret is never a valid value. This keeps it at the baseline of 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 names a specific verb ('Fetches') plus an exact resource ('GET data.openweathermap.org/{product}/{route}'), making the operation unmistakable. It also distinguishes itself from siblings: list_products and get_product supply the inputs, account_status covers account state, and get_topup_link handles payment — leaving fetch_data clearly as the only tool that retrieves actual 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 embeds workflow context by pointing to get_product for routes and parameters and to get_topup_link for the 402 top-up path, so an agent learns how this tool fits into the larger flow. It lacks explicit when-not-to-use exclusions (e.g., 'use account_status instead for balance queries'), but the context is clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one product by slug: its live catalogue entry (price, licence, lifecycle state, the specification address) together with the routes fetch_data can call and the parameters each route requires, taken from the platform's published product record. Needs no key and charges nothing. Use it before fetch_data — the route names come from here; an unknown slug answers with the slugs the catalogue serves.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | a product slug from list_products |
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable context beyond those hints: it requires no key, charges nothing, returns data from the platform's published product record, and behaves informatively on unknown slugs. The only minor gap is not detailing the exact output shape, but the output schema already covers that.
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 sentences, front-loaded with the core return value and followed by cost/authentication and usage guidance. Every sentence adds distinct value with no repetition of annotations or schema details, making it appropriately sized and easy to scan.
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 read-only tool with a rich output schema, this description is complete. It explains the return contents, the relationship to fetch_data, the authentication/cost profile, and the error behavior. An agent has everything needed 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% and the schema already describes the parameter as 'a product slug from list_products.' The description reinforces this by explaining slug-based lookup and adding the unknown-slug behavior, which gives the agent a clearer expectation of what happens with invalid input. This meaningfully extends the schema's bare 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 opens with a specific verb and resource: 'Returns one product by slug' and lists exactly what the returned catalogue entry contains (price, licence, lifecycle state, specification address, callable routes). It also distinguishes itself from fetch_data by positioning get_product as the source for route names, making its role clear relative to 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 gives explicit sequencing guidance: 'Use it before fetch_data — the route names come from here.' It also explains how to recover from an unknown slug by stating that the response returns the slugs the catalogue serves. This is actionable and removes ambiguity about when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a top-up for the account and returns the payment intent with hosted_url, the payment provider's short-lived page where a human completes the payment — no tool pays, and card details never touch the Forum. amount_minor is in cents; the platform accepts USD only and a minimum of 1000 (= $10). Pass the secret sign_up returned as the secret argument; the data key cannot open a payment. Asking again while a page is open returns the same page. Bought credits appear in account_status once the payment completes.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | No | the account's secret — the string sign_up returned as secret; the data key in the client configuration cannot open a payment; when both are present the argument wins | |
| currency | No | USD is the only currency the platform accepts; the platform refuses any other | USD |
| amount_minor | Yes | the amount in the currency's minor unit (cents); the platform's minimum is 1000 = $10 and the platform checks it |
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry readOnly=false, openWorldHint=true, and idempotentHint=true. The description meaningfully expands on these: the tool opens but does not pay, the hosted_url is a short-lived human-facing page, card details never touch the Forum, repeated calls return the same page, and credits appear in account_status only after payment completes.
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 main outcome is front-loaded and the paragraph is dense without being bloated. However, several sentences restate parameter details that already exist in the schema, causing slight redundancy. The behavioral sentences earn their place, but the repetition keeps it just below a top score.
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 explains the full flow: prerequisites (secret), constraints (USD and $10 minimum), idempotent behavior, the fact that no tool pays, and the post-condition of credits appearing in account_status. Since an output schema exists, the return shape does not need to be spelled out here.
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 documents all three parameters at 100% coverage, including cents, the $10 minimum, USD-only acceptance, and the secret's origin. The description largely repeats this parameter-level information rather than adding new meaning beyond the schema, so it stays at 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 states a specific action and result: 'Opens a top-up for the account and returns the payment intent with hosted_url'. It also clarifies that the tool only initiates the payment while a human completes it, which clearly differentiates it from the sibling read and account tools.
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 operational context: use the secret from sign_up, the data key cannot open a payment, repeated calls while a page is open return the same page, and credits later appear in account_status. It does not explicitly name alternative tools, but no sibling competes with this payment-opening purpose, and the secret/data-key distinction provides a useful when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every data product the Forum serves, as the platform's own catalogue answer: slug, title, lifecycle state, price in credits per call (1 credit = $0.001; the quoted price is the charged price), licence and attribution text, and the address of the product's route specification. Needs no key and charges nothing. Call get_product next for a product's routes and required parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful context beyond that: it requires no key, charges nothing, and returns every product rather than a filtered subset. The pricing clarification (credits, conversion, quoted price being charged) is valuable operational context not present in the annotations.
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 and front-loaded with the primary behavior, followed by returned fields, cost and auth context, and a routing hint. Every sentence carries useful information and none is redundant with the schema or annotations.
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 parameterless listing tool with an output schema already present, the description provides everything an agent needs: scope, returned fields, authentication/cost constraints, and the natural next step. There are no significant gaps.
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?
There are zero parameters and the schema is empty, so there is nothing for the description to clarify. The baseline for a parameterless tool is 4; no ambiguity exists here.
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 and resource: 'Lists every data product the Forum serves', and reinforces the scope by calling it the platform's own catalogue answer. It enumerates exactly what fields are returned, and the closing pointer to get_product makes it easy to distinguish from its most relevant sibling.
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 clearly states when to call this tool: to get the full catalogue with no key and no cost. It also gives explicit next-step guidance, 'Call get_product next for a product's routes and required parameters', which orients an agent toward the correct sibling for the follow-up operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Forum account for an email address under the Terms version currently served, and returns the account, its secret — the one string that runs the account, shown exactly once — its first data key, shown exactly once, and the 1,000-credit signup grant spendable on any product. The result's configure block is the client configuration entry that sends the data key from then on; until the client reconnects, pass data_key.key as data_key on fetch_data. Keep the secret with the owner and pass it as secret on account_status and get_topup_link. An address that already has an account answers 409 email_exists with next_action login_to_link.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | the owner's email address — the account's identity; one account per address |
| Name | Required | Description |
|---|---|---|
| body | No | |
| fault | No | |
| usage | No | |
| record | No | |
| status | No | |
| account | No | |
| headers | No | |
| upstream | No | |
| body_text | No | |
| configure | No | |
| transport | No | |
| key_source | No | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical one-time-only behaviors: the secret is shown exactly once, the first data key is shown exactly once, and the 1,000-credit grant is included. It also explains how to use the returned configure block for fetch_data and how to pass secret on account_status and get_topup_link. The 409 error response and next_action are also described.
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 well-structured, with every sentence serving a distinct purpose: what is created, what is returned, how to use the returned artifacts, and what happens on duplicate signup. There is no filler 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?
The description covers the full lifecycle: creation, returned credentials, immediate follow-up usage on fetch_data, account_status, and get_topup_link, plus the duplicate-account error path. Given that an output schema exists, nothing important for an agent to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the email parameter with 100% coverage, including that it is the account identity and one account per address. The description reinforces this and adds context about the 409 behavior, but it does not materially add parameter semantics beyond what the schema already 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 uses a specific verb and resource: 'Creates a Forum account for an email address.' It clearly distinguishes sign_up from its siblings, which all manage or query existing accounts rather than creating them. The behavior is concrete and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use sign_up: to create a new Forum account for an email address. It also provides a clear conditional: existing accounts return 409 email_exists with next_action login_to_link, steering the agent away from re-signing up. However, it does not explicitly state general alternatives like 'use account_status to check an existing account.'
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. Dates show when Glama detected each change.
account_statusfetch_dataget_productget_topup_linklist_productssign_upClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Data feeds for AI agents: list products, sign up, check balance, get a top-up link, fetch data.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
x402-gated weather and FX exchange rate data endpoints for AI agents.
Pay-per-use weather, environment, finance, and on-chain intelligence tools for AI agents via x402.
Add one secure layer between your agents and this server.
Each tool has a single unambiguous role: catalogue browsing, data fetching, account creation, account status, and top-up. Even get_product and list_products are cleanly separated by singular/plural and detail level.
Most tools follow a verb_noun pattern (fetch_data, get_product, get_topup_link, list_products), and all names are lowercase snake_case. account_status and sign_up break the verb_noun pattern, but they are still readable and predictable.
Six tools is a well-scoped set for an API platform server: discovery, data access, account monitoring, and top-up each have dedicated coverage. No tool feels redundant, and the count is appropriate for the server's purpose.
The set covers the full usage loop: sign up, discover products, fetch data, check balance/usage, and top up. Minor gaps exist — sign_up references a login_to_link action that no tool provides, and there is no key rotation or management — but they do not block the primary agent workflow.