Skip to main content
Glama

excalibur-mcp

by io.github.lonniev

excalibur_resolve_dynamic_block

Start resolving a dynamic post block with an LLM — returns a CLAIM CHECK.

A dynamic block's prompt is run by the model (with web search + web fetch for live data) and woven into the surrounding post context in the author's voice. The author's instruction governs length — there is no character cap (X supports long-form posts). The operator's LLM key stays in the vault and never leaves the server.

Because that work (paginated fetches + generation) can outlast a client timeout, this returns immediately with a claim check instead of the text: {"success": true, "claim_check": "...", "status": "pending", "poll_after_seconds": N}. Redeem it with the free companion fetch_dynamic_block(claim_check) until status == "done" (then read result.text). (The scheduler resolves blocks directly server-side at fire time and does not use this tool.)

Paid: the AI cost is metered as a tollbooth fare on THIS start call, refunded if no LLM key is configured or the job ultimately fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bansNoBanned constructions — JSON array or comma-separated (optional).
npubNoRequired. Your Nostr public key (npub1...) for credit billing.
voiceNoVoice-profile text fed to the model (optional).
promptYesThe dynamic block's prompt to run.
contextNoThe surrounding composed post (may contain the ⟨HERE⟩ marker).
dpop_tokenNo
max_fetchesNoAuthor budget for web lookups (search + fetch), 1..25.
allowed_domainsNoAuthor allowlist for web_fetch — JSON array or comma-separated. Blank = fetch any URL the prompt references.
runtime_limit_secondsNoAuthor's time budget for this block in seconds (60–1800). Bounds how long the job may run AND sets the poll cadence; the operator may price it ad valorem.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the immediate claim-check return, the async nature ('work can outlast a client timeout'), the billing model ('metered as a tollbooth fare... refunded if no LLM key is configured or the job ultimately fails'), and security ('LLM key stays in the vault and never leaves the server'). This is rich, actionable context.

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

Conciseness5/5

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

The description is three tight paragraphs: purpose, async rationale with the claim-check flow, and billing. Every sentence earns its place, and the most critical fact (returns a claim check) is front-loaded. No fluff or repetition.

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?

The description covers the full lifecycle: how to start, the claim-check format, how to poll with the companion tool, when it's not used (scheduler), security, and cost implications. It also clarifies there is no character cap. For a complex async tool, this is comprehensive.

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 89%, so the schema already documents most parameters. The description adds semantic meaning by explaining how prompt, context, and voice interrelate: 'A dynamic block's prompt is run by the model... woven into the surrounding post context in the author's voice.' This helps the agent understand the purpose of these fields beyond their names.

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 description opens with 'Start resolving a dynamic post block with an LLM — returns a CLAIM CHECK.' This clearly identifies the verb (start resolving), resource (dynamic post block), and key behavior (returns a claim check), distinguishing it from the sibling fetch_dynamic_block.

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?

The description explicitly instructs to 'Redeem it with the free companion fetch_dynamic_block(claim_check)' and notes that 'The scheduler resolves blocks directly server-side at fire time and does not use this tool.' This provides clear alternatives and exclusions, telling the agent when to use this tool versus others.

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

All excalibur-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct operation and domain (account, posts, coupons, credentials, scheduling, oracle, etc.), with clear differentiation even for similar-sounding tools like check_balance vs check_authority_balance or list_coupons vs list_my_coupons. There is no ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (e.g., create_post, delete_coupon, list_posts), with no mixing of styles. The excalibur_ prefix is uniform.

Tool Count1/5

With 72 tools, the server far exceeds the typical well-scoped range (3–15). While the functionality is broad, the sheer number feels excessive for a single MCP server, leading to an extreme mismatch.

Completeness5/5

The tool surface covers the full lifecycle for core domains: CRUD for posts, snippets, coupons, credentials; complete flows for OAuth, npub proof, scheduling, notarization, and payments. No obvious gaps are present.

Resources