The docs, rules, blocks, charts and design tokens of nuvui, a React UI library, for coding agents.
Scored across 11 tools
Most tools are clearly separated by action and resource: list_* discovers pages/blocks/charts, get_* retrieves concrete files or reference pages, and search_docs finds sections. There is minor overlap between get_page and get_rules because both can return prose guidance, and get_page is broad enough to cover components and guides, but the descriptions make the intended boundaries reasonably clear.
All tool names use consistent snake_case and follow a predictable verb_noun pattern: get_block, get_changes, get_chart, get_page, get_rules, get_tokens, list_blocks, list_charts, list_components, list_guides, search_docs. No mixed conventions or vague standalone verbs appear.
Eleven tools is a well-scoped count for a documentation/reference server covering discovery, retrieval, search, rules, tokens, blocks, charts, and changelogs. Each tool appears to earn its place without excessive fragmentation.
The surface covers the full documentation-consumption lifecycle: list components/guides/blocks/charts, search sections, retrieve pages, files, tokens, rules, and changelog information. There are no obvious dead ends for an agent working with the NuvUI reference.
A block's files in full, the packages they need, and the command that adds it to a project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A block's name from list_blocks, such as sign-in. | |
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. With no output schema present, the description usefully carries the return-shape burden by naming the three payload components (files, packages, install command), which is real context beyond the annotations. It stops short of noting size or rate characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact clause with no filler, and the most important information (the full file contents) leads. It is arguably too terse as a fragment rather than a sentence, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool whose annotations cover safety and whose parameters are fully documented, the description supplies the missing piece: what the response contains. Minor gaps remain around response size or formatting, but nothing essential to invoking it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters carry examples, patterns, and default behavior ('leave it out for the latest release'), so the schema does the heavy lifting. The description adds nothing about name or version semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (a block) and enumerates exactly what is returned: its files in full, the packages they require, and the install command. That content list clearly distinguishes it from sibling list_blocks, which only enumerates names. It lacks an explicit action verb, but the retrieval intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus the obvious alternative, list_blocks, or when a specific version argument matters. The agent must infer the list-then-fetch workflow on its own. The 'full files' phrasing hints at a detail view, but no condition or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What each @nuvui/* package added and changed after the versions a project has, from the packages' changelogs, newest first, and what's in the docs but in no release yet. Pass the @nuvui/* entries of the project's package.json. Without them: the latest version of each package.
| Name | Required | Description | Default |
|---|---|---|---|
| installed | No | The @nuvui/* packages in the project's package.json, with their versions as written there, such as { "@nuvui/react": "^0.6.0", "@nuvui/table": "0.1.6" }. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds genuinely non-structural facts: results are newest-first, sourced from changelogs, and include doc'd-but-unreleased items. It stops short of describing response shape or how much is returned per package, which keeps it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns, followed by parameter usage and the fallback — no filler. The dense relative clause in sentence one costs a little readability but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a nested 16-key object parameter, the description carries responsibility for explaining what comes back, and it does state content, ordering, and source. It's a bit thin on grouping/response structure per package, but an agent can call it correctly from what's given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's own description already shows the package.json-shaped example, so the description largely restates it. The one addition the schema cannot express is the omission default ('the latest version of each package'), which is why this is a solid baseline rather than a 4-5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (what each @nuvui/* package added and changed) and pins down the data source (changelogs, docs-unreleased items), which is clearly distinct from the sibling read tools (get_page, get_tokens, search_docs). The first sentence's grammar ('after the versions a project has') makes it slightly harder to parse than it needs to be, but the domain and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent exactly what to pass ('the @nuvui/* entries of the project's package.json') and what happens on omission ('the latest version of each package'), which is real usage context. It doesn't mention when to reach for search_docs or get_rules instead, so the alternative-routing dimension is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A chart's file in full, such as bar/stacked, from list_charts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A chart's id from list_charts, such as bar/stacked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and title 'Read a chart', so the safety profile is fully covered. The description adds 'in full', usefully signaling complete file content rather than a summary, but says nothing about return format or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the key qualifier 'in full' is front-loaded. It reads as a fragment rather than a sentence, which slightly hurts clarity but keeps the definition tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one fully-documented parameter, complete safety annotations, and no output schema, relatively little is required. Still, the description never characterizes what the returned 'file' contains or how a chart type like bar/stacked maps to a file, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the parameter is documented as 'A chart's id from list_charts, such as bar/stacked.' The description largely restates this same information, adding no format or syntax detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The fragment 'A chart's file in full' conveys the resource (a chart) and implies full retrieval, but the verb is implicit and the phrasing is grammatically incomplete. Naming 'from list_charts' gives sibling context, though it does not clearly distinguish this from the other get_* tools beyond the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the phrase 'from list_charts', which hints that chart identifiers come from that tool. There is no statement of when to use this versus list_charts (summary vs full) or any prerequisite/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One page of the reference, as Markdown: a component's parts, props, examples, CSS variables, classes and accessibility, or a guide. Takes a page's id from list_components, list_guides or search_docs, or a component's name, such as Compare or DataTable. A section gives only that part of the page, such as Props or CSS variables.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | A page's id, such as components/compare, or a component's name. | |
| section | No | A `##` heading on the page, such as Props, Accessibility or CSS variables. | |
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds value beyond them by disclosing the return medium ('as Markdown') and the effect of a section ('gives only that part of the page'), which matters because there is no output schema. It does not discuss errors or unknown-page behavior, but that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences that establish the return shape before the input mechanics; every clause carries information. The comma-heavy enumeration of page contents is slightly dense but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains what comes back (Markdown page content) and how to obtain valid ids, and annotations carry the safety profile. The only real omission is failure behavior for a nonexistent page or section, which is minor for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by explaining that 'page' accepts either an id or a component name, and that 'section' narrows the output to one '##' heading area rather than changing the resource. That is genuine semantic lift over the field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('One page of the reference, as Markdown') and enumerates exactly what a page contains (parts, props, examples, CSS variables, classes, accessibility). This clearly separates it from siblings like get_block, get_tokens, get_chart or get_rules, which the agent can rule out without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent to the right inputs explicitly: 'Takes a page's id from list_components, list_guides or search_docs, or a component's name.' That is clear context for when to use it and what precedes it. It stops short of stating exclusions or when to prefer a sibling (e.g. get_block) instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. Without a topic: the versions these docs describe, what to know before writing code with nuvui, the packages, the rules in a line each, and which component meets which need. With a topic: that rule in full, with wrong and right code.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | One of: accessibility, composition, forms, packages, server-components, styling, text-and-direction. | |
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds real behavioral value by describing exactly what each mode returns (versions, packages, one-line rules, component mapping vs. a full rule with wrong/right code), which goes beyond the annotations. It does not mention error behavior or pagination, keeping it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The imperative 'Start here.' is front-loaded and the two mode clauses are tightly parallel. The overview list is somewhat long and comma-heavy, but each item adds information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and does so for both modes, and both input parameters are documented. It is essentially complete for a low-complexity, zero-required-parameter read tool; only an explicit relationship to sibling lookup tools is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the schema only lists topic enum values, while the description explains that supplying a topic switches the response from an overview to a single full rule. The version parameter is left entirely to the schema, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the resource (the rules/docs for using nuvui) and even the ordering role ('Start here'), distinguishing it as the entry-point tool. It never states a crisp verb like 'retrieve' and does not name any sibling, so an agent must infer how it differs from search_docs or list_guides, which is why it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit context for both call modes: call without a topic for the overview, call with a topic to get that rule in full. That is genuine when-to-use guidance tied to the parameter. It stops short of naming alternatives (search_docs, list_guides) or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The design tokens as CSS custom properties, for your own CSS: var(--color-primary), never a color written out. A prefix gives only those, such as --color-, --radius- or --text-.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | ||
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the output format (CSS custom properties, never literal colors) and the filtering behavior of prefix, which is useful context. It does not describe pagination or the full shape of the returned token set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences; the return format is front-loaded and the prefix behavior follows. The phrasing "never a color written out" is slightly indirect but earns its place as a usage constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 must characterize the return value — and it does, as CSS custom properties with an example. Combined with annotations covering the safety profile and the schema documenting version, this is nearly complete for a simple read tool; only the structural shape of the returned list is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
prefix is undocumented in the schema, but the description compensates by explaining that it returns only matching tokens and giving concrete examples (--color-, --radius-, --text-). The version parameter is fully described in the schema itself. Meaningful added value beyond the schema for the uncovered parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource concretely: design tokens delivered as CSS custom properties, with an example (var(--color-primary)). This is clearly distinct from the block/chart/page/rules siblings without needing to name an alternative. It stops short of framing itself against any specific sibling, so a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"for your own CSS" and the prefix examples imply the intended use (consuming token values rather than hardcoding colors), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Blocks are screens and parts of apps built from the components, such as a sign-in screen, a dashboard or a pricing table, each a TSX file and an SCSS file to copy and change. Look here before building a screen from nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. | |
| category | No | One of: 3d, accounts, calendar, chat, dashboard, data, editor, flows, layout, marketing, media, settings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description usefully adds that blocks are copyable TSX/SCSS assets, but it does not describe result structure, pagination, or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no filler. The definition is front-loaded enough, though starting with the action ('Lists blocks...') could make the purpose even faster to grasp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what a returned block entry contains beyond being a screen/part with TSX and SCSS files. For a list tool with fully documented optional filters, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so version and category are already fully documented in the schema. The description adds no further detail about how filtering by version or category affects the returned blocks, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines the resource clearly: blocks are screens/app parts built from components, each with a TSX and SCSS file. It does not explicitly say 'lists blocks' or differentiate this listing tool from get_block/list_components, but the examples and file format make the resource recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage cue: 'Look here before building a screen from nothing.' That tells the agent when this discovery tool is appropriate, though it does not name alternatives like get_block or list_components for further inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Charts built with @nuvui/charts on Recharts, each one file to copy: area, bar, line, pie, radar, radial, scatter and more.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | One of: area, bar, line, pie, radar, radial, tooltip, composed, scatter, dashboard. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the burden is lighter. The phrase 'each one file to copy' adds useful context that the result is copyable source, but nothing is said about filtering behavior, result size, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no wasted words, and the resource identification is front-loaded. It is slightly under-specified rather than over-long, which is the better failure mode.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with annotations covering safety and no output schema, most of what an agent needs is present, but the description omits what a listing returns and how the optional family filter behaves. The trailing 'and more' is also vaguer than the schema's explicit value list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 'family' parameter and its allowed values are fully documented in the schema. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Recharts-based chart components from @nuvui/charts) and hints at the payoff ('each one file to copy'), but never states the verb 'list' or that it returns a catalog. Against siblings like list_components and list_guides there is no differentiation, so an agent cannot tell these apart from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus alternatives. The obvious sibling get_chart (fetch a single chart) is never mentioned, nor is the family-scoping behavior explained as a selection criterion. The agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every component page, by package, with what each is for in a line. Pass a package to see only its pages.
| Name | Required | Description | Default |
|---|---|---|---|
| package | No | A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/3d, @nuvui/scheduler, @nuvui/icons. | |
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuine behavioral detail that the annotations do not: each result carries a one-line purpose summary. It says nothing about ordering, result size, or whether packages with no components 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the scope statement leads before the optional filter. The phrasing "Every component page, by package" is slightly compressed to the point of ambiguity about grouping versus filtering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return shape; "what each is for in a line" covers part of that but says nothing about what else each entry contains (name, path, package grouping). For a two-parameter listing tool the description is adequate but leaves the agent guessing about result structure and the version parameter's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the enum of package names and the version pattern are fully documented in the schema, making 3 the baseline. The description's "pass a package to see only its pages" merely restates the schema's filter semantics, and the version parameter is never mentioned at all in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (component pages) and what each entry includes (a one-line purpose), which is enough to tell it apart from get_page or search_docs. It never states the verb (list/browse) explicitly or contrasts itself with siblings like list_blocks, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Pass a package to see only its pages" gives a usage hint but only about filtering, not about when this tool is preferable to get_page, search_docs, or list_blocks. There are no exclusions and no stated preconditions, so the agent must infer that this is the catalog-browsing entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The pages that aren't about one component: getting started, theming, Tailwind, SCSS, forms, right to left, translation, the Content Security Policy, support, and recipes for whole screens.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds only a content inventory, saying nothing about pagination, ordering, or result shape beyond what annotations and the schema imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence that defines the scope first, then enumerates topics. The topic list is long but each item earns its place by helping an agent judge relevance; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with annotations covering safety, a fully documented single parameter, and no output schema, the description is sufficient to select and call it correctly. Minor gaps (result ordering/pagination) are non-blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'version' parameter is fully documented in the schema including format and default behavior. The description adds no additional meaning about versioning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (non-component pages) and enumerates the concrete topics it covers, which lets an agent distinguish it from list_components at a glance. The verb 'list' is only implicit in 'The pages that...', so it is slightly less crisp than an explicit verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'aren't about one component' implicitly contrasts with list_components, suggesting this is for conceptual/topical docs rather than component reference. However, no alternative tool is named and there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the sections of the reference that best answer a question or a few words, such as 'sortable table', 'dark mode' or 'error message on a field'. Each result names its page and section, for get_page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| version | No | The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond them: results are section-level, each labeled with page and section identifiers, and are intended as input to another tool. It omits ranking/return-volume behavior and the default result limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and scope; the example queries are short and earn their place by showing query granularity, and the get_page follow-up closes the loop without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains the shape of a result (page + section). Together with the schema's version guidance, an agent has enough to call this correctly; only limit/pagination behavior and the absence of any exclusivity guidance leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — only 'version' is documented in the schema, while 'query' and 'limit' are bare. The description partly compensates by characterizing 'query' as a question or a few words, but says nothing about 'limit' (default 8, max 20), which is real information an agent needs to control result size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (finds) and resource (sections of the reference that answer a question), and immediately distinguishes itself from the retrieval sibling by noting results feed get_page. An agent can tell it apart from get_page, list_guides, etc. without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete example queries ('sortable table', 'dark mode') that clarify the intended usage shape, and states the follow-up (results name page/section 'for get_page'), implying a search-then-fetch workflow. It never states when NOT to use it or when to call get_page directly, so it stops short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_changes1 field changedInput schema / properties / installed / properties / @nuvui/schedulerAdded value: +{
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_blocks1 field changedInput schema / properties / category / descriptionPrevious value: -"One of: 3d, accounts, chat, dashboard, data, editor, flows, layout, marketing, media, settings."New value: +"One of: 3d, accounts, calendar, chat, dashboard, data, editor, flows, layout, marketing, media, settings."list_components1 field changedInput schema / properties / package / descriptionPrevious value: -"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/3d, @nuvui/icons."New value: +"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/3d, @nuvui/scheduler, @nuvui/icons."get_changes1 field changedInput schema / properties / installed / properties / @nuvui/3dAdded value: +{
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_blocks1 field changedInput schema / properties / category / descriptionPrevious value: -"One of: accounts, chat, dashboard, data, editor, flows, layout, marketing, media, settings."New value: +"One of: 3d, accounts, chat, dashboard, data, editor, flows, layout, marketing, media, settings."list_components1 field changedInput schema / properties / package / descriptionPrevious value: -"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/icons."New value: +"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/3d, @nuvui/icons."get_changes1 field changedInput schema / properties / installed / properties / @nuvui/backgroundsAdded value: +{
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_components1 field changedInput schema / properties / package / descriptionPrevious value: -"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/icons."New value: +"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/backgrounds, @nuvui/icons."get_block1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}get_changesget_page1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}get_rules1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}get_tokens1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_blocks2 fields changedInput schema / properties / category / descriptionPrevious value: -"One of: accounts, chat, dashboard, data, editor, flows, layout, marketing, settings."New value: +"One of: accounts, chat, dashboard, data, editor, flows, layout, marketing, media, settings."Input schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_components2 fields changedInput schema / properties / package / descriptionPrevious value: -"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/icons."New value: +"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/media, @nuvui/icons."Input schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_guides1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}search_docs1 field changedInput schema / properties / versionAdded value: +{
+ "description": "The @nuvui/react version in the project's package.json, such as 0.6.2 or ^0.6.0, for the docs of that release. Leave it out for the latest release.",
+ "maxLength": 40,
+ "minLength": 1,
+ "pattern": "^(?:\\^|~|>=|=)?v?\\d+(?:\\.(?:\\d+|x|\\*)){0,2}(?:-[0-9A-Za-z.-]+)?$",
+ "type": "string"
+}list_blocks1 field changedInput schema / properties / category / descriptionPrevious value: -"One of: accounts, chat, dashboard, data, editor, layout, marketing, settings."New value: +"One of: accounts, chat, dashboard, data, editor, flows, layout, marketing, settings."list_components1 field changedInput schema / properties / package / descriptionPrevious value: -"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/icons."New value: +"A package, such as @nuvui/table or table. One of: @nuvui/react, @nuvui/date-picker, @nuvui/table, @nuvui/charts, @nuvui/barcodes, @nuvui/chat, @nuvui/kanban, @nuvui/editor, @nuvui/emoji, @nuvui/map, @nuvui/flow, @nuvui/icons."get_blockget_chartget_pageget_rulesget_tokenslist_blockslist_chartslist_componentslist_guidessearch_docsLive React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
React components and design rules your coding agent installs and follows.
React, Tailwind CSS and shadcn/ui components, sections and landing pages for coding agents.
Mlola UI components, tokens and design rules for coding agents, with a markup checker
Add one secure layer between your agents and this server.