List every component shipped by petal_components, the shadcn-style component library for Phoenix LiveView. This is the canonical Phoenix UI vocabulary - call it before composing any HEEx so you reach for an existing component instead of hand-rolling Tailwind divs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 clearly implies a read-only list operation with no side effects, but it does not explicitly state the return format, permissions, or any potential limitations. The extra context about being the canonical vocabulary adds value but is not comprehensive.
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 description is two sentences, each earning its place: the first states the precise function, the second provides essential usage motivation. There is no fluff or redundancy.
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 zero-parameter list tool with no output schema, the description is complete. It conveys what the tool does, when to use it, and why it matters, giving the agent a clear mental model for invocation.
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?
The tool has zero parameters, and the schema fully covers this with an empty object. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to convey; the description does not need to compensate.
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 states the tool lists every component shipped by petal_components, specifying the resource and scope. It also positions the tool as the canonical Phoenix UI vocabulary, which distinguishes it from siblings like get_component and get_install_instructions.
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 provides explicit usage context: 'call it before composing any HEEx' to avoid hand-rolling Tailwind divs. However, it does not explicitly mention alternatives or when not to use the tool, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: listing all components, getting details for a specific component, and providing installation instructions. There is no overlap or ambiguity between them.
All tool names follow a consistent imperative verb-noun pattern (get_component, list_components, get_install_instructions). The naming is uniform and predictable.
With exactly 3 tools, the server is tightly scoped to its purpose of supporting petal_components usage. Each tool earns its place and the count is well within the ideal range.
The server covers the essential needs for working with petal_components: discovering components, understanding their schemas, and setting up the library. No critical gaps are apparent for the server's stated mission.
