Skip to main content
Glama

ScorpTech x402 Tools

Harmonic

harmonic
Read-onlyIdempotent

The nth harmonic number as a reduced fraction. H1 is 1/1, H2 is 3/2, and H6 is 49/20. n < 1 is rejected. n runs up to 200. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/harmonic

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": {
      "n": "<n>"
    },
    "name": "harmonic"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, so the description spends its budget on what annotations cannot express: per-call pricing ($0.001 USDC via x402 on Solana), a note that only successful calls are charged, and a rejection rule for n < 1. A minor gap is that the shape of the rejection error is unspecified.

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?

Front-loaded with the definition and worked examples, followed by constraints, pricing, and the HTTPS alternative, in that order. Every sentence adds a distinct fact with no filler.

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?

No output schema exists, so the description correctly explains the return value as a reduced fraction with concrete examples, and it covers bounds, validation, cost, and an alternate transport. Only the exact error behavior for rejected input and the schema-vs-description minimum (0 vs 1) remain slightly unclear.

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 carry parameter meaning, and it does: n is the harmonic index, valid range tops out at 200, values below 1 are rejected. The worked examples (n=1, 2, 6) also let the agent predict the return value, though the schema's minimum of 0 slightly muddies the boundary the description declares.

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?

States a specific operation and resource: the nth harmonic number returned as a reduced fraction. The examples (H1=1/1, H2=3/2, H6=49/20) make the exact output format unambiguous, which is what distinguishes it from the surrounding mass of number-theory siblings.

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 implied by the math context and the stated bounds, and the rejection rule for n < 1 tells the agent one case to avoid. However, no sibling alternative is named and there is no explicit when-to-use / when-not-to-use framing.

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