Skip to main content
Glama

Open Components

by com.uxfront
OverviewDiscussionsAdmin

Get Contract

get-contract
Read-onlyIdempotent

Returns the contract of a component or a foundation, as YAML: its API (props, slots and events), its DOM contract (element, role, states, keyboard and parts), its tokens, and every rule in its checklist, each with a stable ID (like button/keep-focus), a level (must or should), a scope (component, usage or both) and how to check it. It holds every requirement in a fraction of the page's length, and it's the same file as https://opencomponents.dev/raw/docs/.yaml.

WHEN TO USE: first, before you build, review or explain a component or its tokens. WHEN NOT TO USE: for some of the rules only (by scope, layer, level or check), use list-rules. For the reasoning or the examples behind a rule, use get-page with its sections.

Input Schema

NameRequiredDescriptionDefault
componentYesThe component or foundation, like button or design-tokens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "popover",
-  "radio-group",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "field",
+  "input",
+  "popover",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "radio-group",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "popover",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "radio-group",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "radio-group",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "dialog",
-  "switch",
-  "textarea",
-  "tooltip",
-  "checkbox-group"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  6. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "textarea",
-  "tooltip",
-  "checkbox-group"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "dialog",
+  "switch",
+  "textarea",
+  "tooltip",
+  "checkbox-group"
+]
  7. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "textarea",
+  "tooltip",
+  "checkbox-group"
+]
  8. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  9. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "switch",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "tooltip"
+]
  10. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "switch",
+  "tooltip"
+]
  11. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "tooltip"
+]
  12. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description still adds real value beyond them: the return format is YAML, the payload is far shorter than the equivalent page, and the result is identical to the raw file at https://opencomponents.dev/raw/docs/<path>.yaml, which lets an agent reason about caching and provenance. It stops short of describing failure behavior for a bad component id, so not 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.

Conciseness5/5

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

Front-loads what is returned, then the size/URL equivalence, then the use and do-not-use conditions as labeled blocks. The first sentence is long but every clause names a distinct part of the payload; no sentence is filler.

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?

No output schema exists, so the description carries the full burden of explaining the return value — and it does, enumerating the YAML sections and the shape of each checklist rule (id, level, scope, check). For a single-parameter read with a closed enum, nothing an agent needs 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?

There is a single parameter with 100% schema description coverage and an enum of all 14 valid values, so the schema already does the heavy lifting and the baseline is 3. The description adds only indirect hints — that a component maps to a docs path and to ID prefixes like button/keep-focus — without documenting the parameter itself.

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?

States a specific verb and resource (returns the contract of a component or foundation) and enumerates the contents concretely: API, DOM contract, tokens, and checklist rules with stable IDs, levels and scopes. The sibling distinction is explicit — list-rules handles rule subsets and get-page handles reasoning/examples.

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?

Provides an explicit WHEN TO USE ('first, before you build, review or explain') and a WHEN NOT TO USE that names two alternatives (list-rules, get-page) along with the exact conditions that select each one. Nothing is left to inference.

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

All Open Components toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources