Server Quality Checklist

Tool Scores

• search_componentA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. It adds some behavioral guidance (always generate markup with Bootstrap Italia classes, respect accessibility notes), which is useful. However, it doesn't disclose specifics like whether the tool writes markup, mutates state, or its return shape/side effects, which for a read/search operation are less critical but still absent.

  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?

  The description is three sentences and front-loads the core purpose. Every sentence adds value (purpose, when-to-use, design-system constraints). It's efficient without being bare-bones minimal. One could argue the last sentence about not substituting tailwind is slightly wordy, but it carries genuine constraint information.

  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?

  For a single-parameter search tool with 100% schema coverage, the description is reasonably complete. It specifies the design system version (Bootstrap Italia 2.x), the search scope (name/description/tag), and output expectations (conforming markup with accessibility notes). No output schema exists, but the description sufficiently hints at what the agent should produce. It could mention pagination or result limits, but given the tool's simplicity this is adequate.

  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 coverage is 100% — the single 'query' parameter is well described in the schema with examples ('bottone', 'menu', 'form', 'avviso', 'card servizio'). The description reinforces the semantic scope (search by name, description, or tag) without duplicating the schema. Per the baseline rule, 3 is appropriate since the schema already documents the parameter adequately and the description doesn't need to compensate.

  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?

  The description clearly states the verb ('Cerca'/'search') and resource (Bootstrap Italia component by keyword), and adds useful scope: searching by name, description, or tag. It distinguishes itself from siblings like list_components (which lists rather than searches) and get_component_code (which retrieves code once you know the id). However, it doesn't explicitly differentiate from get_webcomponent or list_webcomponents, so sibling differentiation isn't complete.

  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 provides clear usage context ('Use this tool when you need to build a UI element and don't know the exact id') and gives explicit exclusions ('Don't substitute with generic Bootstrap, Tailwind, or non-conforming markup'). It doesn't explicitly name sibling alternatives, but the when-to-use guidance is concrete and actionable for the agent.

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

• get_component_codeA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It states the tool generates compliant markup and respects accessibility notes, adding behavioral context. However, it doesn't disclose whether there are constraints like unsupported components, validation requirements, or rate limits. With no annotations, some more behavioral disclosure would help.

  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?

  The description is brief and front-loaded, with the core purpose stated first. Every sentence earns its place, including the negative guidance about not substituting non-conformant markup.

  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?

  For a single-parameter, read-style retrieval tool with complete schema coverage and an output that is markup + notes, the description is reasonably complete. The design-system constraint and accessibility requirement are stated. A minor gap: it doesn't mention what happens for a non-existent component id.

  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% (single id parameter, described with example and pointer to list_components for valid ids). The description adds design-system context that the schema lacks. Since there's one simple param, the description adds marginal but useful value beyond the schema.

  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?

  The description clearly states the verb (restituisce/returns) and resource (component markup and accessibility notes for a Bootstrap Italia component given its id). It distinguishes the design system (Bootstrap Italia 2.x). However, it doesn't explicitly differentiate from siblings like get_webcomponent or list_components, though the focus on 'markup + accessibility notes' partially helps.

  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?

  The description gives implicit guidance by naming the design system (Bootstrap Italia) and instructing not to substitute with generic Bootstrap/Tailwind. However, it doesn't explain when to use this vs sibling get_webcomponent or search_component, which could overlap. Usage context is implied rather than explicit.

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

• list_componentsA
  3.7/5.0
  Behavior3/5

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

  The description reveals it's a read-only listing operation (id, name, category) which is a safe scope disclosure. No annotations are provided, so description carries the burden, but it doesn't disclose potential behaviors like whether results are paginated, ordered, or reflect multiple versions of the design system. It does convey that this is a discovery tool tied to the PA design system.

  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?

  The description is a compact 3-sentence paragraph. It front-loads the purpose, then adds usage context and constraints. Slightly verbose with the accessibility/design system reminders that may apply more broadly to generated markup than to this specific listing tool, but it's still efficient overall.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with one optional parameter and no output schema, the description is reasonably complete. However, since there's no output schema, it doesn't clarify the return shape beyond 'id, nome, categoria'. Given the sibling list_webcomponents exists, more clarity on the difference (vanilla vs web components) would improve completeness for an agent choosing between them.

  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 schema already documents the category parameter. The description adds category examples (form, navigazione, layout, contenuti, azioni, feedback) that go beyond the schema's single 'form' example, providing richer meaning about valid category values. With 100% coverage, the baseline is 3, and the added examples justify a 4.

  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?

  The Italian description is clear: it lists available Bootstrap Italia components (id, name, category). It distinguishes from siblings somewhat by focusing on the discovery/listing function, though it doesn't explicitly name an alternative like search_component for lookup-by-query use cases.

  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 explicitly says to use this tool to discover what exists before generating a UI, giving clear usage context. It also provides negative guidance (don't substitute generic Bootstrap, Tailwind, or non-conforming markup). However, it doesn't distinguish this from the sibling list_webcomponents or search_component explicitly.

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

• get_webcomponentA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does add meaningful behavioral context by declaring the output covers 'uso' (usage) and 'contratto di accessibilità' (accessibility contract), and frames the read-only nature implicitly. However, it doesn't disclose authentication requirements, caching, or error behavior.

  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?

  The description is compact (3 sentences) and front-loaded with the core purpose. No wasted words, though the brand-y 'AI-first' framing is somewhat redundant across sentences and could be trimmed.

  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?

  For a single-parameter informational/read tool with no output schema, the description is reasonably complete. It states what is returned (usage + accessibility contract), the single input, and a usage recommendation. It could benefit from noting the returned usage contains code examples and that these are framework-agnostic, but the core needs are met.

  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% and the only parameter (tag) is well-documented in the schema with an example. The description reinforces the parameter's purpose by specifying what the tool returns for a given tag and cross-references list_webcomponents for discovering tags. The description adds marginal value beyond the schema (which is already complete), so baseline 3 with slight uplift is fair.

  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?

  The description clearly states the verb ('restituisce') and resource: returns the usage and accessibility contract of a universal Web Component given its tag. It distinguishes from siblings by framing the tool as AI-first focused, though it doesn't explicitly contrast against get_component_code or search_component.

  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 gives clear usage context: 'preferisci SEMPRE questi tag ai markup grezzi quando il progetto può caricarli' provides strong guidance on when to use these components. However, it doesn't name an explicit alternative tool to use instead for other cases, so it stops short of a 5.

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

• list_recipesA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses important behavioral traits: it generates markup with Bootstrap Italia 2.x classes (not generic Bootstrap, Tailwind, or non-conforming markup), respects accessibility notes, and always follows the specified pattern. The emphasis on 'SEMER' (always) signals strict output behavior. This is meaningful behavioral context beyond what structured fields provide.

  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?

  The description is a focused block of 4 sentences that front-loads the primary purpose before adding constraints. Each sentence earns its place: purpose, definition of a recipe, design system requirements, and exclusions. Slightly verbose in the last sentence enumerating exclusions, but still tight overall.

  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?

  For a no-parameter list tool with no output schema, the description adequately covers what's needed: what gets listed, what the items are composed of, and what standards must be followed. The sibling context (get_page_recipe) suggests the agent could drill down after listing, and this description gives enough context to make that connection, though it doesn't explicitly point to it.

  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?

  The tool has 0 parameters with 100% schema coverage, so the schema carries no information to enrich. Per the rubric, 0 params = baseline 4. The description adds value by explaining what the listed items are (page recipes conformant to PA site models) and the design constraints, which helps the agent understand what to expect in the results.

  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?

  The description states a specific verb+resource ('Elenca le ricette di pagina') with clear scope ('conformi ai modelli di sito PA'). It distinguishes from siblings by focusing on page recipes vs components/webcomponents. However, it doesn't explicitly contrast with get_page_recipe or list_components, though the plural 'list' vs singular 'get' is implied.

  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?

  The description provides context about what recipes are (composing multiple components into a full page) and the design system constraints, which helps decide when to use. But it doesn't explicitly state when NOT to use it or mention alternatives like get_page_recipe for retrieving a single recipe's details. The guidance about not substituting with generic Bootstrap is more about markup standards than tool selection.

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

• validate_snippetA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the check categories (patterns, accessibility, Web Component suggestions), providing a reasonable preview of what happens. However, it doesn't state whether the tool modifies anything, whether it returns detailed reports versus simple pass/fail, or whether it auto-corrects or merely suggests corrections for the agent to apply.

  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?

  Two sentences, zero waste. The first sentence packs purpose plus four concrete check categories, the second provides actionable timing guidance. Front-loaded with the main verb and resource.

  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?

  For a single-parameter validation tool with full schema coverage and no output schema requirement (the description omits return-value details but this tool's outputs—reports/suggestions—are somewhat self-evident from its validation function), the description is complete. The usage timing guidance adds practical value. One could argue for a slightly richer description of what the feedback looks like, but the core validation scope is well covered.

  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 coverage is 100% with a single 'snippet' parameter already documented as 'Lo snippet HTML da validare.' The description adds minimal extra meaning—it clarifies the snippet should be validated for specific pattern categories and accessibility, but the schema alone already explains what the parameter is. Baseline of 3 is appropriate given the high schema coverage.

  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?

  The description clearly states the verb (controlla/validate) and resource (snippet HTML), and enumerates the specific checks performed: non-conformant patterns (Tailwind/Bootstrap generic/inline handlers), basic accessibility rules, and suggestions for AI-first Web Components. It distinguishes itself from siblings by focusing on validation rather than listing, searching, or fetching components/recipes.

  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 gives clear timing guidance: 'Chiama questo tool DOPO aver generato markup, per autocorreggerti' (call this AFTER generating markup, to self-correct). This establishes a clear usage context. However, it doesn't explicitly state when NOT to use it or name alternative tools, though the timing context strongly implies it complements the component/recipe lookup tools in the sibling set.

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

• get_accessibility_rulesA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It adds behavioral context: mandates Bootstrap Italia 2.x markup, requires conforming to the accessibility notes, and explicitly prohibits generic Bootstrap, Tailwind, or non-conforming markup. This is strong normative behavioral guidance beyond what any annotation would have provided.

  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?

  The description is compact, front-loaded with the core purpose, and adds the design-system+markup constraint in the same paragraph. While the all-caps 'SEMPRE' is emphatic, every sentence carries meaningful operational guidance with no filler.

  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?

  For a zero-required-param, single-filter, no-output-schema tool, the description adequately covers purpose, usage timing, and compliance constraints. It doesn't describe the return format, but the absence of an output schema is offset by the clear behavioral contract about Bootstrap Italia compliance and accessibility rules.

  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%, giving the baseline of 3. The description adds value by mentioning specific topic examples (form, colore, heading, landmark, focus, immagini) consistent with the filter parameter, reinforcing how topics can be used. It clarifies the parameter is a filter dimension without repeating schema details.

  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?

  The description states a specific verb ('Restituisce') and resource ('regole di accessibilità trasversali'), and clarifies it applies to every PA interface. It distinguishes itself from siblings by emphasizing accessibility rules rather than component lookup, though it doesn't explicitly name the alternative tools for other needs.

  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 gives clear when-to-use guidance ('Consulta questo tool prima di consegnare una UI') and when it applies (every PA interface). It implicitly differentiates from component tools by focusing on transversal accessibility constraints, but doesn't explicitly state exclusions or name alternatives.

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

• get_page_recipeA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses important behaviors: always generates Bootstrap Italia markup, respects accessibility notes, and composes specific page sections (header, breadcrumb, content, footer). It also states determinism ('Genera SEMPRE'). This covers the key behavioral traits an agent needs to know for safe invocation.

  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?

  The description is appropriately concise, with each sentence earning its place. It front-loads purpose, then design system constraints, then explicit negative guidance in one short, imperative sentence. No wasted words, though it could be slightly restructured for scannability.

  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?

  Given the tool has only 1 parameter, no output schema, and no annotations, the description does a solid job covering what the agent needs: what's produced (page skeleton with all sections), the design system, accessibility compliance, and explicit do-not-substitute instructions. The guidance is comprehensive for a well-defined, bounded tool.

  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% with only 1 parameter (id). The schema already documents that id is the recipe id and directs users to list_recipes for ids. The description focuses on what the tool produces rather than parameter details. Since coverage is complete, baseline 3 is appropriate — the description adds value by explaining the output context but doesn't need to compensate for schema gaps.

  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 clearly states what the tool does: returns the complete, compliant skeleton of a PA page (e.g., a municipal service page), composing header, breadcrumb, content, and footer with required links. It specifies the design system (Bootstrap Italia 2.x) and distinguishes itself from generating generic markup. This is specific and actionable.

  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 provides clear usage context (for building PA pages with mandatory links) and explicit negative guidance: 'Non sostituire con Bootstrap generico, Tailwind o markup non conforme' (don't substitute with generic Bootstrap, Tailwind, or non-conforming markup). It doesn't explicitly name alternative tools, but the sibling context (list_recipes exists) is hinted. Strong guidance overall.

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

• list_webcomponentsA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does explain that accessibility is already encapsulated, which is useful behavioral context. However, it doesn't disclose return format, whether this is a pure read/list operation, pagination, or ordering behavior for a zero-parameter listing tool. The tool is clearly a read-only listing, so moderate transparency is adequate.

  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?

  The description is reasonably concise with two solid sentences. Both sentences are meaningful and add value, repeating no schema info. The main message (list Web Components, prefer them) is front-loaded. The slight redundancy between the opening sentence and the second sentence repeating 'Web Components universali' costs a small deduction.

  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?

  For a zero-parameter listing tool with no output schema, the description does well in explaining why you'd use this (framework-agnostic, accessibility encapsulated) and when to prefer it. It could clarify what 'universali' means in terms of what gets listed (all components?) and how it relates to get_webcomponent (which presumably fetches one), but overall adequate.

  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?

  With 0 parameters, baseline is 4. The description doesn't need to explain parameters since there are none to explain. The description adequately covers what the listing returns (tags and scopes).

  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 clearly states the tool lists universal Web Components with tag and purpose. It distinguishes itself from sibling tools (list_components, list_recipes) by specifying AI-first universal Web Components that work across frameworks. The verb 'Elenca' (list) plus resource 'Web Components' is specific and clear.

  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?

  The description gives explicit guidance on when to use this: it recommends these tags as the preferred form ('forma consigliata'), states 'preferisci SEMPRE questi tag ai markup grezzi' and specifies the condition ('quando il progetto può caricarli'). It differentiates from raw markup and implies a comparison against framework-specific components.

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