Skip to main content
Glama

Tseha

by io.tseha

Get component spec

get_component
Read-only

Returns the full specification for one component: import path, props schema, usage example, anti-patterns, when-to-use and when-not-to-use notes, Figma spec, and dependencies. Read-only. Call it before writing code that uses a component, so props and import path come from the design system instead of memory. The name argument must be the exact component name as returned by list_components or search_components (case-sensitive, no package prefix); an unknown name returns a not-found error rather than a near match, so resolve the name first with search_components if you are guessing. The result may carry a provenance warning when the record was LLM-generated and not yet reviewed - treat those fields as unverified. It covers one component at a time; use list_components to enumerate and get_component_updates for version-to-version changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesExact component name, e.g. "Button"
project_idYesUUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project not found or access denied" rather than empty data, and a project withheld by a plan limit returns a plan error that retrying cannot clear. The component must belong to a package assigned to this project; a name that exists elsewhere in the organization is still not found here.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Project ID from list_projects"New value: +"UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns \"Project not found or access denied\" rather than empty data, and a project withheld by a plan limit returns a plan error that retrying cannot clear. The component must belong to a package assigned to this project; a name that exists elsewhere in the organization is still not found here."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With only readOnlyHint in the annotations, the description carries the full behavioral burden and delivers thoroughly: it confirms read-only semantics, discloses exact-match case-sensitive name lookup with a not-found error instead of near matches, warns about provenance of LLM-generated records to treat as unverified, and documents project-scoped error behavior including plan errors retrying cannot clear.

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?

Six sentences, each earning its place. The key purpose and read-only safety statement are front-loaded, followed by param semantics, provenance caveat, and routing rules — no filler and no duplication of schema content.

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 two-parameter tool with no output schema and only readOnlyHint by design, the description fully covers what is returned, when to call it, how to prepare inputs, error outcomes, and provenance caveats. An agent can select and invoke this tool correctly from the description alone, with the 100%-covered schema providing remaining parameter-level detail.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful context above — name must be exactly as returned by list_components or search_components (case-sensitive, no package prefix, no near-match fallback) and recommends resolving the name first when in doubt. This is useful but incremental beyond the already-rich schema text.

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 states a specific verb-plus-resource: 'Returns the full specification for one component' and enumerates the delivered contents (import path, props schema, usage example, anti-patterns, when-to-use notes, Figma spec, dependencies). It also distinguishes itself from sibling tools by naming what it is not for: enumerating components and per-version changes.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance is included: 'Call it before writing code that uses a component' so props and import paths come from the design system instead of memory. It also gives explicit alternatives with conditions — use list_components to enumerate, get_component_updates for version changes, and search_components to resolve a guessed name before calling this tool.

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

All Tseha toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool has a clearly distinct resource and role: enumeration (list_*), lookup (get_*), search, updates, and metadata. Even the closely related list_components and search_components are sharply separated by exact-name enumeration versus ranked by-use-case search.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, using either list_* for enumerations or get_* for single-item or metadata lookups. Naming choices clearly signal the operation type and resource without exceptions.

Tool Count5/5

With 9 tools, the server is well-scoped for read-only access to a project's design system, component catalog, standards, and style tokens. Each tool has a distinct responsibility and none feel redundant or superfluous.

Completeness5/5

The surface fully covers the read-only domain: project discovery, package listing, component enumeration and search, component details, version updates, standards, and style tokens. It leaves no obvious dead ends for an agent needing design system information.

Resources