Agent Paywire library

Read the SDK security registry

get_sdk_security

Read-onlyIdempotent

Return /api/sdk-security.json. Output is the SDK security document: schema_version, generated_at, disclaimer, description, count, and entries. count equals entries.length. Each entry has id, package, ecosystem (npm or github), minimum_safe_version (string or null), constraint (string or null), per_payment_cap_usd (number or null), formal_advisory_published (boolean or null), advisory_url (string or null), reported_at, fixed_at, origin_header_rejected_since, fixes, notes, source, related_urls, and verified_at. Null means the linked source does not state that field. The rows are @x402/fetch, @x402/axios, @x402/extensions, and @x402/svm at >=2.23.0, Eclair at >=0.14.6, Core Lightning at >=26.04.1 for the Optech #429 announcement bug, a separate Core Lightning v26.06.10 row whose release names no CVE, lnd for CVE-2026-98432, an agent-approval-channel advisory, and BTCPay Server with minimum_safe_version null because Optech #428 does not name a version. One unpaged document. Takes no parameters: call with an empty object. Use get_sdk_security instead of search_sources when you need the minimum version table. Use search_sources for the V12 post, Optech #428, and the Eclair release notes. Use /api/lightning-wallets.json and /api/lightning-releases.json for the wallet catalog and the stable node table; this tool does not return those files. A failed read returns isError. The text is the Error message. Free, no auth.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_sdk_security"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`count`	Yes
`entries`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 24, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), it usefully discloses that the document is unpaged, that failures return isError with the message as text, and that no auth is required. However, restating the row contents and field list mostly duplicates the output schema rather than adding new behavior; with annotations already covering safety, a 3 reflects solid but partly redundant disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the endpoint and the return shape, but the exhaustive listing of every field and every registry row consumes most of the text and largely repeats what the output schema already documents. That bulk dilutes the routing and error guidance that actually carries value.

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?

Because an output schema exists, the description need not explain return values, yet it still covers invocation, unpaged behavior, error signaling, auth, and sibling alternatives, which is enough for an agent to call it correctly. The main gap is that the field and row enumeration is redundant rather than additive.

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?

There are no parameters, so the baseline is 4. The description reinforces this by telling the agent to call with an empty object, removing ambiguity about how to invoke a zero-arg tool.

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 first sentence names the exact resource returned (/api/sdk-security.json) and the second states what the document contains (schema_version, count, entries). It explicitly rules out confusable siblings, saying it does not return /api/lightning-wallets.json or /api/lightning-releases.json.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a direct routing rule: use this tool over search_sources when the minimum version table is needed, and use search_sources for the V12 post, Optech #428, and the Eclair release notes. The when-not conditions and the alternative endpoints are named explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Agent Paywire library tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?