Provides web search via DuckDuckGo, returning ranked organic results (no ads) for free-text queries.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-utils-mcp What's the weather in Tokyo?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Eight utilities your agent can call — geocoding, weather, web search, URL-to-Markdown, randomness and compliance lookups — paid per call in USDC on Base via x402, from your own wallet.
This package is not on npm yet. Install it straight from GitHub — this is the command that works today:
npx -y github:donnywin85/agent-utils-mcpThat starts the MCP server on stdio and it will list all eight tools with no wallet and no key. You only need a funded key to actually call one.
Add it to Claude Code — one line, and the tools are live in your next session:
claude mcp add agent-utils --env EVM_PRIVATE_KEY=0xyour_disposable_base_key -- npx -y github:donnywin85/agent-utils-mcpRelated MCP server: 1cent
tool | what it does | price |
| address or place name → coordinates, with ranked candidates | $0.003 |
| coordinates → street address | $0.003 |
| current conditions + up to a 7-day forecast for any coordinates | $0.003 |
| free-text query → ranked organic results (no ads) | $0.003 |
| article or PDF URL → clean Markdown | $0.003 |
| CSPRNG bytes, or uniform integers in a range | $0.003 |
| OFAC SDN / consolidated sanctions screening for a name | $0.01 — see note |
| GLEIF Legal Entity Identifier for a company | $0.03 |
Prices live in one table in src/index.mjs; npm run pricecheck compares it
against the gateway's own /openapi.json and fails on any drift.
Known drift, stated rather than hidden: as of 2026-08-21
npm run pricecheckreports/sanctionsadvertised at $0.03 while the gateway charges $0.01. You are charged the gateway's price, so this errs in your favour — but the table is wrong until that is reconciled, and the check is red on purpose.
The server signs each payment with a key it reads from its own env, which you set in your MCP client's config. Nothing is bundled, and no key is ever sent anywhere except as an EIP-3009 signature to the x402 facilitator.
Fund a wallet with a few dollars of USDC on Base.
It needs zero ETH — payments use transferWithAuthorization and the
facilitator broadcasts and pays the gas.
Use a low-balance, disposable wallet. The key sits in your client config in plaintext; any process that can read that file can spend from it.
Claude Desktop (claude_desktop_config.json), Cursor, or any MCP host:
{
"mcpServers": {
"agent-utils": {
"command": "npx",
"args": ["-y", "github:donnywin85/agent-utils-mcp"],
"env": {
"EVM_PRIVATE_KEY": "0xyour_disposable_base_wallet_key"
}
}
}
}Tools list fine without a key — you can inspect what is on offer before funding anything. The first paid call is where a missing key is reported, in as many words:
/geocode failed: EVM_PRIVATE_KEY is not set. Add it to this MCP server's env in
your client config.Argument names are short: geocode takes q, not query.
Every tool returns the upstream JSON plus, on a successful payment, the settlement transaction hash:
(paid $0.003 USDC — settle tx 0xb2397b96…)That is deliberate: you can verify on Basescan that you were charged once, for what you got, rather than taking the server's word for it.
The first six were not chosen by guesswork. They are the categories that USDC receipts across 1,062 x402 seller wallets showed agents actually pay for — geocoding (56 payers), weather (21), article/PDF→Markdown (7), randomness (6), web search (6).
The upstreams follow two rules worth knowing as a caller:
A missing value is null with a reason, never a plausible-looking number.
Weather reports no reading rather than zero; reverse-geocode says "ocean or
unmapped" rather than inventing an address.
The limits of an answer are stated in the answer. Forecast rows are
labelled model output; search says results are unverified and that its ranking
is DuckDuckGo's; web_search's count is a maximum, not a promise, because a
result whose destination cannot be resolved is dropped rather than guessed at.
url_to_markdown refuses private, loopback, link-local and cloud-metadata
addresses, and re-validates every redirect hop — it fetches caller-supplied URLs
from inside a private network, so that guard is not optional.
You want the same utilities for free, without a wallet — dex-data-mcp
carries geocode, reverse_geocode, get_weather, search, url_to_markdown
and get_random on a keyless free tier, alongside 16 more tools. If you do not
need this server's compliance pair, start there: claude mcp add dex-data -- npx -y dex-data-mcp.
You want cross-DEX market data — arb-dex-mcp
(keyless) or bsc-dex-spread-mcp (paid, one tool).
You want the human-approval loop these services are operated by —
approval-queue-starter, one file, zero deps.
Something is broken, or you want volume pricing — the gateway returns a
contact address on every 402, and a human reads it.
MIT.
Forward geocoding: turn an address or place name into latitude/longitude. Returns ranked candidates with display name, coordinates, bounding box, address components, and an importance score so you can judge ambiguity rather than assume the first hit is right. Data from OpenStreetMap Nominatim. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Address or place name, e.g. "1600 Amphitheatre Parkway, Mountain View". Max 300 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses that the tool returns ranked candidates with multiple fields (display name, coordinates, bounding box, address components, importance score), explains the significance of the importance score for handling ambiguity, names the data source (OpenStreetMap Nominatim), and transparently states the cost and payment mechanism. This is rich behavioral context beyond the basic purpose.
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 tight sentences, each earning its place: purpose, return value/ambiguity handling, data source, and cost. It is front-loaded with the core purpose and contains no redundant or filler content.
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 there is no output schema, the description compensates by enumerating the return fields (candidates, display name, coordinates, bounding box, address components, importance score). It also covers cost, data source, and automatic payment behavior. For a single-parameter tool, this is comprehensive.
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 the parameter (q) with a clear description and example. The tool description adds no additional semantic detail about the parameter itself, so it lands at the baseline of 3 for 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 opens with 'Forward geocoding' and explicitly states 'turn an address or place name into latitude/longitude', which is a specific verb+resource that clearly distinguishes it from the sibling tool 'reverse_geocode'. It leaves no ambiguity about the tool's core function.
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 this is 'Forward geocoding', which implies the use case (address/place name → coordinates) and implicitly contrasts with reverse geocoding. It provides clear context but does not explicitly name alternatives or state when not to use it, so it falls 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.
Legal Entity Identifier (LEI) lookup from the GLEIF golden copy. Search by company NAME, not just by identifier — knowing the LEI already is the hard part. Returns the LEI, registered legal name, previous names, legal form, jurisdiction, legal and headquarters addresses, and the registration record. LAPSED, RETIRED and ANNULLED entities are returned with a lapsed flag rather than hidden, because a filtered record and no record look identical to a caller. Costs $0.03 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Legal entity name, max 200 chars. Include the suffix for a precise match, e.g. "Apple Inc." rather than "Apple". | |
| lei | No | Exact 20-character LEI for a single record. Use instead of q. | |
| limit | No | Maximum name-search results, 1..50. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly discloses that lapsed/retired/annulled entities are returned with a flag instead of hidden (and why), and states the exact cost per call and payment method. This goes beyond basic expectations but does not cover all potential behaviors (e.g., rate limits or error handling), so a 4 is appropriate.
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 adding essential information: purpose, return fields, and edge-case/cost behavior. It is front-loaded and free of filler, though slightly longer than minimal. Every sentence 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?
Given no output schema and no annotations, the description provides a strong overall picture: what it does, what it returns, how edge cases are handled, and the cost. It lacks details on response format (e.g., JSON structure) but that is not required since no output schema exists. The schema covers parameters, and the description covers broader context 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% with detailed parameter descriptions, so the baseline is 3. The description reinforces the purpose of q versus lei ('Search by company NAME, not just by identifier') and the schema provides the rest. It adds some nuance but does not introduce new parameter-level meaning beyond 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 uses a specific verb 'lookup' with a clear resource ('LEI from the GLEIF golden copy') and explicitly states search by company name. This distinguishes it from all sibling tools, none of which relate to LEI or entity lookup.
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 the primary use case (looking up an LEI by company name) and contrasts it with using an identifier, implying the q parameter for name searches. It does not mention alternative tools because none are relevant, but it gives practical guidance on behavior (e.g., lapsed entities included) and costs, which helps the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse geocoding: turn latitude/longitude into a street address with structured components. Returns null with a reason rather than a guess when the point is ocean or unmapped. Data from OpenStreetMap Nominatim. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, -90..90. | |
| lon | Yes | Longitude, -180..180. |
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 null-and-reason behavior for ocean/unmapped points, the OpenStreetMap Nominatim data source, and the cost/payment mechanism, which are important runtime behaviors.
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 behavioral and cost information. No filler or repetition of schema fields.
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 with 2 params, but there is no output schema, so the description should explain the return value more fully. It mentions 'structured components' but doesn't enumerate them, and it doesn't mention potential errors aside from the null case. Still, cost and data source add context beyond the minimum.
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 both lat and lon already described. The description adds no parameter-specific details beyond the schema, so the baseline 3 applies.
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 'turn latitude/longitude into a street address with structured components', using a specific verb and resource. By calling it 'Reverse geocoding', it distinguishes itself from the sibling 'geocode' 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?
It explicitly frames the tool as reverse geocoding, indicating its use case, but does not name alternatives or state when not to use it. The sibling tool 'geocode' implies the forward direction, but no explicit exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OFAC sanctions screening. Checks a person or company against the US Treasury SDN and Consolidated lists — 19,600+ designated parties and 40,000+ names including every alias — and returns the matched record with its sanctions programs, designation remarks and a match score. Word order does not matter, because OFAC stores people as "SURNAME, Given". riskLevel is hit, possible or clear, and "clear" is scoped to the lists named in the response: EU, UK and UN are NOT screened. If the lists cannot be loaded you get an error, never a clear — a screening tool that says "no match" when it has no list is worse than one that is down. Costs $0.03 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Person or company name to screen. Max 200 characters. Word order does not matter. | |
| type | No | Restrict to one designation type. | |
| limit | No | Maximum matches returned, 1..50. Default 10. | |
| minScore | No | Match threshold 0.1..1. Default 0.6; 1.0 is an exact name-token match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: word-order insensitivity due to name format, riskLevel values and 'clear' scoping, error behavior when lists fail to load (never returns a false clear), and the $0.03 USDC cost with payment mechanism. These go beyond simple capability claims and provide essential operational details.
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 covers purpose, scope, output, match behavior, limitations, error semantics, and cost in a compact paragraph. The information is front-loaded and structured 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?
For a paid external screening tool with no output schema, the description covers the essential context: what lists are used, what the response contains (programs, remarks, score), riskLevel interpretations, failure semantics, and pricing. Users can accurately predict tool behavior without further documentation.
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 each parameter is already well-documented. The description adds the 'SURNAME, Given' detail to clarify why word order doesn't matter, which enhances the 'name' parameter, but most parameter semantics come from the schema itself.
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 performs OFAC sanctions screening, specifically checking a person or company against the US Treasury SDN and Consolidated lists. It uses a specific verb ('Checks') and identifies the resource and scope, making it distinct from the unrelated sibling 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?
It provides clear context for when to use the tool (screening persons/companies) and explicitly scopes the 'clear' result to the US lists, noting EU, UK, and UN are not screened. It does not name alternatives, but no sibling handles sanctions screening, so exclusion guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cryptographically secure random values from a CSPRNG: either random bytes (hex and base64url) or uniform integers in an inclusive range. Integers are rejection-sampled, so the distribution is uniform rather than modulo-biased. For randomness nobody else could have seen, generate it yourself — this is for callers that cannot. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Inclusive upper bound for integer mode. Requires min. | |
| min | No | Inclusive lower bound for integer mode. Requires max. | |
| bytes | No | Number of random bytes, 1..1024. Default 32. Ignored when min/max are given. | |
| count | No | How many integers to draw, 1..1000. Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds significant context: the randomness source (CSPRNG), the uniform distribution via rejection sampling (avoiding modulo bias), the cost ($0.003 USDC per call), the network (Base mainnet), and the payment mechanism (EVM_PRIVATE_KEY). This goes well beyond basic schema info, though it doesn't cover error handling or response format.
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 adding value: the first defines outputs, the second explains a statistical property, and the third covers use case and cost. It is front-loaded with the core purpose, contains no filler, and remains under the typical length limits.
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 moderate complexity and lack of output schema, the description covers the key contextual aspects: what it returns (bytes in hex/base64url, integers), how the randomization works, the cost, and the intended usage scenario. It falls short of a 5 because it doesn't precisely define the returned data structure or specify how to choose between hex vs base64url output, but it is sufficient for an agent to operate 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%, so the baseline is 3, but the description adds meaningful semantics by explaining the two operational modes: random bytes (when min/max are absent) and uniform integers (when min/max are provided). It also clarifies that integer generation is rejection-sampled to be uniform, which gives context for interpreting the min/max and count parameters beyond their schema definitions.
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: generating cryptographically secure random bytes (hex/base64url) or uniform integers in an inclusive range. It uses a specific verb ('generate') and resource ('random values'), and the sibling tools are all unrelated (geocoding, search, etc.), making this tool's purpose distinct.
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 usage context: 'For randomness nobody else could have seen, generate it yourself — this is for callers that cannot.' This tells the agent when to use the tool (when local generation isn't possible) and implies an alternative (self-generation). However, it doesn't explicitly enumerate alternative tools or exclusions beyond this contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public article or PDF URL and return clean Markdown, using Firefox reader-mode extraction for HTML and text extraction for PDFs. Returns title, byline, excerpt, word count and a truncation flag. JavaScript is not executed, so client-rendered pages return an explicit not_extractable error rather than an empty page passed off as the article. Private, loopback and cloud-metadata addresses are refused. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http/https URL of an article or PDF. |
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 thoroughly describes what the tool does under the hood (Firefox reader-mode extraction, text extraction for PDFs), what it refuses (private/loopback/cloud-metadata addresses), what it returns (title, byline, excerpt, word count, truncation flag), and the cost/payment mechanism. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and packs in critical information like limitations, error handling, security restrictions, and pricing without any fluff. Every clause earns its place, and the structure flows logically from purpose to behavior to constraints.
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 no output schema and no annotations, the description covers all essential contextual information: input type, extraction method, edge cases (client-rendered pages), security guards, return fields, and cost. For a tool with a single parameter, this is fully self-contained and leaves the agent well-equipped to select and 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 100% description coverage for the single 'url' parameter, stating 'Public http/https URL of an article or PDF.' The description adds some context about address restrictions and extraction behavior, but it doesn't significantly extend the parameter's meaning beyond what the schema already provides. Baseline 3 is appropriate.
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: 'Fetch a public article or PDF URL and return clean Markdown.' It clearly distinguishes from siblings like geocode/weather by focusing on URL-to-Markdown conversion. It also specifies two extraction modes (reader-mode for HTML, text extraction for PDFs), making the intended functionality 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 provides clear context: it's for public articles/PDFs, and explicitly notes that JavaScript is not executed, so client-rendered pages will return an error. It also lists restrictions (private, loopback, cloud-metadata addresses refused). While it doesn't name alternative tools, the sibling set is unrelated, so no additional when-to-use guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weather for any coordinates worldwide: current temperature, feels-like, humidity, precipitation, wind speed, gusts and direction, plus up to a 7-day daily forecast with highs, lows, precipitation totals and probability. Every condition carries both the standard WMO code and plain text. Forecast rows are model output and the response says so. Pair with geocode to go from a place name to coordinates. Data from Open-Meteo. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude, -90..90. | |
| lon | Yes | Longitude, -180..180. | |
| days | No | Forecast days, 1..7. Default 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: discloses data source (Open-Meteo), cost ($0.003 USDC), payment mechanism (EVM_PRIVATE_KEY), output format (WMO code + text), and a model-output caveat. This is thorough behavioral context.
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 dense sentences covering scope, output fields, data caveats, complementary tools, and cost. Every sentence earns its place and the most important info is front-loaded.
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 no output schema, the description enumerates current and forecast fields, return encoding (WMO + text), model output note, and cost. It is self-sufficient for an agent to understand what will be returned and how to 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?
The schema already covers all 3 parameters with descriptions (100% coverage). The description adds context by confirming 'any coordinates worldwide' and 'up to a 7-day daily forecast,' reinforcing the meaning of lat/lon/days without redundancy.
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 what the tool does: 'Weather for any coordinates worldwide' with a detailed list of current conditions and forecast data. It is specific and distinct from sibling tools like geocode and web_search.
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 provides usage context by saying 'Pair with geocode to go from a place name to coordinates,' indicating when this tool is appropriate. It doesn't explicitly exclude alternatives, but no competing weather tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search: a free-text query returns ranked organic results with title, real destination URL, display URL and snippet. Sponsored rows are excluded. Results are not fetched or verified — a listing says nothing about whether the page is correct or still live. Pair with url_to_markdown to read any result. Costs $0.003 USDC per call on Base mainnet (eip155:8453), paid automatically from the wallet in EVM_PRIVATE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search terms. Max 500 characters. | |
| count | No | Maximum results, 1..25. Default 10. A maximum, not a guarantee — rows whose destination cannot be resolved are dropped rather than guessed at. |
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 sponsored rows exclusion, that results are not fetched/verified, and provides cost/payment specifics. It also details the exact fields returned, offering high transparency.
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?
Five concise sentences each earn their place: core function, exclusions, verification caveat, pairing suggestion, and cost. The description is front-loaded with the primary action and contains 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 2-parameter search tool, the description is complete: it explains output fields, limitations (unverified, sponsored excluded), cost, and a workflow. With no output schema, it adequately describes return values and behavioral nuances.
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 does not add parameter-specific semantics beyond what the schema documents for 'q' and 'count'; it focuses on tool behavior and cost instead.
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 free-text query returns ranked organic results with title, real destination URL, display URL and snippet,' clearly defining the tool's function. It distinguishes itself from siblings by focusing on web search and even suggests a complementary tool (url_to_markdown).
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 through the pairing directive 'Pair with url_to_markdown to read any result' and warns that results are unverified, helping set expectations. However, it does not explicitly name alternatives beyond url_to_markdown or state precise 'when not to use' conditions, so it is clear but not exhaustive.
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.
v0.1.0geocodelei_lookupreverse_geocodesanctions_screensecure_randomurl_to_markdownweatherweb_searchEach tool has a clearly distinct purpose: geocoding (forward and reverse), web content extraction, weather, search, random generation, sanctions screening, and LEI lookup. There is no overlap or ambiguity between any pair of tools.
All names are lowercase with underscores, but they follow different grammatical patterns: single verbs (geocode, reverse_geocode), noun phrases (weather, secure_random), object-verb compounds (web_search, sanctions_screen), and transformation descriptions (url_to_markdown). The naming is readable and descriptive but not consistently patterned.
With 8 tools, the server is well-scoped for a general-purpose utility kit. Each tool offers a useful, independent capability without excessive overlap or bloat.
The utility set covers each advertised domain reasonably well: forward and reverse geocoding, HTML/PDF extraction, current and forecast weather, web search, secure randomness, and two specialized lookups. Minor gaps exist (e.g., no pagination for web_search, no historical weather), but no critical dead ends are apparent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
5 pay-per-call SEO tools over MCP. Free discovery, tool calls settle in USDC on Base via x402.
x402-paid Base agent tools (USDC). 5 deterministic tools. No API keys. No NFT pass.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/donnywin85/agent-utils-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
