Create an asset project with a reusable style bible so every prompt stays on-model and the generated set remains consistent.
Create an asset project with a style bible that every prompt reuses (this is what keeps a set consistent).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lowercase slug, e.g. "my-face-stickers" | |
| type | Yes | What the set is | |
| bible | Yes | Style bible | |
| pixel | No | Set for pixel-art projects |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It communicates one useful behavioral fact, that the bible is reused by every prompt and drives set consistency, but says nothing about mutation side effects, duplicate-name handling, permissions, or what the call 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?
One sentence, front-loaded with the verb and resource, with no filler. The parenthetical rationale is slightly chatty for a tool description but it does add meaning rather than restate the name.
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?
For a mutating create tool with no annotations and no output schema, the description covers the what but not the operational context (failure modes, uniqueness constraints, follow-up calls). It is minimally adequate given the rich schema.
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% and nested objects are documented in detail, so the schema itself does the heavy lifting for name/type/bible/pixel. The description adds only one semantic note, that the bible persists across prompts, which is marginal beyond what the schema already conveys.
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?
Clear verb (Create) plus resource (asset project), and it names the distinguishing artifact, the style bible. It does not explicitly separate itself from siblings like project_get or project_update, but the create verb makes the role obvious.
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?
Usage is only implied: you create a project when starting a new asset set. There is no guidance on when to choose this over project_update, no prerequisites (e.g. does a project name need to be unique?), and no mention of what to do after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.