What can you do with this server?

The StoryKit MCP server lets AI assistants search and embed free, ready-made design blocks (charts, widgets, illustrations, themes) — no API key or signup required. * Search the library (search_assets): Find design blocks by text query and/or kind (CHART_VARIANT, ANIMATION, TEXT_STYLE, THEME, COMPONENT, SVG, INTERACTIVE), with sorting (newest, used, name) and pagination support. * Get full asset details (get_asset): Retrieve complete metadata for a specific asset by ID, including its data schema, embed snippet, and links. * Get embed snippets (get_embed_snippet): Generate a ready-to-paste HTML snippet (one-line + script) pre-filled with example data; customize via data-sk-* attributes. * List themes & theme families (list_themes, list_theme_families): Browse published color palettes and editorial theme families for consistent styling. * List chart families (list_chart_families): Explore 65+ Datawrapper-aligned chart types with usage guidance and sample data. * Build bundle download URLs (bundle_url): Generate a .zip archive of one or more assets as standalone HTML pages (plus a composed page), optionally themed.

How do I use storykit-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@storykit-mcp Search for a gauge chart and give me the embed snippet." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

storykit-mcp

by aryan0078

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

storykit-mcp

Give an AI structured data and get back a hosted StoryKit widget — or drive the full Studio (images, media, brands, canvases, assets, series, workflows) with a personal API key.

Public widgets (no key) — find_widgets → render_widget → opaque hosted URL.
Studio tools (STORYKIT_API_KEY) — full owner surface under plan limits (~69 remote tools).

Mint a key + paste-ready LLM prompt: asset.storykit.space/ai

CRITICAL: which endpoint?

URL	Auth	Tools
`https://asset.storykit.space/api/v1/studio-mcp`	`Bearer sk_live_…`	Full Studio (images included)
`https://asset.storykit.space/api/v1/mcp`	none	Only widgets (3 tools) — no images

If tools/list lacks generate_image, you are on the wrong server.

Related MCP server: user-majico-mcp

Connect

Remote Studio (HTTP — preferred for images)

export STORYKIT_API_KEY="sk_live_…"
# Claude / Cursor / any streamable-HTTP MCP client:
# URL:  https://asset.storykit.space/api/v1/studio-mcp
# Header: Authorization: Bearer $STORYKIT_API_KEY

claude mcp add --transport http storykit-studio https://asset.storykit.space/api/v1/studio-mcp \
  --header "Authorization: Bearer ${STORYKIT_API_KEY}"

Remote public widgets only

claude mcp add --transport http storykit https://asset.storykit.space/api/v1/mcp

Local stdio (widgets always; Studio when key is set)

export STORYKIT_API_KEY="sk_live_…"   # required for image/studio tools
claude mcp add storykit -- npx -y storykit-mcp@3.3.0

Stdio tool names are prefixed with studio_ (e.g. studio_generate_image → remote generate_image).

HARD RULES for agents

Never invent images with DALL·E, Midjourney, Gemini image, built-in image_gen, Unsplash, etc.
Never invent ids — call list_* / get_* first.
After generate_image / edit_image, poll get_image_job until SUCCEEDED; return platform outputUrl only.

Public tools (no key)

Tool	Spec
`find_widgets`	`{ intent, domain?, dataFields?, kind?, page?, size? }` → schemas only
`render_widget`	`{ widgetId, data[], theme?, ttlDays? }` → expiring hosted URL (treat as secret)
`list_widget_themes`	`{}` palettes

Consent before personal/health data. Max 200 rows. Default TTL 30 days.

Studio tools (`STORYKIT_API_KEY`)

Call studio_get_account or studio_get_usage first.

Account & image status

Tool	Spec
`studio_get_account`	`{}` identity, plan, quotas
`studio_get_usage`	`{}` full limits snapshot
`studio_get_image_status`	`{}` queue, aspects, remaining

Media library

