LLPRO Campus

Check an agent's action against the limits its owner signed: budget cap, end date, allowed actions. Signed result. No money held

spend_limit_check

Read-onlyIdempotent

Is this action inside the limits an owner signed for a long-running agent? Send the signed scope (agent, budget cap, end date, allowed actions; signed by the owner's Ed25519 key), the action, amount and currency the agent wants, and optionally spent_so_far and expected_principal (the owner's public key you trust). Get back allow, deny or invalid, every check with pass or fail, what is left of the budget, and a signed record anyone can verify. No money is held or moved. It does not show who the owner is, that the scope was not revoked (nothing is stored), or that spent_so_far is true. Free.

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": {
      "scope": "<scope>",
      "request": "<request>"
    },
    "name": "spend_limit_check"
  }
}

Input Schema

Name	Required	Description
`scope`	Yes
`request`	Yes
`spent_so_far`	No	decimal text; what the agent has already spent under this scope (your statement; not verified)
`expected_principal`	No	the owner's public key you expect; if it differs the scope is refused

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description states that no money is held or moved, that nothing is stored (so revocation cannot be checked), that spent_so_far is unverified, and that the owner's identity is not disclosed. It also explains the output is a verifiable signed record and that the call is free, which are material traits an agent cannot get from annotations alone.

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?

Purpose is front-loaded as a question, then inputs, then outputs, then limitations, which is a logical order. The first sentence is a long run-on clause chain that could be split, but nearly every clause carries usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return contract itself and does so fully: verdict enum, per-check pass/fail, remaining budget, and a verifiable signed record. Combined with the explicit limitation list, an agent has everything needed to call it and interpret the answer.

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 50%, and the description maps the fields into a coherent story (signed scope from the owner, the requested action/amount/currency, optional spent_so_far and expected_principal), which helps assemble a valid payload. However, for the undocumented schema fields it adds no format detail (currency codes, decimal text rules, base64 signature encoding) and largely restates what the schema already says about expected_principal and spent_so_far.

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 uses a concrete verb+resource pair (check an action against an owner-signed scope) and enumerates the returned verdicts (allow, deny, invalid). It does not name a sibling tool to differentiate against, so the agent must infer the boundary from the question framing alone.

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

Usage Guidelines4/5

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

The opening question establishes a clear usage context: pre-authorizing an action for a long-running agent with an owner-signed scope of budget cap, end date and allowed actions. It stops short of naming alternatives or stating explicit when-not conditions beyond the limitation list.

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

All LLPRO Campus 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?