Skip to main content
Glama

Ipow

ipow
Read-onlyIdempotent

The integer power base^exp. 2^10 is 1024, and (-2)^5 is -32. 0^0 is 1. exp runs from 0 to 256. The base has at most 80 digits. Past 15 digits the value is a decimal string. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/ipow

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": {
      "base": "<base>",
      "exp": "<exp>"
    },
    "name": "ipow"
  }
}

Input Schema

NameRequiredDescriptionDefault
expYes
baseYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing pricing ($0.001 USDC per successful call via x402 on Solana), an alternate HTTPS endpoint, and the output format change to a decimal string past 15 digits. Annotations already cover read-only/idempotent safety, so this added payment and serialization context is the real value.

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?

Front-loaded with the operation and examples, then limits, then pricing/endpoint. Efficient overall, though the range restatements slightly overlap the schema.

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 does the necessary work by explaining that results past 15 digits come back as a decimal string, plus edge cases (0^0, negative base). Remaining minor gap is whether small results are returned as integers or strings.

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 coverage is 0%, but the schema itself carries pattern, min/max, and maxLength constraints, so much of the range information in the description ('exp runs from 0 to 256', 'base has at most 80 digits') is duplication. The examples do clarify that negative bases are permitted and that 0^0 is defined as 1, which the schema's regex alone only hints at.

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 operation, integer exponentiation of base^exp, with concrete examples (2^10, (-2)^5) that pin down the semantics. It doesn't explicitly contrast with siblings like mod_pow or power_mod, but the 'integer power' framing plus the domain limits make the target unambiguous.

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 statement of when to use this versus alternatives such as mod_pow, power_mod, or sl2_pow, and no prerequisites or exclusions. Usage must be inferred entirely from the name and examples.

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