Tool	Spec
`studio_upload_media`	`{ imageBase64, contentType?, filename? }` → mediaId
`studio_list_media`	`{ query?, kind?, trash? }`
`studio_get_media`	`{ id }`
`studio_get_media_content`	`{ id }` base64 ≤2MB
`studio_update_media`	`{ id, title?, tags? }`
`studio_star_media`	`{ id, starred }`
`studio_trash_media` / `studio_restore_media` / `studio_delete_media`	`{ id }`

Image AI

Tool	Aliases	Spec
`studio_generate_image`	`studio_image_generate`, `studio_img_generate`	`{ prompt, aspect?, qualityMode?, brandKitId?, referenceMediaIds?, count?, magicPrompt?, caption?, mode? }`
`studio_edit_image`	`studio_image_edit`, `studio_img_edit`	`{ prompt, referenceMediaIds[1..5], maskMediaId?, aspect?, count? }`
`studio_list_images`		`{ query?, state? }`
`studio_get_image_job`		`{ jobId? }` or `{ id? }` — poll until SUCCEEDED
`studio_cancel_image_job` / `retry` / `delete`		`{ jobId }`
`studio_describe_image`		`{ mediaId? }` or `{ generationId? }`
`studio_publish_image` / `unpublish`		`{ id }` numeric generation id
`studio_save_image_as_kit`		`{ jobId }`
`studio_batch_generate_images`		PRO: `{ prompts[], aspect?, brandKitId?, qualityMode? }`

Aspects: square portrait poster story landscape banner
qualityMode: fast | quality

Image workflow

studio_get_account
Optional studio_upload_media → mediaId
studio_generate_image or studio_edit_image
Loop studio_get_image_job until SUCCEEDED
Return platform outputUrl only

Prompt / vision

Tool	Spec
`studio_compile_prompt`	`{ draft }` → caption for generate_image.caption
`studio_analyze_image_to_prompt`	`{ imageBase64, contentType?, aspect?, layout? }`
`studio_get_vision_job`	`{ jobId, apply? }`

Brands

Tool	Spec
`studio_list_brand_kits`	`{ query?, page?, size? }`
`studio_get_brand_kit`	`{ id }`
`studio_extract_brand_kit`	`{ imagesBase64:[{base64,contentType?}], prompt?, md? }`
`studio_refine_brand_kit`	`{ id, feedback }`
`studio_rename_brand_kit`	`{ id, name }`
`studio_duplicate_brand_kit`	`{ id, name? }`
`studio_delete_brand_kit`	`{ id }`
`studio_publish_brand_kit` / `unpublish`	`{ id }`
`studio_brand_showcase`	`{ id, count? }`

Canvases

Tool	Spec
`studio_list_canvases`	`{}`
`studio_get_canvas`	`{ id }` includes doc
`studio_create_canvas`	`{ title?, aspect? }`
`studio_save_canvas`	`{ id, title?, aspect?, doc?, thumbnailMediaId? }`
`studio_duplicate_canvas` / `studio_delete_canvas`	`{ id }`

Studio assets (commissioned widgets)

Tool	Spec
`studio_list_studio_assets`	`{}`
`studio_get_studio_asset`	`{ id }` no source code
`studio_commission_studio_asset`	`{ prompt, kind?, purpose?, sourceMd? }`
`studio_iterate_studio_asset`	`{ id, feedback }`
`studio_rename_studio_asset`	`{ id, title }`
`studio_trash_studio_asset` / `restore`	`{ id }`
`studio_list_folders` / `studio_create_folder`	create: `{ name }`

Series & workflows

Tool	Spec
`studio_list_series` / `get` / `create` / `series_next` / `series_extend` / `delete`	see input schemas
`studio_list_workflows` / `get` / `create` / `update` / `run` / `delete` / `list_workflow_runs`

Remote names drop the studio_ prefix. Full list: tools/list on studio-mcp.

Track usage at storykit.space/me.

Environment

