Skip to main content
Glama

excalibur_post_nostr_message

Publish a public Nostr note (kind 1) authored by your proven npub.

eXcalibur cannot sign a note as you — a Nostr event must be signed by the key it claims to come from, and eXcalibur never holds your nsec. So for this one note it mints a fresh, ephemeral "scribe" keypair, signs with it, and p-tags YOUR npub as the author. The p-tag renders the note as a real mention and places it in your own Nostr mentions, so you can see — and disown — anything published in your name.

The author is always your proven npub from this session (the same npub you pass for billing); it is never a free-form argument, so no caller can scribe as anyone else.

The note publishes to the DPYC relay set. The call succeeds if at least one relay accepts it; the response lists every relay's accept/reject and the accepted/attempted counts so you can see the note's real reach — a one-relay publish never reads as a clean broadcast.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
npubNoRequired. Your PROVEN Nostr public key (npub1...). You are recorded as the note's author.
messageYesThe note text to publish.
dpop_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers exceptionally: it discloses that eXcalibur cannot sign as the user, mints an ephemeral scribe keypair, p-tags the user's npub, publishes to the DPYC relay set, and succeeds if at least one relay accepts. It also explains the response contents and the disowning ability.

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 description is four paragraphs and somewhat repetitive about the author being the proven npub, but each sentence carries meaningful behavioral or contextual information. It is not bloated with irrelevant details, though a more condensed version could earn a 5.

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?

The description thoroughly covers signing, authorship provenance, relay behavior, and the success/failure condition, which is impressive for a complex tool. Minor gaps include no explanation of dpop_token, no explicit statement about zero-relay failure behavior, and no mention of prerequisites like authentication or billing.

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?

The schema description already covers npub and message, and the description adds valuable context for npub (proven, session-bound, billing correlation, never free-form). However, dpop_token is completely unexplained in both schema and description, and with 67% coverage, the description does not fully compensate for that gap.

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 'Publish a public Nostr note (kind 1) authored by your proven npub,' which is a specific verb+resource+scope. It clearly distinguishes this from sibling tools like excalibur_post_tweet or excalibur_create_post by specifying Nostr note, kind 1, and the author constraint.

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?

The description explains constraints and mechanics, but never explicitly says when to use this tool versus alternatives such as excalibur_post_tweet or excalibur_create_post. It implies usage through the name and context, but provides no exclusions or direct comparisons to sibling tools.

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.

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.