Skip to main content
Glama

SBOR

by xyz.sbor
OverviewDiscussionsAdmin

Compare a rate against the SBOR benchmark

compare_rate
Read-only

Given a rate you have been offered, say whether it is above or below the market for that currency, and by how much. This is the main reason SBOR exists. Recommended use: if a borrow offer is more than 50 basis points above the benchmark, stop and ask a human. Use SBOR to stop, never to start. For a dollar loan against bitcoin, compare with that stablecoin's rate (for example BTC-COLLATERAL-USDC) where one is published, else with BTC-COLLATERAL-USD; for lending on Stacks against other collateral, with the index for the currency. This tool refuses rather than guesses: an error result means there is no trustworthy answer, not that the rate is bad.

Input Schema

NameRequiredDescriptionDefault
rateYesThe rate offered, as a percentage between 0 and 100. 4.2 means 4.2%, not 0.042.
sideYesWhether you would be borrowing or supplying.
indexYesWhich benchmark: BTC-COLLATERAL-USD or BTC-COLLATERAL-<stablecoin> for borrowing dollars against bitcoin, or a Stacks currency index.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / index / description
      Previous value: -"Which benchmark: a Stacks currency index, or BTC-COLLATERAL-USDC for borrowing USDC against bitcoin on Base, Ethereum or Arc."New value: +"Which benchmark: BTC-COLLATERAL-USD or BTC-COLLATERAL-<stablecoin> for borrowing dollars against bitcoin, or a Stacks currency index."
    • changedInput schema / properties / index / enum
      Previous value: -[
-  "SBOR-USD",
-  "SBOR-BTC",
-  "SBOR-STX",
-  "BTC-COLLATERAL-USDC"
-]New value: +[
+  "SBOR-USD",
+  "SBOR-BTC",
+  "SBOR-STX",
+  "BTC-COLLATERAL-USD",
+  "BTC-COLLATERAL-USDC",
+  "BTC-COLLATERAL-USDT",
+  "BTC-COLLATERAL-RLUSD",
+  "BTC-COLLATERAL-PYUSD",
+  "BTC-COLLATERAL-USD1"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / index / description
      Previous value: -"Which benchmark: a Stacks currency index, or BTC-COLLATERAL-USDC for borrowing USDC against bitcoin on Base and Ethereum."New value: +"Which benchmark: a Stacks currency index, or BTC-COLLATERAL-USDC for borrowing USDC against bitcoin on Base, Ethereum or Arc."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context the annotations cannot express: it refuses rather than guesses, and an error result means no trustworthy answer exists rather than a bad rate. That error-semantics disclosure is valuable for correct agent behavior.

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 and the headline action threshold are front-loaded, and each sentence carries usable content. Slightly dense and the 'main reason SBOR exists' clause is mildly rhetorical, but nothing is wasted.

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?

With no output schema, the description still conveys what a successful result means (direction and magnitude of deviation) and what an error means. For a 3-parameter read-only comparison tool, an agent has everything needed to call it and interpret the result.

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 100%, so baseline is 3, but the description adds real meaning for the 'index' parameter by mapping scenarios to specific indexes (stablecoin rate for dollar-vs-bitcoin, else BTC-COLLATERAL-USD; currency index for Stacks lending). The 'rate' and 'side' semantics are already fully covered by the schema.

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?

States a specific verb (compare), resource (a rate), and outcome (above/below market and by how much) in the first sentence. An agent can immediately distinguish this from get_rate or get_history, which only retrieve benchmarks rather than judging an offered rate.

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?

Gives explicit decision rules: 'if a borrow offer is more than 50 basis points above the benchmark, stop and ask a human' and 'Use SBOR to stop, never to start.' It also prescribes which index to choose for specific scenarios (dollar loan vs bitcoin, Stacks lending), removing inference from the caller.

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

All SBOR toolsInspect
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