Variable	Purpose
`STORYKIT_API_BASE`	API host (default `https://asset.storykit.space`)
`STORYKIT_API_KEY`	Personal `sk_live_…` for Studio tools
`STORYKIT_STUDIO_MCP`	Override Studio MCP URL

MIT. Created with love by Story Kit.

Available Tools

7 tools

bundle_urlA

Build a download URL for a .zip bundle of one or more assets (each as standalone index.html + asset.json, plus a composed page.html). Optionally pass theme id to skin the composed page.

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes
`theme`	No	optional THEME asset id for the composed page

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the tool's output (download URL) and its inputs, but does not mention whether the operation is safe (read-only), requires authentication, or has side effects. The description's mention of bundle contents adds some context, but behavioral traits beyond the core action are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core action, and contains no redundant or filler words. Every sentence provides essential information about what the tool does and its optional parameter.

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?

The tool has only 2 parameters, no nested objects, and no output schema. The description adequately explains the input semantics and the output concept (a download URL). However, it does not specify the return format (e.g., string, JSON), which could be considered a minor gap given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (theme is described in schema). The description adds meaning by explaining that 'ids' are asset IDs and that each asset results in standalone files plus a composed page. However, it does not elaborate on the numeric constraints (maxItems, minItems) or that theme is an optional asset ID. The description partially compensates for the missing schema description of 'ids'.

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?

The description clearly states the tool builds a download URL for a .zip bundle of assets, specifying the bundle's contents (standalone index.html, asset.json, composed page.html) and an optional theme parameter. It is distinct from sibling tools like get_asset or get_embed_snippet, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contraindications. It only describes the output, not the context of use.

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

get_assetA

Get the full JSON for one asset by id: descriptor, dataSchema (row shape for data-sk-items), html/css/js when self-contained, plus embed.snippet, links.embedHtml, and links.bundle.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	asset id from search_assets

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It transparently lists return components and implies a read operation, but does not explicitly state safety, side effects, or error handling. Still adequate for a retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with main purpose, enumerates components without waste. Every word adds value.

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?

Returns a JSON with listed components; no output schema needed. Lacks error handling details, but sufficient for a simple retrieval tool with one parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. The tool description adds context ('asset id from search_assets'), but does not significantly enhance beyond schema. Baseline 3 is appropriate.

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?

The description clearly states the verb 'Get' and the resource 'full JSON for one asset', enumerating all components (descriptor, dataSchema, html/css/js, etc.). It distinguishes from siblings like search_assets (which lists many) and get_embed_snippet (focused on snippet).

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?

Implicitly indicates use when needing full asset JSON, and mentions that id comes from search_assets, linking to a workflow. Lacks explicit when-not-to-use or alternatives, but sibling names provide enough context.

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

get_embed_snippetA

Get the copy-paste embed snippet for an asset — a with example data-sk-items + the hosted sk-embed.js runtime. Replace data-sk-items with your rows (see dataSchema from get_asset).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the output format and necessary steps, but does not disclose if the tool is read-only, any permissions needed, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences deliver the purpose and usage in a front-loaded manner. No extraneous words; every sentence serves a clear purpose.

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?

Given the tool's simplicity (one parameter, no output schema), the description is complete: it explains what is returned and how to apply it (replace data-sk-items, reference get_asset for schema). No gaps remain.

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?

With 0% schema coverage, the description must compensate. It adds meaning by referring to 'for an asset', clarifying that the single 'id' parameter is an asset identifier. This is sufficient for correct invocation.

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?

The description clearly states it retrieves an embed snippet for an asset, specifying the output format (div with data-sk-asset) and how to use it. This distinguishes it from sibling tools which deal with bundles, assets, and themes.

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?

The description gives context: replace data-sk-items with rows and get dataSchema from get_asset. This implies a workflow but does not explicitly state when not to use or provide alternatives.

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

list_chart_familiesA

