Skip to main content
Glama
Sign In
kodza

kodza

by kodza-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Get a Kodza component

get_component
Read-only

Fetch a Kodza UI component's HTML, CSS, JS, API, keyboard behavior, dark-mode values, and install notes by slug, with options to exclude inline files and target a stack.

Instructions

The full code of one Kodza component (HTML, CSS and, when it has one, vanilla JS), its API (CSS variables with defaults, modifier classes, data attributes, events), what each key does when it takes the keyboard, its dark-mode values and its install notes. Its CSS and JS are also available as files at the URLs listed in its Files section; with inline: false, the answer leaves them out of the Code section. target narrows the install notes to one stack.

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": {
      "slug": "<slug>"
    },
    "name": "get_component"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe component slug, from search_components (e.g. "button-fill")
inlineNofalse: the Code section leaves out the CSS and JS, which stay available as files at the listed URLs. true by default: the whole code inline
targetNoWhere it goes: html (a plain page), artifact (a Claude artifact on claude.ai), wordpress, shopify or react. All of them when omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.4
    • changedInput schema / properties / inline / description
      Previous value: -"false: leave the CSS and JS out of the Code section (you download those files with the given commands). true by default, for assistants that cannot run commands"New value: +"false: the Code section leaves out the CSS and JS, which stay available as files at the listed URLs. true by default: the whole code inline"
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context beyond them, namely that the payload includes a Files section with URLs, that inline: false suppresses CSS/JS from the Code section while keeping the files reachable, and that target narrows install notes to a single stack. It stops short of describing response size, pagination or failure modes for an unknown slug.

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?

Three sentences, front-loaded with what the component payload contains before moving to file URLs and parameter effects. Dense but each clause carries information; the long parenthetical enumerating API elements is the only mildly crowded part.

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 single-entity fetch with a fully documented three-parameter schema, readOnly annotations, and no output schema, the description covers what comes back, how to get code as files instead of inline, and how target affects install notes. 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already defines all three parameters, and the description largely restates inline and target rather than adding syntax or format detail. It does add a small amount of meaning by tying inline to the 'Code section' and target to narrowing 'install notes', which is why it sits at the baseline rather than below it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (one Kodza component) and enumerates exactly what is returned: HTML, CSS, optional vanilla JS, API surface, keyboard behavior, dark-mode values and install notes. It does not name the sibling search_components as the discovery step (that only appears in the slug schema description), so the differentiation from the search tool is implied rather than stated.

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?

Usage is implied by phrasing like 'Its CSS and JS are also available as files at the URLs listed in its Files section' and 'with inline: false, the answer leaves them out', which tells the agent how to pick between inline and file-based retrieval. However, there is no explicit statement of when to call this versus search_components, nor any prerequisite such as needing a slug from a prior search.

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

Deploy Server

Other Tools