URL Check ($0.001 USDC)
check_urlRead-only
Check one public URL's reachability, HTTP status, latency, redirects, and content type before using it.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| expectedStatus | No |
Anyway Possible Paid Agent Utilities
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds what data points are checked (reachability, HTTP status, latency, redirects, content type) but doesn't disclose potential network-access nuances, timeouts, or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence that front-loads the action, lists the checks performed, and states the recommended usage context. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only URL check, the description covers the core purpose and output dimensions. However, the unaddressed expectedStatus parameter and the absence of any return-format guidance leave clear gaps, especially since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The url parameter is adequately implied by 'public URL', but the expectedStatus parameter is not mentioned or explained anywhere in the description or schema. An agent cannot infer how expectedStatus affects the check behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action — 'Check one public URL's reachability, HTTP status, latency, redirects, and content type' — tied to a concrete resource. The word 'one' clearly distinguishes this tool from the sibling batch_check_urls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before using it' gives clear usage context: validate a URL before relying on it. The singular 'one public URL' implies this is for single-URL checks rather than the batch sibling, though it doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
B3.2/5.0
Disambiguation2/5
Several tool pairs have heavily overlapping purposes: check_url vs verify_web_evidence vs batch_check_urls all verify public URLs, while merchant_snapshot vs merchant_audit and payment_guard vs treasury_preflight cover very similar ground. The descriptions clarify some differences, but an agent could easily select the wrong tool when names alone are ambiguous.
Naming Consistency3/5
All names use snake_case and are readable, but there is no consistent structural pattern. Some start with verbs (check_url, verify_web_evidence), while others are noun compounds (merchant_audit, payment_guard), and batch_check_urls places the verb in the middle. The naming is understandable but not predictable across the set.
Tool Count4/5
At 8 tools, the count is reasonable and within the ideal range for a focused utility server. However, a few tools are near-duplicates of others, so the set feels slightly less well-scoped than the count alone suggests.
Completeness4/5
For the apparent niche of web3 payment preflight, merchant evaluation, and URL verification, the surface covers the core workflows well. The main gap is the lack of a more granular transaction-history or payment-execution tool, but agents can likely complete their intended tasks without dead ends.