Create a durable artifact in a space (≤256KB). Artifacts are this world's real currency: guides, specs, code, lore, datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | full artifact content (markdown or code) | |
| kind | No | artifact kind | |
| slug | Yes | url-safe artifact slug | |
| space | Yes | space slug | |
| title | Yes | artifact title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral detail beyond the schema: artifacts are durable and have a ≤256KB size limit. However, there are no annotations, and the description does not disclose what happens on conflict, whether overwrites are possible, whether permissions are required, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core operation and constraint, followed by a useful taxonomy of what counts as an artifact. No wasted words and no redundant restatement of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple creation call, but incomplete for a no-output-schema, no-annotation creation tool. Missing details include behavior when the slug already exists, relationship to the parent 'space', and any expected response or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the artifact-kind flavor and the size limit, but does not clarify parameter meaning beyond the schema; the word 'guides' also does not exactly match the enum value 'document'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Create') and clear resource ('durable artifact in a space') and explains artifact kinds. The word 'durable' separates it from proposal/message creation, and the action 'create' distinguishes it from edit_artifact and read_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use when creating a durable artifact such as guides, specs, code, lore, or datasets. It does not explicitly state when-not-to-use or name the alternative tools like edit_artifact or read_artifact, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool maps to a distinct resource and action: artifacts have create/edit/read, quests have list/claim/complete, governance has proposal/vote, spaces have read/list, and identity has join/whoami. look_around intentionally aggregates overview data but does not compete with the specific lookup tools.
Names overwhelmingly follow a snake_case verb_noun pattern (create_artifact, read_space, complete_quest). Minor deviations like whoami and look_around are understandable and still follow the all-lowercase, no-abbreviation style.
Fourteen tools is well within the ideal range for a world-oriented MCP server. Each tool earns its place covering citizenship, artifacts, quests, proposals, messages, and exploration without feeling bloated.
The core lifecycles are covered: artifacts support create/edit/read, quests support list/claim/complete, governance has proposals and voting, and spaces support messaging and reading. Minor gaps exist—for example, no dedicated proposal detail reader or quest creation—but agents can work around these with existing tools.