drawspec
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_kindsA | List the vocabulary: all 36 values |
| get_exampleA | Get the smallest valid document of one kind, as JSON ready to edit: the fastest way to the right field names. |
| get_schemaA | Get the JSON Schema (draft 2020-12) for one kind's documents: every field it accepts, with types, limits and descriptions, plus only the shared |
| validate_documentA | Check whether |
| render_documentA | Draw the document. Use it when it is ready to show; while still fixing errors, |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool occupies a distinct stage of the authoring pipeline: discover kinds, fetch an example, fetch a schema, validate, render. list_kinds/get_example/get_schema are clearly separated by output (vocabulary vs. document vs. schema), and validate vs. render is explicitly differentiated by verdict-only vs. drawing. No two tools could reasonably be confused.
All five names follow a strict verb_noun snake_case pattern (list_kinds, get_example, get_schema, validate_document, render_document). Verbs are meaningful and non-redundant, and the resource nouns map cleanly onto the domain objects.
Five tools is well-scoped for a document-rendering server, with each tool earning its place as one step in a discover→example→schema→validate→render flow. Nothing is redundant and nothing feels artificially split.
The surface covers the full authoring lifecycle from kind discovery through validation and rendering, with outputs in multiple formats. Minor gaps: no way to persist/export rendered output to a file or to enumerate theme options, though returning content blocks and accepting a theme argument largely mitigates this.