CryptoPulse Data API

halal_place

[$0.002 USDC per call via x402] Full record for one halal place by id (as returned by /api/halal/near): phone, website, opening hours, address and OpenStreetMap link.

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": {
      "id": "<id>",
      "lat": "<lat>",
      "lng": "<lng>"
    },
    "name": "halal_place"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Place id from /api/halal/near, e.g. n123 or w456
`lat`	Yes	Latitude of the place (from the search result)
`lng`	Yes	Longitude of the place (from the search result)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the paid-access model ('$0.002 USDC per call via x402'), which an agent must know before calling, but says nothing about failure modes for an invalid id, why lat/lng are mandatory for an id-based lookup, or whether the call is rate-limited.

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?

A single dense sentence with the cost note front-loaded in brackets and the returned fields enumerated at the end. Nothing is redundant, though the price tag and the record description compete slightly for the opening position.

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

Completeness4/5

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

With no output schema, the description compensates by enumerating the returned fields (phone, website, hours, address, OSM link), which is the key missing piece. The remaining gap is error/invalid-id behavior for a paid call, which is minor but not trivial given the per-call charge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the id, lat and lng parameters are already documented at a baseline level and the description only restates that the id originates from /api/halal/near. It adds no explanation for why coordinates are required alongside an id, which is the one genuinely non-obvious parameter relationship.

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+resource: 'Full record for one halal place by id', and differentiates itself from the list/search endpoint by noting the id comes from /api/halal/near. It does not name the sibling tool halal_near directly, but the routing intent is still clear.

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?

Usage is only implied: the id '(as returned by /api/halal/near)' suggests calling this after a nearby search to expand one result. There is no explicit when-to-use/when-not-to-use statement or named alternative among siblings (halal_near, halal_city).

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

All CryptoPulse Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?