Skip to main content
Glama

pageaudit__demand

Web page intelligence for agents: page audit, SEO metadata, URL liveness preflight, batch x402 endpoint vetting, change monitoring, x402 seller search, and real 30-day paid-usage demand data for the x402 market. Price: $0.01 per call in USDC on Base (eip155:8453), paid with x402 in params._meta["x402/payment"]. HTTP: GET https://api.firstmention.uk/s/pageaudit/demand

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pageaudit__demand"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • removedInput schema / properties / format
      Removed value: -{
      -  "enum": [
      -    "json",
      -    "csv",
      -    "jsonl"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / limit
      Removed value: -{
      -  "type": "integer"
      -}
    • removedInput schema / properties / min_calls
      Removed value: -{
      -  "description": "only endpoints with at least this many calls in 30d",
      -  "type": "integer"
      -}
    • removedInput schema / properties / min_payers
      Removed value: -{
      -  "description": "only endpoints with at least this many distinct payers in 30d",
      -  "type": "integer"
      -}
    • removedInput schema / properties / network
      Removed value: -{
      -  "description": "e.g. 8453 for Base, or solana",
      -  "type": "string"
      -}
    • removedInput schema / properties / offset
      Removed value: -{
      -  "type": "integer"
      -}
    • removedInput schema / properties / q
      Removed value: -{
      -  "description": "keyword over service/url/description/tags",
      -  "type": "string"
      -}
    • removedInput schema / properties / sort
      Removed value: -{
      -  "enum": [
      -    "calls",
      -    "payers",
      -    "recent",
      -    "price"
      -  ],
      -  "type": "string"
      -}
    • addedInput schema / properties / url
      Added value: +{
      +  "type": "string"
      +}
  2. Added

TDQS

C2.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description does carry real behavioral weight: it discloses the cost ($0.01 per call in USDC on Base, eip155:8453), the payment mechanism (x402 payment object in params._meta['x402/payment']), and the HTTP method and endpoint. However, it says nothing about the shape or scope of returned results, failure modes when payment is missing, or what 'demand data' contains, and the bundled capability list actively muddies what this endpoint does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The substance is one long comma-chained sentence enumerating unrelated capabilities, followed by pricing and transport details. The single fact relevant to this tool is buried at the end, and most of the enumeration is waste for an agent selecting this endpoint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter paid endpoint with no annotations and no output schema, the description should explain what demand data is returned and how url scopes it. It covers payment/transport adequately but leaves the actual function and the lone parameter unexplained.

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% and the single parameter 'url' is never mentioned in the description, so the agent gets no signal about whether url is required, what it points to, or how it relates to fetching demand data. The x402 payment lives in params._meta but the description does not tie that to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a product-wide menu ('page audit, SEO metadata, URL liveness preflight, batch x402 endpoint vetting, change monitoring, x402 seller search, and real 30-day paid-usage demand data') rather than a statement of what this specific tool does. Only the final clause about '30-day paid-usage demand data' plausibly maps to the name 'demand', leaving the agent to guess which of seven listed capabilities it actually invokes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given, and no alternative is named. Siblings such as pageaudit__trends, pageaudit__sellersearch, and pageaudit__newsellers also appear to concern x402 market data, but the description offers nothing to distinguish this tool from them.

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.

Resources