Skip to main content
Glama
Sign In

Super Artifacts

by app.superartifacts
OverviewDiscussionsAdmin

Ask people to sign an artifact

super_signatures

Ask named people to sign one published version of an artifact, and follow the request. request with artifact, signers [{name, email, party?}] (≤10) and an optional message (≤500 characters) emails each signer a private link; the version must be one file of at most 2 MiB, and it is kept while the request is open and for good once it completes. status with request (one) or artifact (all, newest first). withdraw closes an open request. remind emails signer the link again, three times at most, a day apart. Only each signer can sign, in a browser, after a code sent to their address: an agent cannot.

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": {
      "action": "<action>"
    },
    "name": "super_signatures"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYes
signerNoA signer id, from status. For remind.
messageNoA note shown to every signer.
requestNoA signature request id, from request or status.
signersNo
versionNoThe version to sign. Default: the published one.
artifactNoArtifact id or slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the annotations: it discloses that signers are emailed a private link, that the version is retained while open and permanently after completion, the 2 MiB single-file constraint, the reminder cap of three at one-day intervals, and critically that only the signer can sign in a browser via an emailed code — an agent cannot. These are exactly the side effects and limits an agent needs before invoking.

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 core action, then packs the per-action contract into dense but well-ordered sentences; nearly every clause adds a real constraint or behavior. It is long but justified by the multi-action surface.

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?

Covers the full lifecycle (request → status → remind → withdraw → sign) and all the operational constraints an agent needs, with no output schema required. A minor gap is that it doesn't sketch what `status` returns (e.g. per-signer state), which would help an agent interpret results.

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 71%, and the description fills the main gap by mapping parameters to actions (signer for remind, request for status/withdraw, artifact/signers/message for request) and adds constraints not in the schema, such as the 2 MiB single-file version requirement and the meaning of retention. Some per-action requiredness remains implicit.

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 — ask named people to sign one published version of an artifact — and enumerates the four concrete actions (request, status, withdraw, remind). An agent knows exactly what the tool does and how the sub-actions differ 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?

Each action is paired with its intended use and required inputs: `request` with artifact/signers/message, `status` with request or artifact, `withdraw` closes an open request, `remind` re-emails a signer. There is no explicit 'when not to use' or named alternative, but no sibling signature tool exists, so the routing guidance is effectively complete.

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

All Super Artifacts toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources