Skip to main content
Glama

component-usage-doc

Access usage documentation for shadcn-vue components and charts to understand implementation details and integration requirements.

Instructions

read usage doc of a component, Use this tool when mentions /doc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYestype of the component
nameYesname of the component in lowercase

Implementation Reference

  • Handler function that creates component documentation using ComponentServices.createComponentDoc and opens it in the browser using WebViewService.openMarkdownInBrowser, then returns the documentation content.
    execute: async (params) => {
      try {
        const processedDoc = await services.ComponentServices.createComponentDoc(
          params.name,
          params.type
        );
    
        // 在浏览器中打开markdown文档
        const componentTitle = `${params.name} - shadcn/vue Component Documentation`;
        await services.WebViewService.openMarkdownInBrowser(
          processedDoc || "No documentation found for this component",
          componentTitle
        );
    
        return {
          content: [
            {
              type: "text",
              text: `${processedDoc}`,
            },
          ],
        };
      } catch (error) {
        console.error("Error executing tool:", error);
        throw error;
      }
    },
  • Zod input schema validating type as 'components' or 'charts' and name as valid shadcn-vue component using ComponentServices.isValidComponent.
    parameters: z.object({
      // components | charts
      type: z.enum(["components", "charts"]).describe("type of the component"),
      name: z
        .string()
        .describe("name of the component in lowercase")
        .refine((name) => services.ComponentServices.isValidComponent(name), {
          message: "Component must be a valid shadcn/vue component",
        }),
    }),
  • Registration of the 'component-usage-doc' tool using server.addTool, including name, description, parameters schema, and execute handler.
    server.addTool({
      name: "component-usage-doc",
      description: "read usage doc of a component, Use this tool when mentions /doc.",
      parameters: z.object({
        // components | charts
        type: z.enum(["components", "charts"]).describe("type of the component"),
        name: z
          .string()
          .describe("name of the component in lowercase")
          .refine((name) => services.ComponentServices.isValidComponent(name), {
            message: "Component must be a valid shadcn/vue component",
          }),
      }),
      execute: async (params) => {
        try {
          const processedDoc = await services.ComponentServices.createComponentDoc(
            params.name,
            params.type
          );
    
          // 在浏览器中打开markdown文档
          const componentTitle = `${params.name} - shadcn/vue Component Documentation`;
          await services.WebViewService.openMarkdownInBrowser(
            processedDoc || "No documentation found for this component",
            componentTitle
          );
    
          return {
            content: [
              {
                type: "text",
                text: `${processedDoc}`,
              },
            ],
          };
        } catch (error) {
          console.error("Error executing tool:", error);
          throw error;
        }
      },
    });
  • Core helper function that fetches the full component documentation, retrieves usage demos, replaces ComponentPreview tags with demo code, and returns processed markdown.
    static async createComponentDoc(name: string, type: string) {
      const doc = await this.readFullComponentDoc({
        type: type,
        name: name,
      });
      const demos = await this.fetchUsageDemo(name);
    
      // 将文档中的 <ComponentPreview name="组件名" /> 替换为对应的 demo 代码
      // 确保demos是数组类型
      const demosArray = Array.isArray(demos) ? demos : [];
      const processedDoc = this.replaceComponentPreviewsWithCode(doc, demosArray);
      return processedDoc;
    }
  • Helper function that converts markdown to HTML, creates a styled webpage, saves to temp file, and opens it in the browser.
    static async openMarkdownInBrowser(
      markdownContent: string,
      title: string = "Component Documentation"
    ): Promise<void> {
      try {
        // 将markdown转换为HTML
        const htmlContent = await marked(markdownContent);
    
        // 创建完整的HTML页面
        const fullHtml = this.createHtmlPage(htmlContent, title);
    
        // 创建临时文件
        const tempDir = os.tmpdir();
        const tempFilePath = path.join(tempDir, `component-doc-${Date.now()}.html`);
    
        // 写入HTML文件
        fs.writeFileSync(tempFilePath, fullHtml, "utf8");
    
        // 在浏览器中打开
        await open(tempFilePath);
    
        console.log(`Documentation opened in browser: ${tempFilePath}`);
      } catch (error) {
        console.error("Error opening markdown in browser:", error);
        throw error;
      }
    }
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It implies a read-only operation ('read usage doc'), but doesn't specify what the output contains (e.g., documentation text, links, examples), whether it requires authentication, or if there are rate limits. For a tool with no annotations, this leaves significant behavioral gaps, though it correctly indicates a read action.

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 very concise with two short phrases, making it easy to parse. However, the second phrase 'Use this tool when mentions /doc' is somewhat cryptic and could be clearer. Overall, it's front-loaded with the core purpose and wastes no words, earning a high score for efficiency despite minor clarity issues.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., documentation content, format, or errors), which is critical for a read operation. With 2 parameters fully covered by the schema, the main gap is output behavior, making this inadequate for agent use without additional context.

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 clear descriptions for both parameters ('type' with enum values and 'name' as component name in lowercase). The description adds no parameter-specific information beyond what the schema provides, such as examples or usage tips. Given high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'read usage doc of a component' which provides a clear verb ('read') and resource ('usage doc of a component'), establishing the basic purpose. However, it doesn't distinguish this tool from potential siblings like 'component-quality-check' or 'requirement-structuring' that might also involve documentation or component analysis. The purpose is clear but lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description includes 'Use this tool when mentions /doc', which gives a specific trigger but no broader context. It doesn't explain when to use this versus alternatives (e.g., 'component-quality-check' for quality issues or 'requirement-structuring' for requirements), nor does it provide exclusions or prerequisites. This is minimal guidance that doesn't help the agent choose between sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HelloGGX/shadcn-vue-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server