Skip to main content
Glama

Ruler Prefix

ruler_prefix
Read-onlyIdempotent

The ruler values v2(1) through v2(n), written as comma-separated integers. The first 8 values are 0,1,0,2,0,1,0,3. n runs from 1 to 4096. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/ruler-prefix

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": "ruler_prefix"
  }
}

Input Schema

NameRequiredDescriptionDefault
nYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds valuable context beyond annotations: the return format (comma-separated integers), an example output, an n range, the per-call price ($0.001 USDC x402/Solana), and an alternative HTTPS endpoint.

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 core output definition and example, then range, then pricing/endpoint. Every sentence adds distinct value with no waste.

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 single-parameter tool with rich annotations and no output schema, the description supplies return format, example output, range, and access/pricing details. Complete enough to call correctly; only sibling differentiation is missing.

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: 'v2(1) through v2(n)' explains that n is the inclusive upper index, and 'n runs from 1 to 4096' clarifies the range and meaning. This adds genuine semantics beyond the bare integer type/min/max.

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 clearly: returns the ruler sequence v2(1)..v2(n) as comma-separated integers, which is unambiguous. It does not explicitly distinguish itself from siblings like ruler, ruler_max, ruler_odd, or ruler_sum, so an agent must infer the 'prefix' scope from the description.

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 about when to use this versus the sibling ruler_* tools (ruler, ruler_max, ruler_odd, ruler_sum). The n range and example are given, but there is no guidance on selection or context of use.

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