Skip to main content
Glama

Get a component

mzizi_get_component
Read-onlyIdempotent

Fetch one component in full, Rust first. When the component has a Mzizi Roots (Rust) implementation, rust comes first: its crate, the cargo add line, its CONTRACT clause block and the .rs source inline. astro follows when the component has a pure Astro implementation (mzizi-registry#397): its mzizi add --target astro line, the files it installs into src/components/mzizi/ and their dependencies; null otherwise. react follows: the React build (deprioritised; it keeps working, new work goes to Rust), shadcn-shaped with files[] inline, its npx shadcn add line, and vendor: the registry commit, each file's install target, sha256 and a raw URL pinned to that commit, each @/ import with the dependency that installs it, and the live API item URL (labelled live: it can serve a different commit). Each sha256 is of the registry source at path@ref; a file shadcn add writes can differ (it strips "use client" under rsc: false and rewrites aliases). With no Rust, rust is null and lead is "react". Add docs (use cases, variants, a11y: the documented contract) and version history (from the changelog) with include. Former nyuchi-* names resolve to their mzizi-* successors.

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

Input Schema

NameRequiredDescriptionDefault
nameYesComponent name, e.g. 'button'.
includeNoExtra sections to fetch. Omit for the implementations only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / name / maxLength
      Added value: +200
  2. Changed1 schema field changed
    • changedInput schema / properties / include / description
      Previous value: -"Extra sections to fetch. Omit for metadata only."New value: +"Extra sections to fetch. Omit for the implementations only."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behaviour, and the description adds genuine context beyond them: null-vs-populated fields per implementation, the `lead` fallback when no Rust build exists, that the raw URL and sha256 are pinned to a registry commit, and that the `live:` URL may serve a different commit. It does not describe error behaviour for an unknown component name, which keeps it below a 5.

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

Conciseness3/5

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

The opening sentence is well front-loaded, but the body collapses a deeply nested return shape into one dense paragraph of backticked fragments with no line breaks or grouping, making it hard to scan. Every clause carries information (there is no output schema to fall back on), but the lack of structure costs readability.

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?

With no output schema, the description carries the full burden and largely meets it, specifying per-language payload shapes, the vendor/commit pinning model, and the docs/versions inclusions. Gaps remain around failure cases (unknown or ambiguous names, case sensitivity) and how `lead` interacts with the requested `include` sections.

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?

Schema coverage is 100%, so the enum values are already documented, but the description still adds meaning: `include` is explained in terms of what each value actually returns (use cases, variants, a11y contract; version history from the changelog) and the default of omitting it. `name` gains semantics through the note that former nyuchi-* names resolve to mzizi-* successors.

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?

"Fetch one component in full" gives a specific verb and resource, and the word "one" plus "in full" cleanly separates it from mzizi_list_components and mzizi_search, which return collections or partial matches. It also names the legacy-alias resolution behaviour, so an agent knows this is the canonical single-record lookup.

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 effectively tells the agent to add `include` when docs or changelog sections are needed, and that omitting it returns implementations only — that is real routing guidance. It never explicitly names a sibling tool or states when not to use this one (e.g. use list_components to discover a valid `name`), so it stops short of full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources