list_commandsList every command available in the FigCraft app, including ID, label, menu, shortcut, and parameter docs. Filter results by keyword to find the command you need.
Every command the FigCraft app can run (561 of them): id, label, menu, shortcut and parameter doc. Filter with filter.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does: it discloses the total result size (561) and the shape of each entry, implying the call returns the full catalog rather than a page. It does not state whether the list is paginated or ordered, which is a minor remaining 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?
One front-loaded sentence plus a four-word follow-up. The return fields and the filtering instruction are both given without a wasted clause.
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 optional parameter and no output schema, the description covers what an agent needs: the resource, its scale, and the fields returned. The only substantive omission is how `filter` matches, which would be required for confident use.
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 0% for the single `filter` parameter, so the description must carry the semantics and only says to filter with it. It never specifies matching behavior — substring vs. exact vs. regex, case sensitivity, or which fields (id, label, menu) are searched.
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 and resource ('every command the FigCraft app can run') plus the exact fields returned (id, label, menu, shortcut, parameter doc), so an agent immediately knows this is a catalog lookup rather than an executor. It never names its obvious sibling run_command, so differentiation is implied by 'can run' rather than stated.
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?
'Filter with `filter`' is the only usage hint, which is a functional cue rather than a when-to-use rule. Nothing tells the agent to call this first to discover an id before run_command, nor when filtering is preferable to fetching all 561 entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.