Skip to main content
Glama
Sign In

Super Artifacts

by app.superartifacts
OverviewDiscussionsAdmin

Give people access

super_share
Idempotent

Give named people access to one of: an artifact (viewer; commenter also comments; editor also edits; new addresses are emailed), a project (viewer; each address is emailed) or a workspace (editor; returns accept links, sends no email). Someone already named moves to the role sent, so a lower role replaces a higher one; nobody is removed. Never changes visibility: public stays public; restrict with super_artifact_set. At most 20 addresses for an artifact, 50 for a project or workspace.

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": {
      "emails": "<emails>"
    },
    "name": "super_share"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoDefault viewer; editor for a workspace. An editor's key restores (super_artifact_set version), writes (super_data_write), publishes by slug in its workspace.
emailsYes
confirmNoProject only: true shares a project that holds private artifacts (`confirm_private`).
projectNoProject id, slug or exact title.
artifactNoArtifact id or slug.
workspaceNoA handle you administer, or "" for your own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm / description
      Added value: +"Project only: true shares a project that holds private artifacts (`confirm_private`)."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses email side effects per target type (new addresses emailed for artifacts; all addresses emailed for projects; accept links returned with no email for workspaces), discloses the privilege-downgrade behavior ('a lower role replaces a higher one'), and states an explicit per-target address cap (20/50). These are exactly the mutation consequences an agent needs before calling.

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 verb and target types, then packs role and side-effect nuances into tight parenthetical clauses. Every clause carries information, but the density of parentheticals makes it slightly harder to scan than a cleaner bulleted structure would.

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?

For a 6-parameter mutation tool with no output schema, the description covers side effects, defaults, limits, downgrade semantics, and what it deliberately does not do (visibility, removal). Nothing an agent needs in order to call it correctly is missing.

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 already 83%, so the baseline is 3; the description earns above that by adding meaning the schema cannot, notably the differing email-order caps for artifact vs project/workspace and the role defaults per target. It still leaves 'confirm' (project private-artifact confirmation) and the workspace accept-link return value to the schema's own descriptions.

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 concrete verb ('give access') plus the three supported target resources (artifact, project, workspace) and the roles each accepts. An agent can immediately tell this grants access rather than listing or modifying resources like the sibling super_artifacts or super_artifact_set.

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?

Per-target behavior is spelled out (artifact viewers/commenters/editors, project viewers, workspace editors), and the boundary case is routed to a sibling: 'Never changes visibility: public stays public; restrict with super_artifact_set.' It also implicitly excludes removal via 'nobody is removed.' What it lacks is a positive statement of when not to use it (e.g., 'use super_project_members to remove access').

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