Skip to main content
Glama
Sign In

SpellBook Finance

by com.spellbook-finance
OverviewDiscussionsAdmin

spellbook_alert_create

Idempotent

Create one alert in a workspace and return the saved alert. alertType buylist_watch watches dealer buy offers for the whole inventory (buylistWatchScope inventory) or for one printing and finish (buylistWatchScope card); buylistWatchCondition crossed also needs direction and threshold in USD. Every other alertType watches one card or box and needs assetType, assetKey, assetName, isFoil, direction and threshold. Sending the same alert twice returns the first one with replayed true and creates nothing. Call spellbook_alerts_list first to see what exists.

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": {
      "workspaceId": "<workspaceId>",
      "alertType": "<alertType>"
    },
    "name": "spellbook_alert_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
finishNoThe finish to watch, matching the finish codes spellbook_printings_search returns. Required for a buylist_watch with scope card.
isFoilNoWhether the watched card is foil. Required for every non-buylist_watch type.
contextNoOptional analytics context: briefly describe the user's underlying goal in one sentence. Do not copy prompts, personal details, credentials, identifiers, or tool arguments. Omit for private tasks.
assetKeyNoThe printing id for a card or the product id for a box. Required for every non-buylist_watch type.
alertTypeYesThe kind of alert. buylist_watch watches dealer buy offers against inventory or one printing. Required.
assetNameNoA display name for the watched asset. Required for every non-buylist_watch type. Optional for buylist_watch.
assetTypeNoWhether the alert watches a card or a sealed box. Required for every non-buylist_watch type.
directionNoWhether the alert fires when the price is above or below threshold. Required for crossed and for every non-buylist_watch type.
thresholdNoThe USD price the alert compares against. Required for crossed and for every non-buylist_watch type.
scryfallIdNoThe exact printing id from spellbook_printings_search. Required for a buylist_watch with scope card and for a card alert.
workspaceIdYesThe workspace the alert belongs to, from spellbook_workspaces_list. Required.
buylistVendorNoFor buylist_watch: the dealer to watch, as SpellBook stores the vendor name. Omit to watch Card Kingdom.
buylistWatchScopeNoFor buylist_watch: inventory watches every sellable item in the workspace, card watches one printing and finish. Required for buylist_watch.
buylistWatchConditionNoFor buylist_watch: buying_again or crossed. crossed also needs direction and threshold. Required for buylist_watch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Optional analytics context: briefly describe the user's underlying goal in one sentence. Do not copy prompts, personal details, credentials, identifiers, or tool arguments. Omit for private tasks.",
+  "maxLength": 512,
+  "type": "string"
+}
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=true; the description adds concrete value by explaining the idempotency mechanism (returns the first alert with replayed true and creates nothing), which tells the agent retries are safe. It does not mention required permissions or rate limits, but the annotation coverage lowers the burden.

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?

Front-loads the create-and-return action, then groups conditional requirements by alertType in a dense but readable block; the final two sentences cover idempotency and the recommended prior call. Given 14 parameters and 11 enum alert types, the length is justified, though the long opening sentence could be split for scanability.

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

Completeness3/5

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

For a 14-parameter mutation with no output schema, the description covers conditional field requirements and idempotency well, and states it returns the saved alert. It omits what to do on validation failure and any workspace/plan preconditions, leaving some gaps an agent would encounter when invoking it.

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 the baseline is 3; the description earns above that by giving cross-field conditional logic the schema cannot express – buylist_watch with scope inventory vs. card, and that buylistWatchCondition 'crossed' additionally requires direction and threshold in USD, versus all other types needing assetType/assetKey/assetName/isFoil/direction/threshold.

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 and resource ('Create one alert in a workspace and return the saved alert') and immediately distinguishes itself from spellbook_alerts_list and spellbook_alert_delete by describing creation semantics. An agent can tell what it produces (a saved alert) without opening the schema.

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?

Explicitly routes the agent: 'Call spellbook_alerts_list first to see what exists,' and states that resubmitting an identical alert is a no-op returning replayed true. It also conditions which fields are needed per alertType. It stops short of naming when not to use this tool or listing prerequisites such as plan/entitlement limits.

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

All SpellBook Finance 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