Skip to main content
Glama

Issn Validate

issn_validate
Read-onlyIdempotent

ISSN check digit (8 characters, the last may be X). Spaces and hyphens are ignored. The formatted form is the two groups of four. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: GET https://scorptech.it.com/api/x402/v1/issn-validate

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": {
      "value": "<value>"
    },
    "name": "issn_validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
valueYes

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 and open-world behavior, so the bar is lower. The description adds real value beyond them by disclosing pricing ($0.001 USDC per successful call, x402 on Solana) and an alternate HTTPS endpoint, which matters for cost-sensitive or non-MCP callers.

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?

Format rules are front-loaded, followed by pricing and endpoint in short declarative sentences with no filler. Every sentence adds information an agent needs.

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 trivial single-parameter validator with no output schema, the definition covers input format, cost model, and transport. It stops short of saying what a successful versus failed validation returns, which would be the only remaining gap.

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 the input semantics, and it does: it defines the 8-character length, the possible X check digit, and that spaces and hyphens are ignored. It could still state that 'value' is the raw ISSN string, but the format guidance substantially compensates for the schema gap.

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?

The description identifies an ISSN check-digit operation and specifies the accepted input form (8 characters, last may be X, spaces/hyphens ignored). The verb 'validate' comes only from the name, but for a one-argument validator in a family of *_validate tools the purpose is unmistakable.

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 resource (ISSN) rather than stated. The description never routes the agent away from near-siblings such as isbn_validate or ean_validate, so an agent must infer the distinction from the identifier type alone.

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