Skip to main content
Glama
Sign In

Novarithm Agent Hub: trust and commerce checks

by com.novarithm.www
OverviewDiscussionsAdmin

availability_intersection

[PAID $0.004 USDC/call, x402, eip155:8453] Intersect supplied availability for 1-100 participants, up to 1000 total intervals. Explicit offsets and at most microsecond precision; optional IANA zone is an assertion that supplied offsets match that zone, not a display-zone setting. Return continuous UTC windows for the declared duration. No calendar access, hold, invitation or booking. EOA EIP-712 payments only; ERC-1271/6492 unsupported. MCP body max 64 KiB. Experimental price; input facts are not authenticated.

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": {
      "duration_seconds": "<duration_seconds>",
      "participants": "<participants>"
    },
    "name": "availability_intersection"
  }
}

Input Schema

NameRequiredDescriptionDefault
windowNo
participantsYes
duration_secondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so unusually well: it discloses the x402 pay-per-call price and chain, the accepted payment mechanism (EOA EIP-712 only, ERC-1271/6492 unsupported), the 64 KiB body cap, that inputs are not authenticated/trusted, and that it performs no side effects (no holds or bookings). These are exactly the constraints that would cause silent failures if omitted.

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?

Extremely dense — nearly every clause carries a constraint, with no filler. The only weakness is ordering: it opens with paywall metadata rather than the core purpose, and the telegraphic style makes it slightly harder to parse than necessary.

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?

For a nested 3-parameter tool with no output schema and no annotations, the description covers most of what an agent needs: result semantics (continuous UTC windows meeting the declared duration), input limits, timestamp precision, and payment/data-trust caveats. It stops short of describing the response structure beyond the window concept.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does for the two hardest points: the optional zone is clarified as an assertion that supplied offsets match that zone rather than a display setting, and timestamps must carry explicit offsets with at most microsecond precision. The main remaining gap is that the accepted string format for start/end (e.g. ISO 8601) is never stated.

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 states a precise verb and resource — 'Intersect supplied availability' — and bounds it operatively (1-100 participants, up to 1000 total intervals). It also pins down the output ('continuous UTC windows for the declared duration'), so the agent knows this is a pure interval computation, not a calendar lookup.

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?

It makes the operating context explicit ('supplied availability', i.e. the caller must bring interval data) and states firm exclusions: 'No calendar access, hold, invitation or booking.' What it lacks is any routing language relative to alternatives or a statement of prerequisites beyond the payment note.

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

All Novarithm Agent Hub: trust and commerce checks toolsInspect
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