Skip to main content
Glama

Perm Inverse

perm_inverse
Read-onlyIdempotent

Inverse of a permutation of 0..n-1. The inverse of [1, 2, 0] is [2, 0, 1]. Applying both is the identity. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/perm-inverse

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": {
      "perm": "<perm>"
    },
    "name": "perm_inverse"
  }
}

Input Schema

NameRequiredDescriptionDefault
permYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the bar is lower. The description adds genuinely new behavioral context: cost ($0.001 USDC per successful call), payment protocol (x402, Solana), and an alternate HTTPS endpoint. It does not mention input validation behavior for non-permutations, which is a minor gap.

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?

The definition and example are front-loaded, and the sentences about the identity property and pricing each add information. The pricing/HTTPS sentences are slightly tangential to the mathematical core but still relevant to actually invoking the paid endpoint.

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 one-parameter tool with no output schema, the description covers the operation, a concrete input/output example, and the access/pricing model. Only edge-case validity behavior and explicit output shape are left implicit, which is acceptable given the well-defined mathematical domain.

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%, so the description must carry semantics. It does so partially by defining the input as a permutation of 0..n-1 and illustrating format with [1, 2, 0], but it omits explicit constraints such as validity requirements or array length limits and never names the 'perm' parameter.

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 operation on a precise object: 'Inverse of a permutation of 0..n-1', reinforced with a worked example. It is clearly distinguishable from siblings like perm_compose, perm_rank, or perm_sign without opening any schema.

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 mathematical context and the identity property ('applying both is the identity'), but there is no explicit statement of when to call this versus alternatives such as perm_compose or perm_rank. The agent can infer the scenario but is given no routing guidance.

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