List Datawrapper-aligned chart families (65+) mapped to StoryKit blockTypes — each family has whenToUse, a sample variant, and sampleData. Search kind=CHART_VARIANT to find published skins for a family.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. The 'list' verb implies a read-only operation, but the description does not explicitly state safety guarantees, caching behavior, or any side effects. It adds content details (whenToUse, sample variant) but not behavioral traits beyond the basic listing action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence delivers core purpose and structure, while the second provides actionable guidance. It is well-structured and front-loaded with key information.

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 tool with no parameters and no output schema, the description is remarkably complete. It specifies the type of output (list of chart families with specific fields), mentions the count (65+), and gives a practical next-step hint (searching for CHART_VARIANT). All necessary context is covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so baseline is 4. The description adds value beyond the empty schema by explaining that each family includes 'whenToUse', a sample variant, and sampleData, and provides guidance on using kind=CHART_VARIANT for published skins. This enriches understanding of the tool's output.

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?

The description clearly states it lists Datawrapper-aligned chart families, specifies the count (65+), and notes they are mapped to StoryKit blockTypes. It differentiates from sibling tools like 'list_theme_families' and 'list_themes' by focusing on chart families. The additional note about searching for CHART_VARIANT provides specific usage context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining what the tool returns and hints at subsequent actions (searching for skins via kind=CHART_VARIANT). However, it lacks explicit guidance on when to use this tool versus alternatives, or when not to use it. No exclusions or context for sibling differentiation are provided.

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

list_theme_familiesA

List editorial theme palette families — seeded as published THEME assets for reuse in embeds and bundles.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided. Description indicates a read operation ('list') but does not disclose any behavioral traits beyond that, such as idempotency or side effects. Adequate but not enriched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise, front-loaded with action and resource. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description adequately explains what the tool does but lacks information about return format, pagination, or relationship to sibling tools. Could be more complete.

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?

No parameters exist, so schema coverage is 100%. Description adds no parameter info, which is acceptable given zero parameters. Baseline of 4 applies.

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?

Description clearly states the tool lists editorial theme palette families, specifying they are seeded as published THEME assets for reuse. This distinguishes it from sibling tools like list_themes (individual themes) and list_chart_families.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. Usage is implied by the name and description but lacks direct comparisons to sibling tools.

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

list_themesA

List published StoryKit themes (palette + vibe) for composing a page or bundle export.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description must convey behavior. The action 'list' implies a read-only operation, and the description does not suggest any side effects. It is adequately transparent for a parameterless list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence. It front-loads the core action and resource, and every word adds value without redundancy.

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?

For a simple parameterless list tool, the description covers purpose and usage context. It does not detail return format, but that is acceptable given the tool's simplicity and the absence of an output schema. It is sufficiently complete.

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?

There are no parameters, so schema coverage is 100% trivially. The description adds meaning by defining what 'themes' are ('palette + vibe'), which goes beyond the empty schema. Baseline 4 is appropriate.

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?

The description clearly states the action ('List'), the specific resource ('published StoryKit themes'), and explains their nature ('palette + vibe'). It distinguishes from the sibling 'list_theme_families' by specifying 'StoryKit themes', making the purpose unambiguous.

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?

The description provides clear context when to use the tool: 'for composing a page or bundle export'. While it does not explicitly state when not to use or list alternatives, the use case is well-defined and sufficient given the tool's simplicity.

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

search_assetsA

Search the StoryKit design library. Returns matching blocks (id, name, kind, blockType, embed snippet, dataSchema when the asset accepts rows). Kinds: CHART_VARIANT, ANIMATION, TEXT_STYLE, THEME, COMPONENT, SVG, INTERACTIVE. INTERACTIVE covers the animated/self-contained widgets: draggable knobs + gauges + faders, skeuomorphic controls, blueprint cutaways, maps, quizzes. Sort: newest (default), used, name. Paginate with page + size (max 50).

ParametersJSON Schema

