Skip to main content
Glama
Sign In
mcp-red-web-utils

mcp-red-web-utils

by hsharmanov02
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

caselaw_fetch

Fetch a UK court judgment by its path to retrieve case law text; pay per call in USDC on Base via x402.

Instructions

Fetch a UK judgment by path (paid per call, USDC on Base via x402)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "caselaw_fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose a genuinely important trait: this call costs money (USDC on Base via x402). That is valuable, non-schema information. It stops short of explaining whether payment is charged on failed lookups, whether a wallet/auth setup is required, or what happens with an invalid path.

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

Conciseness4/5

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

One tightly written sentence with the resource and the payment constraint front-loaded and no filler. It is efficient, though the brevity edges toward under-specification rather than pure conciseness.

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 paid, unannotated, single-parameter tool with no output schema, the description omits the two things an agent most needs: the required path format and what the response contains (full judgment text, metadata, or a reference). Payment is mentioned but not operationalized.

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% for the single required parameter. 'by path' weakly implies a lookup key, but the critical format of that path (case citation style, URL slug, internal identifier) is never specified, leaving the agent to guess an easily-failed input.

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

Purpose4/5

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

States a specific verb and resource: 'Fetch a UK judgment'. The 'UK' qualifier and 'by path' input implicitly separate it from caselaw_search (discovery) and caselaw_us (US jurisdiction), though no sibling is named explicitly.

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

Usage Guidelines3/5

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

The phrase 'by path' hints that this is a retrieval step following a search, and 'paid per call' signals a cost consideration. However, there is no explicit when-to-use guidance, no statement that a path comes from caselaw_search, and no mention of alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools