Skip to main content
Glama

sap steve launch preview dbc

sap_steve_launch_preview_dbc

PRE-LAUNCH DBC economics readout: decodes the exact Meteora DBC config the gateway will sign (scaled per quote decimals) and simulates the dev-buy with the official SDK swap math. Returns migration threshold, start price, curve breakdown, tokens out (supply-capped) and min-out after slippage. Call this instead of estimating locally — the frontend renders these values verbatim.

SAP MCP execution guidance: Intent: SAP MCP tool workflow. Pricing: free; call directly without x402. Routing: free hosted call; call directly and keep it small/exact when possible. Signer boundary: hosted reads/builders never receive keypair bytes; value-moving results must be finalized locally when signing is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quoteMintYesQuote mint address (SOL = wrapped SOL mint, CUSTOM = the verified mint)
slippageBpsNoDev-buy slippage in bps (default 300)
solPriceUsdNoLive SOL/USD reference; required for non-SOL quotes.
devBuyAmountNoHuman dev-buy amount in quote units (e.g. 1 SOL, 1000 OOBE). 0/omitted = curve facts only.
quotePriceUsdNoLive USD price of one quote token; required for non-SOL quotes.
migrationQuoteThresholdNoOptional positive quote reserve target that graduates the bonding curve to DAMM v2, in human quote-token units. Decimal strings preserve exact large custom-quote amounts.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesMCP content blocks returned to the caller.
isErrorNoTrue when the tool result represents an application-level error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / migrationQuoteThreshold
      Added value: +{
      +  "description": "Optional positive quote reserve target that graduates the bonding curve to DAMM v2, in human quote-token units. Decimal strings preserve exact large custom-quote amounts.",
      +  "oneOf": [
      +    {
      +      "description": "Migration Quote Threshold parameter for sap steve launch preview dbc.",
      +      "exclusiveMinimum": 0,
      +      "type": "number"
      +    },
      +    {
      +      "description": "Migration Quote Threshold parameter for sap steve launch preview dbc.",
      +      "pattern": "^\\d+(?:\\.\\d*)?$",
      +      "type": "string"
      +    }
      +  ]
      +}
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) establish the safety profile, and the description adds real behavioral context: it decodes the exact config the gateway will sign, uses official SDK swap math, and the signer boundary states hosted builds never receive keypair bytes. The read-only framing of a 'readout' sits a bit awkwardly against readOnlyHint=false, but no explicit mutation is claimed.

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 first sentence is dense, front-loaded, and covers purpose plus return contents; the second is a direct call to action. The SAP boilerplate paragraph is generic across many tools and only the signer-boundary clause is truly specific here, but it does not overwhelm the definition.

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?

An output schema exists, so returning-value detail is a bonus rather than a requirement, and the description still enumerates migration threshold, start price, curve breakdown, tokens out, and min-out. For a complex DBC-economics preview the definition is nearly complete, missing only how it relates to the subsequent build/sign tools.

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 description coverage is 100%, so the schema already documents all six parameters, including slippage default, SOL/USD requirements, and quote-unit semantics. The description adds only tangential hints ('scaled per quote decimals', 'min-out after slippage') that map loosely to slippageBps and quoteMint, so the baseline 3 is appropriate.

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 states a specific verb and resource: it decodes the exact Meteora DBC config and simulates the dev-buy with SDK swap math, clearly framed as a pre-launch readout. This distinguishes it well from the build/sign siblings, though it never names the sibling it replaces (sap_steve_launch_build_dbc).

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?

'Call this instead of estimating locally — the frontend renders these values verbatim' gives a clear use condition, and the routing boilerplate ('free; call directly') reinforces it. However, there is no explicit when-not, no named alternative tool, and no guidance on the build/signing step that presumably follows.

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.