Name	Required	Description
`kind`	No
`page`	No
`size`	No
`sort`	No
`query`	No	free text, e.g. "column chart" or "stat row"

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It describes the returned data and parameters but does not disclose behavioral traits like read-only nature, performance implications, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and well-structured logically: purpose, return fields, kinds (with extra detail for INTERACTIVE), sort, and pagination. Every sentence adds value.

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?

Given the complexity and lack of output schema, the description covers all parameter details and return fields adequately. It could mention error handling or empty results, but overall it is complete for a search tool.

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?

With only 20% schema description coverage, the description adds significant value by detailing enum values for kind and sort, explaining pagination parameters (page, size with max 50), and providing a query example, though it could specify default page value.

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?

The description clearly states the tool searches the StoryKit design library and specifies the returned fields, listing kinds, sort options, and pagination, effectively distinguishing it from sibling tools like get_asset and list_chart_families.

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?

The description provides clear context on what the tool does, including supported kinds and sort order, but does not explicitly state when to use this tool versus alternatives or mention exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Jul 7, 2026
- First observedbundle_url
- First observedget_asset
- First observedget_embed_snippet
- First observedlist_chart_families
- First observedlist_theme_families
- First observedlist_themes
- First observedsearch_assets

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-07 20:55 across 7 tools

Disambiguation5/5

Each tool targets a distinct function: bundle URL generation, asset retrieval, embedding, and various listing/search operations. No overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase underscores (bundle_url, get_asset, list_chart_families, etc.), making naming predictable.

Tool Count5/5

7 tools cover key operations without redundancy, suitable for a design library and bundle generation service.

Completeness4/5

Covers retrieval, search, and bundle creation for assets, but lacks tools for creating, updating, or managing assets, which may be intentional but leaves some gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
asset-auto-generator
io.github.TranThienTrong
An MCP server that provides asset auto generator
Developer Tools App Automation
2
StorydocOAuth
com.storydoc
Generate and manage Storydoc presentations from any MCP-compatible client.
Marketing Workplace & Productivity
2
HubSpot Integrations MCP A
io.github.Centrify-Internal
MCP server for the HubSpot Integrations Center HubDB: search and retrieve integration data.
Search Databases Marketing
22

Related MCP Servers

spline-mcp
Design Tools Developer Tools
lesleslie
A
license
Not graded
quality
B
maintenance
MCP server for Spline.design code generation and asset management.
Updated 10 days ago (2026-08-31 23:32 UTC)
4
BSD 3-Clause
user-majico-mcpofficial
Design Tools Marketing
majico-xyz
A
license
Not graded
quality
B
maintenance
MCP server for Majico.xyz that enables coding agents to read (and limited write) brand guidelines, design tokens, studio canvas, and export manifests.
Updated a month ago (2026-08-12 08:00 UTC)
11
MIT
Streamline MCP Serverofficial
Design Tools Search
webalys-hq
F
license
Not graded
quality
B
maintenance
Enables searching, retrieving, and downloading Streamline's icons, illustrations, elements, and emojis in PNG or SVG formats with customization options, via MCP-compatible clients.
Updated a month ago (2026-07-28 14:28 UTC)
-
asset-finder-mcp
Search Developer Tools
Erfangit23
A
license
A
quality
C
maintenance
All-in-one asset search MCP server for AI coding agents, enabling search for icons, logos, stock photos, vectors, and emoji from a single tool call.
Updated a month ago (2026-08-05 13:45 UTC)
8
2
MIT

storykit-mcp

CRITICAL: which endpoint?

Connect

Remote Studio (HTTP — preferred for images)

Remote public widgets only

Local stdio (widgets always; Studio when key is set)

HARD RULES for agents

Public tools (no key)

Studio tools (STORYKIT_API_KEY)

Account & image status

Media library

Image AI

Image workflow

Prompt / vision

Brands

Canvases

Studio assets (commissioned widgets)

Series & workflows

Environment

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

user-majico-mcpofficial

Streamline MCP Serverofficial

Studio tools (`STORYKIT_API_KEY`)