penpot-headless

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct operation or entity (file, page, shape, component, comment, checkpoint, media, etc.), with no overlapping purposes. Even similar tools like penpot_add_shapes and penpot_add_component_instance are clearly differentiated by their descriptions.
Naming Consistency5/5
All tools follow the penpot_{verb}_{noun(s)} pattern with imperative verbs (add, create, delete, get, list, update, etc.) and descriptive nouns. The naming is uniform and predictable across the entire set.
Tool Count2/5
With 54 tools, the set is significantly larger than the typical well-scoped range of 3-15. While the breadth of Penpot's feature set may justify many tools, the sheer number makes it unwieldy for an agent and suggests the server could benefit from consolidation or higher-level operations.
Completeness5/5
The tool surface covers the full lifecycle for files, pages, shapes, components, variants, comments, and media, plus supportive utilities like checkpoints, text measurement, and batching. There are no obvious gaps for the domain of headless Penpot operations.
Average 3.8/5 across 54 of 54 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action. It does not disclose whether deletion is irreversible, what happens to associated files, or any other behavioral traits beyond the obvious 'delete' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but under-specified. It lacks essential context, making it insufficient rather than concise. It does not earn its place because it omits important usage and behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no annotations), the description is grossly incomplete. It fails to explain what happens on deletion, the return value, or any prerequisites, leaving the agent without enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of the single parameter (projectId) at all. The description adds no meaning beyond what the schema provides, failing to compensate for the coverage gap.
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 action (delete) and the resource (Penpot project), which is specific and distinct from sibling tools like create, rename, or list. No ambiguity or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no context about when deletion is appropriate, and no mention of side effects or dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only says 'Delete a Penpot file' without disclosing permanence, side effects, or required permissions. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but is under-specified. It lacks necessary detail, making it insufficient rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool deletes files (destructive), has no annotations, no output schema, and only one unexplained parameter, the description is far from complete. An agent has too little information to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameter `fileId`. It does not, providing no added meaning beyond the schema's type and requirement.
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 'Delete a Penpot file' which specifies the verb (delete) and the resource (Penpot file). It is clear and distinguishes from siblings that operate on different resources like projects.
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?
No guidance is provided on when to use this tool versus alternatives like penpot_rename_file or penpot_delete_project. There are no hints about prerequisites or contexts where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that the tool creates a page, implying mutation. It does not disclose side effects, required permissions, validation rules, or any potential limitations. Given the lack of annotations, more detail is necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is too brief to convey essential information. Being concise is positive, but it sacrifices completeness for brevity.
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?
With only 2 parameters, no output schema, and no annotations, the description should provide more context about the expected behavior, return value, and validation. The current description leaves significant gaps for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and neither 'fileId' nor 'name' are explained in the description. The agent receives no semantic context beyond the parameter names and types, so it cannot infer formatting, constraints, or the relationship between parameters.
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?
Description clearly states the tool creates a new empty page within a Penpot file. It uses a specific verb ('Create') and resource ('page'), distinguishing it from sibling tools like penpot_create_file or penpot_create_project. However, it does not explicitly clarify that the file must already exist.
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?
No guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., file must exist). The description lacks context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must fully disclose behavior. It only states the basic action, omitting details like idempotency, permission requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, it is under-specified for a tool with two required parameters and no output schema, lacking necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description fails to explain return values, side effects, or constraints, making it incomplete for informed tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds no meaning to parameters like projectId or name, leaving the agent to infer their format or sources.
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 verb 'Create' and the resource 'a new file within a Penpot project', differentiating it from siblings like penpot_create_page and penpot_create_project.
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?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 discloses that it creates a container frame and returns component IDs, but does not mention side effects, permissions, rate limits, or any destructive behavior. For a creation tool, more behavioral context (e.g., whether it modifies existing shapes) is needed.
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 single paragraph that efficiently conveys the core concept without excessive verbosity. However, it could benefit from a more structured breakdown (e.g., bullet points for key aspects) but remains sufficiently concise.
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 the complexity (10 parameters, no output schema, no annotations), the description is incomplete. It omits details on required parameters, return value format, and prerequisites. The reference to penpot_create_component is helpful but insufficient for an agent to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not explain any of the 10 parameters except a vague reference to 'variants' accepting same specs as penpot_create_component. No parameter meanings, formats, or valid values are clarified, leaving the agent dependent solely on the schema, which lacks descriptions.
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 tool creates a variant group and explains its purpose with a concrete example (Button with Type variants). It distinguishes from sibling tools by name, but does not explicitly contrast with penpot_add_variant, so slightly less than perfect.
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 implies when to use (when you need variant groups with property axes) but provides no explicit guidance on when not to use or alternatives like penpot_add_variant. No usage context beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states 'rename' which implies a mutation, but does not disclose any side effects, permissions required, or whether the operation is reversible. Lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence), which is concise but under-specified. It is not wasteful but lacks essential details that could be added without exceeding typical length.
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 the simplicity (2 required params, no enums, no output schema), the description could still be more complete. It does not mention return value, success/failure conditions, or any constraints like name uniqueness. Incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two parameters with only minLength constraints and no descriptions. Schema description coverage is 0%. The tool description does not add any meaning beyond the parameter names, so the agent has no guidance on what valid inputs are.
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 action 'Rename' and the target resource 'existing Penpot project'. It distinguishes from sibling tools like penpot_rename_file and penpot_create_project. However, it does not specify the scope or any unique aspects.
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?
No guidance on when to use this tool versus alternatives like penpot_create_project or penpot_rename_file. No prerequisites or context for invoking the rename operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose side effects, permissions, or implications of renaming (e.g., URL changes, impact on collaborators), which is insufficient given no annotations are 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?
Description is concise with one sentence, no wasted words. However, it could be slightly more informative without harming conciseness.
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?
For a simple rename tool with no output schema and no parameter descriptions, the description lacks completeness; it does not specify return values or error conditions, leaving contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (fileId, name) beyond their types and constraints, failing to add meaning for the agent.
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?
Description clearly states the specific action (rename) and resource (existing Penpot file), effectively distinguishing from sibling tools like create, delete, list.
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?
No guidance on when to use this tool versus alternatives; lacks explicit when-to-use or when-not-to-use information, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states creation without disclosing any behavioral traits like destructive potential, authentication needs, or side effects.
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?
A single concise sentence that front-loads the action. While efficient, it could benefit from additional structure for longer descriptions.
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 the tool's simplicity (2 params, no output schema), the description is minimal but insufficient. It lacks parameter explanations and behavioral context that would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning to parameters teamId and name beyond their names. No explanation of what teamId refers to or constraints on name.
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 'Create a new project within a Penpot team' clearly states the verb (create) and resource (project within a Penpot team), distinguishing it from sibling tools like penpot_create_file and penpot_create_page.
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?
No guidance on when to use this tool vs alternatives, no prerequisites or context provided. The description lacks any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating 'List', but lacks explicit disclosure of side effects, rate limits, or pagination. Without annotations, it adequately conveys non-destructive behavior but could add safety details.
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 single clear sentence with no unnecessary words. However, it is borderline under-specified by omitting parameter details.
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 list tool, the description covers the basic purpose, but omits information about the return format, pagination, or any limitations. Given the lack of output schema, additional details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the sole parameter projectId, such as its format or how to obtain it. The description fails to compensate for missing schema documentation.
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 uses a specific verb 'List' and resource 'files' with scope 'within a Penpot project', clearly distinguishing it from sibling tools like create, delete, or rename files.
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?
No guidance is provided on when to use this tool versus alternatives, such as penpot_create_file or penpot_delete_file. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'list all projects', implying a read operation but lacks details on return format, pagination, or side effects.
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?
One sentence, no redundant information. Efficient and to the point.
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?
Missing details on output schema (no response description), auth requirements, or error handling. Incomplete given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain the teamId parameter beyond what the schema provides (string, minLength 1). No additional semantics.
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?
Description clearly states action (list) and resource (projects within a Penpot team). It distinguishes from sibling tools like list_files and list_teams.
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?
No guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. Only states the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action (edit) but omits side effects, idempotency, permissions, or error behavior. For a mutation tool, this is insufficient.
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 a single, front-loaded sentence of 17 words with no redundancy. Every word contributes to meaning.
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 output schema and low schema coverage, the description leaves critical gaps: the format of id, length limits on content, success/error responses, and whether the update is atomic or has side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not explain what the 'id' parameter refers to (e.g., comment ID or thread ID) or any constraints on 'content'. The description only gives vague context about editing text.
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 action ('Edit'), the resource ('existing comment'), and clarifies the scope (opening message or reply). This distinguishes it from sibling tools like penpot_create_comment and penpot_delete_comment.
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?
No guidance is given on when to use this tool versus alternatives (e.g., when to edit a comment vs. create or delete). Prerequisites like the comment existing or required permissions are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It fails to disclose whether this operation is destructive, what permissions are needed, rate limits, or error conditions. The description only covers function, not behavioral impact.
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 single, well-structured paragraph with no fluff. It front-loads purpose and then explains containerId source and return values. Slightly more structure (e.g., bullet points for parameters) could improve it.
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?
For a tool with 6 parameters (5 required) and no output schema, the description omits explanations for fileId, pageId, and groupName. It relies on cross-references to other tools without fully explaining the variant parameter. The agent would struggle to correctly invoke this tool without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Despite a highly complex variant parameter with extensive nested objects, the description only vaguely mentions it mirrors shape specs. It provides no guidance on required structure, property meanings, or usage patterns beyond a cross-reference to another tool.
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 verb (add) and resource (new variant to existing variant group). It distinguishes from siblings by referencing the prerequisite tool (penpot_create_variant_group) and explaining containerId origin. This makes the purpose specific and differentiated.
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 explains when to use this tool (after creating a variant group) and how to obtain the containerId. It mentions the return values link to penpot_add_component_instance. However, it does not explicitly state when not to use it or compare with alternatives like penpot_create_variant_group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the function but does not disclose side effects, idempotency, or error behavior. Acceptable for a simple rename but lacks depth.
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?
Single concise sentence with no unnecessary words. Front-loaded and clear.
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?
Minimal context provided. With no output schema and no annotations, the description omits return values, error cases, and any additional behavioral details. However, for a simple rename, it is barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions. The description does not explain the parameters (fileId, pageId, name) or their meaning, leaving the agent with only the schema names.
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?
Clearly states the verb (rename) and resource (existing page in a Penpot file). Differentiates from sibling rename tools (rename_file, rename_project) by specifying 'page'.
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?
No guidance on when to use this tool vs alternatives. Does not mention any prerequisites or 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.
Behavior2/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 only says 'add a reply comment,' which implies a write operation, but does not disclose any behavioral traits such as required permissions, side effects, or what happens if the thread does not exist.
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 a single sentence of 8 words, with no wasted text. It is front-loaded and efficiently conveys the tool's purpose.
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?
For a tool with no output schema and two required parameters, the description lacks important context such as return value, error conditions, and confirmation actions. It leaves gaps that an agent needs to handle correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly ties threadId to 'existing comment thread' and content to 'reply comment,' but adds no explicit meaning beyond property names. This is minimal and insufficient to fully document the parameters.
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 verb 'Add' and the resource 'reply comment to an existing comment thread.' It distinguishes from sibling tools like penpot_create_comment_thread (creates new thread) and penpot_update_comment (updates existing comment).
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 implies usage for replying to an existing thread but does not explicitly state when to use this tool versus creating a new thread or updating a comment. No direct guidance on prerequisites or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains behavioral details: how shapes are added, the prerequisite for images (calling another tool), token resolution via file, rotation mechanics, and auto-layout rules. It also notes that bool shapes' visual result is computed when the file is opened.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that covers extensive detail. While the first sentence is clear and front-loaded, the overall length could be trimmed or structured with bullet points for easier parsing. It is comprehensive but not concise.
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 complex input schema and no output schema, the description is fairly complete. It covers shape types, token references, auto-layout, prerequisites (image upload), and rotation. It lacks details on return values, error handling, and effects on the page, but the core functionality is well explained.
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 0%, so the description must add meaning. It thoroughly explains the 'shapes' parameter with all shape types and their sub-properties. However, it provides little to no explanation for the 'fileId', 'pageId', and 'tokensPath' parameters, leaving the agent to infer their roles.
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 tool adds one or more shapes to a Penpot page and lists the specific shape types (rect, frame, text, etc.). This distinguishes it from sibling tools like penpot_update_shapes or penpot_delete_shapes, though it does not explicitly contrast with penpot_add_component_instance.
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 provides detailed guidance on when to use each shape type within the tool, but it does not discuss when to prefer this tool over alternatives (e.g., penpot_update_shapes for modifying existing shapes, penpot_clone_shapes for duplicating). No 'when not to use' or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavioral traits. It mentions the page count constraint but does not describe side effects (e.g., deletion of contained shapes), authorization requirements, reversibility, or error conditions beyond the last-page restriction. The disclosure is minimal.
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 two succinct sentences: one for the action, one for a critical constraint. No redundant information or extraneous detail. Every word serves a purpose, making it highly efficient for an AI to parse.
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 tool with two parameters and no output schema, the description covers the essential purpose and a key constraint. However, it omits context such as the destructive nature of deletion, potential cascading effects, or how to recover (e.g., via snapshots). An agent has enough to perform basic invocation but lacks completeness for robust decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines fileId and pageId with no descriptions; the description adds no further meaning to these parameters. An agent could infer their role from names, but the description misses an opportunity to clarify how to obtain these IDs (e.g., from list results) or their expected format.
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 'Delete a page from a Penpot file', specifying the verb and resource, and distinguishes this from sibling tools that delete other entities (files, projects, shapes, etc.). The constraint about file page count adds clarity without confusion.
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 constraint that the file must have at least two pages gives a clear when-not-to-use condition. However, no explicit guidance is provided on when to choose this tool over other delete tools (e.g., penpot_delete_shapes) or what prerequisites exist (e.g., permissions). Usage context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation ('read and validate'), but does not disclose error behavior if the file is missing or invalid, nor any state changes. Adequately describes the main behavior but lacks detail on side-effects and auth requirements.
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?
Single sentence is concise and front-loaded with the action ('Read and validate') and output summary. Could benefit from brief structure for clarity, but it's effective.
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 simple read tool with one optional parameter and no output schema, the description covers the core functionality and return content. Lacks error handling details but is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only reiterates the parameter name (tokensPath) without adding meaning (e.g., format restrictions, resolution order). The default value is provided but not explained.
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?
Clearly states it reads and validates a design-token file and returns resolved tables for colors, fonts, spacing, radii, shadows. Differentiates from sibling tools by specifying the exact resource (token config file) and the resolved output.
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?
No guidance on when to use this tool versus alternatives (e.g., other read tools like penpot_get_file_snapshot, penpot_get_shape). No mention of prerequisites or conditions under which it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes that the tool registers a component (a creation action) and returns a componentId. It explains the shape tree structure and root detection, but does not disclose whether the operation is destructive, requires specific permissions, or if it modifies the page content. The disclosure is adequate but lacks depth.
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 concise, with three sentences that front-load the main action, then detail the shapes parameter, and finally state the return value. Every sentence contributes valuable information. There is no fluff, though a more structured format (e.g., bullet points) could improve scanability.
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?
Given the tool's complexity (5 params, no output schema), the description covers the core concepts (shapes structure, root detection, return value) but misses the 'tokensPath' parameter and any prerequisites (e.g., fileId/pageId must exist). It does not mention error conditions or constraints like unique component names. Completeness is adequate but not thorough.
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?
The input schema has 0% description coverage, so the description must compensate. It adds significant meaning for the 'shapes' parameter by explaining id, parentId, and frameId usage, and that the unparented shape becomes the root. However, it does not explain the 'tokensPath' parameter at all. This leaves a gap, but overall improves understanding beyond the bare 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 that the tool registers a new shape tree as a Penpot component, specifying the verb 'register' and the resource 'component'. It distinguishes the tool from siblings by mentioning the returned componentId is usable with penpot_add_component_instance, but does not explicitly differentiate from penpot_add_shapes. The purpose 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 context for using the tool: to create a component from a shape tree. It explains the relationship with penpot_add_shapes (same shape specs) and how nesting works via id/parentId, establishing when this tool should be used. It does not explicitly state when not to use it, but the guidance is sufficient for an AI agent to infer the correct use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses author-only deletion, but lacks details on side effects (e.g., thread behavior), idempotency, or error conditions. With no annotations, the description carries the full burden and is insufficient.
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 concise sentences with no redundant words. Action and constraint are front-loaded.
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?
Adequate for a simple delete operation with one parameter and no output schema. However, missing information on return value, error handling, or prerequisites beyond authorship.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'id' has no description; the tool description does not explicitly define it as the comment ID. Schema coverage is 0%, and the description fails to compensate by explaining that the id parameter is the unique identifier of the comment.
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?
Description clearly states 'Delete a single comment (reply) from a thread', specifying the action and resource. Distinguishes from sibling tools like penpot_create_comment and penpot_delete_comment_thread.
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?
States 'Only the comment author can delete their own comment', providing a clear usage condition. Does not explicitly compare to alternatives, but the context of delete vs. update or create is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool removes in-memory entry and optionally a file on disk based on configuration, but does not mention permanence, authorization, or side effects like irreversibility.
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, no redundancy. First sentence states the core action and condition, second adds implementation details. Every word serves a purpose.
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 discard tool, the description covers the action and data removal locations. However, it lacks error handling, return value information (no output schema), and fails to clarify if checkpointId is a required path or ID. Could be more complete given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter checkpointId. The description only says it references a checkpoint from penpot_checkpoint, failing to specify format (e.g., UUID), how to obtain it, or validation rules beyond minLength 1.
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 discards (frees) a checkpoint without restoring it, and contrasts with penpot_checkpoint and penpot_restore_checkpoint. It specifies the action on both in-memory and disk entries, making the purpose unambiguous.
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 says 'once it is no longer needed,' implying when to use, but does not explicitly list when not to use or compare with alternatives like penpot_restore_checkpoint. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the deletion of entire thread and replies and owner restriction. However, lacks details about reversibility or side effects.
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 concise sentences, each adding necessary information with no waste.
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?
Adequate for a simple delete tool with one parameter, but lacks parameter meaning. Otherwise covers purpose and key constraint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'id' has no description. The tool description does not clarify that 'id' refers to the comment thread ID, leaving ambiguity.
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?
Clearly states the action (delete) and resource (comment thread and all replies), distinguishing it from sibling tools like penpot_delete_comment and penpot_resolve_comment_thread.
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?
Provides ownership constraint ('Only the thread owner can delete it'), but does not explicitly guide when to use versus alternatives like penpot_delete_comment for individual replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Describes read-only retrieval and return fields, but omits pagination, ordering, or error behavior. Adequate but gaps.
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: purpose then return details. No redundant words. Front-loaded.
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?
Covers purpose, resource, and return structure. Missing pagination and error handling, but acceptable for a simple list tool with one param.
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 has 1 param fileId with 0% description coverage. Description mentions 'in a Penpot file' but doesn't further describe fileId beyond the name. Partially compensates but could add format or source info.
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?
Clearly states verb 'list' and resource 'comment threads in a Penpot file'. Distinct from siblings like create, resolve, delete comment threads. Specifies exact return fields.
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?
Implies usage for listing threads but no explicit when-to-use or when-not-to-use. No comparison with siblings like get_comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: fresh IDs, optional offset (dx/dy), reparenting (parentId/frameId), and carrying over component/variant tags. It lacks information on error handling (e.g., non-existent shapeIds) or performance considerations, but adequately discloses the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph containing multiple sentences. While it front-loads the main purpose, the structure could be improved with clearer separation of details (e.g., bullet points for optional parameters). It is moderately concise but could be more reader-friendly.
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?
The description covers the core functionality and key optional behaviors, but leaves gaps: no mention of error scenarios, success confirmation, or idempotency. Given the lack of output schema and annotations, a more complete description would include these aspects.
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 0%, so the description must explain parameters. It describes dx/dy, parentId/frameId, and shapeIds in context, but does not explicitly define fileId and pageId beyond their required status. The explanation is functional but could be more systematic for each parameter.
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 it duplicates shapes with fresh IDs, using the verb 'duplicate' and specifying the resource 'shapes on a page'. It also distinguishes itself from the sibling tool penpot_add_component_instance, which creates linked component instances.
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 contrasts this tool with penpot_add_component_instance, guiding when to use plain duplication vs. component instances. However, it does not mention other alternatives like penpot_add_shapes for creating new shapes, leaving some usage scenarios implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read behavior and version info, but lacks details on permissions, rate limits, or side effects. Adequate but not exhaustive.
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?
Single sentence, no wasted words. Information is front-loaded and efficient.
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?
Tool is simple with one parameter and no output schema. Description covers purpose, usage, and content. Lacks response structure but acceptable given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one required parameter 'fileId' with 0% description coverage. The description does not elaborate on the parameter beyond the schema, failing to add meaning (e.g., format, source).
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?
Description clearly states 'Read a Penpot file' and specifies contents (pages, shape tree, revn/vern), distinguishing it from sibling tools like penpot_add_shapes or penpot_delete_file. The verb+resource is specific and informative.
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?
Explicitly says 'needed before any content mutation,' providing clear when-to-use guidance. No explicit when-not-to-use or alternatives, but sibling list provides context for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description carries full burden. It discloses the critical constraint (user-created only) but omits other behavioral details like return value, confirmation of success, or idempotency. Adequate for a simple rename operation.
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, no redundant information. The action and constraint are front-loaded, achieving maximum clarity with minimal words.
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 simple rename tool with two required parameters and no output schema, the description covers the essential constraint. Minor gap: could mention that 'label' is the new name, but schema names imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description adds no parameter details beyond the names 'snapshotId' and 'label'. It does not explain the label is the new name or any constraints like max length or uniqueness. Fails to compensate for missing schema descriptions.
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 action ('Rename') and resource ('existing user-created snapshot'), and distinguishes from sibling tools like penpot_create_file_snapshot and penpot_lock_file_snapshot by specifying the constraint that only user-created snapshots can be renamed.
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?
Description explicitly states when to use (only for snapshots with createdBy 'user') and when not to (system-created automatic backups will error), providing clear usage boundaries. No alternative tools mentioned, but the constraint is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the coordinate and frame attachment behavior, but does not mention any potential side effects, permission requirements, or limits. The tool appears additive, so a score of 3 reflects adequate but not thorough transparency.
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, no wasted words. Front-loaded with the main action, followed by parameter clarifications. Efficient and to the point.
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 6 parameters and no output schema, the description covers the purpose, coordinate semantics, and optional frame attachment. It does not describe the response format, but that is acceptable without output schema. Missing minor details like content being the initial comment text, but overall sufficient.
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 0%, so the description must add meaning. It explains x, y, and frameId, providing value beyond the schema. However, it does not explain fileId, pageId, or content (though these are partially inferable). The description partly compensates for the low coverage.
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?
Clearly states it creates a new comment thread pinned to a canvas position on a page. The verb 'create' and resource 'comment thread' are specific, and it distinguishes from sibling tools like penpot_create_comment (single comment) and penpot_list_comment_threads (listing).
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 tells when to use frameId (to attach to a specific frame) and when to omit it (to place on page root), providing clear context. However, it does not explicitly mention when not to use this tool versus alternative comment-related tools like penpot_create_comment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: types of snapshots (user vs system), expiration of system backups, and the return fields (id, label, revn, createdAt, createdBy, lock state). This adds value beyond what is in the schema.
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 with clear structure: purpose, return details, and usage tip. It is concise without unnecessary words, though it could be slightly more compact.
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 simple list tool with one parameter and no output schema, the description covers the essential information—return fields, distinction of snapshot types, and how to use the result. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, fileId, has 0% schema description coverage. The description does not explicitly describe the parameter; it only implies its necessity ('for a Penpot file'). It adds minimal meaning beyond the schema's type and requirement.
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 'List all named snapshots (version history) for a Penpot file.' It specifies the resource (file snapshots) and the action (list), distinguishing it from sibling tools like penpot_create_file_snapshot and penpot_restore_file_snapshot.
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 explains when to use the tool: to view snapshots for version history or rollback. It differentiates between explicit and system snapshots and directs the user to use the returned id with penpot_restore_file_snapshot. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It clearly indicates a read operation (listing pages) and specifies output fields and ordering. However, it does not explicitly state non-destructiveness or side effects, though none are implied.
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?
A single sentence of 19 words, front-loaded with the key information ('List all pages') and additional details on return values and ordering. No redundant 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 simple list tool with one parameter and no output schema, the description covers purpose, returned fields, and ordering. It could specify the ordering criteria (e.g., creation order) but is otherwise complete.
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?
With 0% schema description coverage, the description adds minimal meaning beyond the parameter name and type. It mentions 'in a Penpot file' but does not clarify how to obtain the fileId or expected format. The single parameter is simple, so the gap is acceptable but not fully compensated.
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 all pages in a Penpot file and returns each page's id and name in order. This specific verb-resource combination distinguishes it from sibling tools like penpot_create_page or penpot_delete_page.
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 implies usage for retrieving page listings but does not provide when-to-use guidance or mention alternatives. No explicit context for selecting this tool over others is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose pagination, authentication specifics, or error handling. However, the tool is simple and the description is truthful.
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?
Single sentence, no fluff, clearly stated. Every word earns its place.
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 zero parameters and no output schema, the description is mostly complete. It could mention that teams are the root organizational unit, but the agent can infer this from context.
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?
There are no parameters, so baseline is 4. The description adds no parameter information but none is needed.
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 uses specific verb 'List' and resource 'Penpot teams', with clear scope 'accessible to the configured access token'. It distinguishes from sibling tools like penpot_list_files and penpot_list_projects.
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?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied as teams are a top-level entity, but alternatives (e.g., list projects after selecting a team) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool clones the shape tree, assigns fresh ids, and maintains a shape-ref link for Penpot recognition. This adds value beyond a simple 'add instance' statement. However, it does not mention permissions, reversibility, or potential side effects (e.g., affecting the main component).
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 extremely concise: three sentences covering purpose, behavior, and library usage. It is front-loaded with the core action and includes essential context without redundancy. Every sentence earns its place.
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?
Given 8 parameters, no output schema, and no annotations, the description covers the main functionality well but omits details on optional parameters (frameId, parentId) and does not mention return values or error conditions. It feels just adequate but not fully complete for a tool of moderate complexity.
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 only 13%, so the description must compensate. It adds significant value for libraryFileId, explaining its purpose and source. x and y are implied as position coordinates but lack format details. frameId and parentId are not mentioned at all, despite having defaults. Overall, the description partially compensates for low schema coverage but leaves 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 specifies the action (place a copy/instance of a component), the resource (existing component on a page), and the result (cloned shape tree with fresh ids linked via shape-ref). It distinguishes itself from sibling tools like penpot_create_component (creates a component from shapes) and penpot_clone_shapes (clones arbitrary shapes) by focusing on component instances and mentioning library support.
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 guidance on when to use the libraryFileId parameter (for components from shared-library files) and when to omit it (current file). It references penpot_list_components as a sibling to retrieve library IDs. However, it does not explicitly state when not to use this tool or compare to alternatives like penpot_clone_shapes for non-component shapes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: aligns on selrect, group immobility, atomicity, and idempotency. This is comprehensive and adds value beyond the schema.
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 dense but well-structured, front-loading purpose and then detailing behavior. Every sentence adds value, though bullet points could improve readability for edge options.
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?
Behavior is well covered, but the description lacks information about return values, errors, or prerequisites. Given no output schema, some completeness is lost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It only explains the 'edge' parameter in detail. Standard parameters like fileId, pageId, shapeIds, tokensPath are not described, leaving a significant gap.
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 verb 'align', the resource 'shapes', and specifies the alignment follows Penpot's own actions. It distinguishes from manual computation and implies a unique value proposition.
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 contrasts with manual computation, providing clear usage context. It does not explicitly list when not to use or compare to sibling tools like distribute, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description successfully discloses key behaviors: shape removal, cascading delete for frames/groups, and irreversibility. This goes beyond what the input schema conveys.
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 concise sentences with no fluff. Critical details (cascading delete, no undo) are included without extra verbiage.
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 delete tool with three parameters and no output schema, the description covers the primary behavior and important caveats. It is slightly lacking in parameter specifics but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds minimal parameter info beyond 'by id'. It does not explain fileId, pageId, or shapeIds beyond the schema, so the description fails to compensate for the low coverage.
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 action (delete), the resource (shapes from a page in a Penpot file), and method (by id). It also distinguishes from siblings by specifying it is the only deletion tool, contrasting with clone, find, etc.
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 explains when to use (to remove shapes) and warns about no undo and cascading deletion of children. It does not explicitly list when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the effect (unlocking allows deletion), the precondition (must be locked), and the authorization (creator-only). This provides sufficient transparency for a simple unlock operation.
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 short, clear sentences with no redundant information. Every word serves a purpose: verb, resource, effect, and constraint.
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 tool with no output schema, the description covers the purpose, effect, and authorization. It lacks details on return values or error scenarios, but these are likely standard for similar operations. Overall adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `snapshotId` has no description in the schema (0% coverage) and the tool description does not elaborate on its meaning beyond the name. The agent would benefit from knowing it is the ID of the snapshot to unlock, but the description does not add any value over the field name.
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 specifies the exact action (unlock), resource (previously locked user-created snapshot), and a key constraint (only creator can unlock). It clearly differentiates from sibling tools like lock_file_snapshot and delete_file_snapshot.
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 states that unlocking allows the snapshot to be deleted, implying usage before a delete operation. It also identifies the authorization condition (creator-only). However, it does not explicitly mention when not to use or compare with alternatives, though the sibling tool list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that ops are applied in array order, each sees effects of prior ops, and create ops can set explicit IDs for later reference. Returns one result per op. This covers key behavioral traits beyond what schema alone provides.
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 front-loaded with the key benefit (single round trip) and efficiently covers operation types, ordering semantics, and inter-op references without wasted words. Every sentence adds distinct value.
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 complexity of batch operations and the absence of an output schema, the description adequately covers purpose, usage, operation details, and return format. It does not mention error handling or limits, but the core functionality is fully described.
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 0%, so description must compensate. It thoroughly explains the 'ops' parameter structure (four operation types, shape spec references penpot_add_shapes, update patch references penpot_update_shapes, etc.). However, it does not document 'fileId', 'pageId', or 'tokensPath' beyond their existence, leaving those parameters with only schema defaults/constraints.
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 states a specific verb+resource: 'Apply an ordered list of create/update/delete/reorder operations to a page as a single update-file change-set'. It clearly distinguishes from siblings like penpot_add_shapes and penpot_update_shapes by emphasizing batch execution and reduced round trips.
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 explains when to use (batching multiple shape operations) and contrasts with individual RPC calls ('instead of one RPC call per shape'), but does not explicitly define when not to use or list alternatives beyond referencing sibling specs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains creation, return of metadata including id, and constraints on later operations. However, it doesn't disclose potential side effects like file modification dates or authorization requirements.
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 efficiently convey purpose, parameter details, and a behavioral note. No fluff; every sentence adds value.
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 simple create tool with 2 params and no output schema, description covers purpose, parameter behavior, and return value. Lacks mention of prerequisites or rate limits, but sufficient for typical use.
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 has 0% description coverage. Description adds meaning: fileId is required, label is optional with auto-generated timestamp; also explains consequences of omitting label. Significantly augments schema.
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?
Description clearly states verb (create), resource (snapshot of a file), and purpose, and distinguishes from siblings like get_file_snapshot and delete_file_snapshot.
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?
Explains optional label and auto-generation behavior, and notes that only user-created snapshots can be renamed/deleted/locked. Lacks explicit when-not-to-use or alternatives, but provides clear context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return data (id, content, author, timestamps), which is behavioral. No annotations provided, so description carries burden. Does not disclose authentication or rate limits, but for a read-only operation, this is acceptable.
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: first states purpose, second lists return fields. No fluff, front-loaded. Efficient and clear.
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 simple read tool with one parameter and no output schema, description covers operation and return data. Lacks details on pagination or ordering, but likely not needed for listing thread replies. Sufficient for low complexity.
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 has one parameter (threadId) with no description (0% coverage). Description mentions 'within a comment thread', linking to the parameter. Adds context about the thread context but doesn't explain format or requirement. Compensates for schema lack.
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?
Clearly states the action 'Get all reply comments' and the resource 'comment thread'. Distinguishes from sibling tools like penpot_list_comment_threads (lists threads) and penpot_create_comment (creates a comment).
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?
Implies usage context ('within a comment thread') but does not explicitly state when to use this tool vs alternatives (e.g., when you have a thread ID from list_comment_threads). No exclusion or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Explains z-order behavior (inserted at topmost shape's position), that shapes keep absolute positions, and return value. Could mention optional groupId parameter but it's not critical.
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?
Four sentences, front-loaded with purpose, no fluff. Each sentence adds value.
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?
Describes constraints, return values, and reverse operation. No output schema exists, so return description is adequate. Could note if groupId is optional (parameter existence) but not required.
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 0%, so description must compensate. It explains shapeIds must be siblings and that groupId is returned, but does not describe fileId, pageId, or name parameters individually. Adds partial meaning beyond schema.
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?
Clearly states the tool groups sibling shapes, matching Penpot's Ctrl+G behavior. Distinguishes from penpot_ungroup_shapes by naming the reverse operation.
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?
Explicitly indicates when to use (group shapes) and when to use the reverse tool (ungroup). Mentions constraint that shapes must share the same parent. Does not exhaustively list alternatives but provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the toggle behavior and UI implication (hidden vs. accessible), but lacks details on permissions, reversibility, or error cases. The disclosure is adequate for a simple operation.
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, no fluff. The key action and Boolean usage are front-loaded. Every word adds value.
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's simplicity (2 params, no output schema), the description covers the essential behavior and UI consequence. It could mention error handling or required permissions for completeness, but this is not critical for a toggle operation.
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 description coverage is 0%, so the description must compensate. It explains the `isResolved` parameter with examples (`true` for resolved, `false` for reopen). The `id` parameter is implied as thread ID, but not explicitly documented.
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 verb 'Mark...as resolved or reopen it' and specifies the resource 'comment thread'. It distinguishes this tool from siblings like create, delete, and list by focusing on resolution toggling.
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 states when to use this tool (to resolve or reopen a thread) and provides context about UI behavior. It does not specify when not to use it or direct alternatives, but the sibling set covers other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals key behaviors: geometry auto-recomputation, path shape restrictions, token references, clearStroke/clearShadows interaction with stroke/shadows, and layout schema reuse. Missing details on idempotency or error handling, but covers many edge cases well.
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 long but well-structured and front-loaded with the core action. Each sentence adds value, covering special cases and behaviors. Minor conciseness improvements possible, but appropriate for the tool's complexity.
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?
The description covers shape behavior thoroughly and notes schema references to penpot_add_shapes. However, it does not explain the required parameters (fileId, pageId, patches) in detail, and with no output schema, return value context is missing. Adequate but has gaps.
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 has 0% description coverage; the description explains many parameters (geometry, content, media, colors, radii, shadows, layout) but not all (e.g., fills, stroke, opacity). It adds meaning for key fields, partially compensating for the gap, though some properties remain underspecified.
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 updates existing shapes by id, lists supported shape types (rect, frame, etc.), and differentiates from siblings by noting that group updates do not move children and advising use of penpot_align_shapes or penpot_distribute_shapes for that purpose.
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?
Explicitly provides when to use (update shapes in place with partial changes) and when not (for moving group as a unit), along with exceptions for path and image shapes. Also mentions alternatives for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It explains that system-created backups cannot be deleted, locked snapshots require prior unlocking, and only user-created snapshots are deletable. It does not mention whether deletion is irreversible or what response to expect, but the core behavioral constraints are well covered.
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 two sentences long. The first sentence clearly states the purpose, and the second adds vital constraints. Every sentence earns its place, and the information is front-loaded with no extraneous content.
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's simplicity (one parameter, no output schema), the description provides sufficient context for the core operation and constraints. However, it could be more complete by mentioning what happens after deletion (e.g., success response) or that the snapshotId must belong to a file, but these are minor omissions for a basic delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 0% (no descriptions in schema). The description does not add any meaning to snapshotId beyond what the schema provides (a required string). It fails to explain the format, source, or how to obtain the snapshotId, leaving the agent without guidance on constructing the argument.
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's purpose: 'Delete a user-created snapshot.' It specifies the condition for deletable snapshots (createdBy: 'user') and distinguishes from system backups, which cannot be manually deleted. This differentiates it from sibling tools like penpot_create_file_snapshot, penpot_restore_file_snapshot, and penpot_lock_file_snapshot.
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 explicitly states when to use this tool (only for user-created snapshots) and when not to (locked snapshots or system backups). It also provides an explicit alternative: if a snapshot is locked, call penpot_unlock_file_snapshot first. This gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: outer shapes stay put, inner shapes slide, uses selrect bounding box, applies as single change-set, and leaves already evenly spaced shapes untouched. No contradictions.
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?
Four sentences clearly convey purpose and behavior. Minor structure improvement possible by explicitly listing parameters, but overall concise and well-organized.
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 no output schema, the description thoroughly explains behavior and key parameters. The only gap is the missing tokensPath parameter, but the core functionality 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?
The description explains axis and implicitly covers fileId, pageId, shapeIds. However, the tokensPath parameter is not mentioned at all, and schema description coverage is 0%, leaving one parameter undocumented.
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 distributes three or more shapes to equalize gaps, matching Penpot's own distribute actions. It distinguishes from siblings like penpot_align_shapes by specifying the exact behavior of spacing equalization.
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 explains when to use the tool (to distribute shapes with equal gaps) and contrasts with caller-computed spacing. It does not explicitly mention alternatives or when not to use, but the sibling list provides context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is read-only and does not modify the live file, which is the key behavioral trait. It also notes the return structure matches another snapshot tool. However, it does not mention potential limitations like pagination or size constraints, but given the read-only nature, the disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence states the main action and context, and the second adds a comparison and usage tip. Every sentence adds value without redundancy.
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 two simple parameters and no output schema, the description covers the main aspects: what is returned (full file content, pages, shape tree), that it is read-only, and its relationship to sibling tools. It is complete enough for a read-only snapshot retrieval tool, though missing details on snapshotId format are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While the description implicitly references the parameters (fileId and snapshotId) by describing the action 'retrieve ... at a specific snapshot', it does not explicitly explain their meaning, format, or how to obtain them. This adds minimal value beyond parameter names.
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 retrieves full file content (pages, shape tree) at a specific snapshot for read-only inspection. It distinguishes itself from sibling tools like penpot_get_file_snapshot (same structure but from historical data) and penpot_restore_file_snapshot (for rollback), making the purpose specific and unambiguous.
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 explicitly states when to use this tool: 'for read-only inspection or comparison, without modifying the live file.' It also specifies when not to use it by pointing to penpot_restore_file_snapshot for actual rollback, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that url images are fetched directly by Penpot's server (nothing passes through the MCP server) and that isLocal defaults to true. It does not mention any destructive or irreversible effects, which is appropriate for a create operation.
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 multiple sentences but each sentence adds value. It is front-loaded with the primary purpose and uses a clear structure: purpose, output usage, input methods, additional details. No wasted words.
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 7 parameters, no output schema, and zero schema descriptions, the description covers the tool's input variations, output meaning, and integration with another tool (penpot_add_shapes). It does not explain error cases or limits, but is sufficiently complete for an agent to use the tool correctly.
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 description coverage is 0%, yet the description adds meaning for several key parameters: filePath, url, dataBase64 are explained as mutually exclusive sources; dataBase64 requirement for mtype is noted; fileId is contextualized as the target file; isLocal default is mentioned. Not all parameters (e.g., name) are elaborated, but the essential ones are covered.
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 action ('Upload an image or other media asset'), the target resource ('to a Penpot file'), and the output ('return the media object metadata'). It distinguishes from sibling tools like penpot_add_shapes by detailing how the returned id is used as mediaId for image shapes.
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 explains the three mutually exclusive methods for providing media (filePath, url, dataBase64) and notes that dataBase64 requires mtype. It also clarifies the relationship to penpot_add_shapes. However, it does not explicitly state when not to use this tool or contrast with other upload-like tools (none apparent in siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the nesting behavior (descendants under 'shapes' field) and the componentInfo field with its four states. It does not mention error conditions, authentication, or rate limits, but as a read-only lookup, the covered aspects are sufficient for typical use.
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 a single, well-structured paragraph. It starts with the main purpose, then explains the key behavioral detail (nesting), and concludes with the componentInfo logic. Every sentence adds value, and there is no redundant or extraneous text.
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?
With 5 parameters, no output schema, and no annotations, the description covers the core functionality well: it explains what the tool returns (shapes and componentInfo) and how parameters affect the output. It does not describe error responses or full shape structure, but for a lookup tool, the coverage is adequate for correct invocation.
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 description coverage is 0%, so the description must compensate. It explains the purpose of includeDescendants and maxDepth in detail, and implies the required parameters (fileId, pageId, shapeId) through context. However, it does not explicitly describe the required parameters, which are self-explanatory but could be named. Overall, the description adds significant value beyond the schema.
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?
Description explicitly states the tool's purpose: 'Look up a single shape by id on a page'. It distinguishes itself from a sibling tool (penpot_get_file_snapshot) by specifying 'without pulling the whole page'. The verb and resource are clear and specific.
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 guidance on when to use this tool (for a single shape lookup) and mentions an alternative (penpot_get_file_snapshot). It also explains the behavior of parameters like includeDescendants and maxDepth, helping users decide how to configure the call. However, it does not explicitly state when not to use it or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses font lookup behavior, glyph advance computation, and handling of newlines and maxWidth. It does not mention auth needs or rate limits, but covers core behavior well.
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 comprehensive at ~7 sentences, front-loading the main purpose. While slightly verbose, every sentence adds value and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies return values (width, height, lineHeight, lines) and explains per-line breakdown. It covers multi-line and word-wrapping behavior, making it complete for the tool's purpose.
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 0%, so description must explain parameters. It explains characters, maxWidth, fontFamily, fontSize, fontWeight semantics, including that fontFamily is used for font lookup. It does not repeat defaults from schema but adds context beyond parameter names.
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 explicitly states it measures real rendered width/height of a text string for a given font without creating or touching any shape. It distinguishes itself from siblings like penpot_add_shapes and penpot_update_shapes by removing guesswork for text dimensions.
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 explains when to use it (before creating/updating text shapes) and how it handles font lookup (Google Fonts first, then team fonts). It also discusses multi-line and maxWidth parameter usage. However, it lacks explicit '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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that restore replaces live data, affects all agents and browser sessions, and that an automatic backup snapshot is created. This gives full transparency about side effects and recoverability.
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?
Three sentences: first states core action, second explains safety undo mechanism, third lists prerequisites. No filler, front-loaded with purpose, each sentence adds essential 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?
No output schema, but description does not mention return value or success/failure indicators. However, for a mutation tool with clear side effects and undo capability, it covers the key aspects except output. Slightly incomplete.
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 0%, so description must add meaning. It explains that fileId and snapshotId come from penpot_list_file_snapshots, but does not elaborate on their format or constraints beyond the schema's minLength. Provides context but limited parameter-specific detail.
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 restores a file to a snapshot state, using verb 'Restore' and specifying the resource (file via snapshot). It distinguishes from siblings like penpot_create_file_snapshot and penpot_get_file_snapshot by referencing the UI equivalent and linking to penpot_list_file_snapshots for obtaining IDs.
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?
Explicitly states prerequisites: requires fileId and snapshotId from penpot_list_file_snapshots. Also notes that a system backup snapshot is created automatically, allowing undo. Does not specify when not to use, but purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details that children keep absolute position, get new parent/frame, group is deleted, and returns ids and parent's updated order. Highly transparent.
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?
Three clear sentences, front-loaded with action, no extraneous words. Efficiently conveys behavior and outcome.
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?
No output schema or annotations, yet description covers the core behavior, return value, and post-conditions. Minor gaps: no error cases (e.g., if groupId is not a group) or exact return format.
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 0%, so description must compensate. It explains groupId's required type but does not clarify fileId and pageId beyond their names. Partial compensation.
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?
Description clearly states the tool dissolves a group, returning children to the parent at the group's z-order. It explicitly matches Penpot's 'Ungroup' behavior and distinguishes from grouping operations via sibling names.
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?
States that groupId must refer to a shape of type 'group', implying when to use. Does not explicitly contrast with alternatives, but the context of ungrouping is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details return fields (id, type, name, position/size, linkState), filter combination logic (AND), and the subtree caveat. Does not cover performance or auth, but sufficient for a read-only search.
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?
Front-loads purpose and usage, then details parameters and returns. Slightly verbose in enumerating linkState values, but all sentences add value.
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 9 parameters, no output schema, and no annotations, the description covers input filters and output structure well. Missing details on limit behavior and error conditions, but adequate for a search tool.
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 description coverage is 0%, but the description explains all filter parameters (type, name, nameContains, textContains, isComponentInstance, isRoot) and their semantics. Does not explain fileId, pageId, limit, but those are understandable from context or schema.
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?
Clearly states the verb 'Search' and resource 'shapes on a page', distinguishes from the sibling penpot_get_file_snapshot by positioning as an alternative to walking the tree.
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?
Explicitly describes when to use (to find shapes by predicates instead of tree walking) and provides an alternative penpot_get_shape for full subtree. Lists all filters and explains omitting filters lists all shapes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses key behavioral traits: case-insensitive by default, per-text-run matching (limitation), returns modified shape ids and count, and atomicity via a single call. This is thorough and honest.
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 front-loaded with the main action and has no redundant sentences. Every sentence adds value: purpose, matching details, case sensitivity, edge case (adjacent runs), and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explicates the return value (shape ids/names and occurrence count) and warns about edge cases. It is complete for a text replacement tool with no nested objects or complex output.
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 0%. The description explains search, replacement, and caseSensitive (with default) but does not explain fileId, pageId, or limit. While fileId and pageId are common, the omission of limit is a gap. It partially compensates but not fully.
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 does find and replace text across all text shapes on a page. This is a specific verb-resource combination that distinguishes it from siblings like penpot_measure_text or penpot_find_shapes.
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 implies usage for bulk text replacement on a page, but does not explicitly state when not to use it or provide alternatives. The context of a single update-file call is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It details the returned fields (componentId, name, mainInstanceId/mainInstancePage, variantId/variantProperties) and the effect of includeLibraries (adds libraryFileId). However, it does not mention error handling, performance, or read-only nature explicitly, though it is implied.
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 a single paragraph but highly efficient. It front-loads the core purpose, uses bullet points within text for clarity, and every sentence adds essential information without redundancy.
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 no output schema or annotations, the description provides a solid understanding of input/output and integration with sibling tools. However, it lacks information on error conditions, prerequisites (e.g., file existence), and pagination limits. Overall, it is complete enough for an AI agent, with minor gaps.
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 schema has 2 parameters with 50% description coverage. The description adds value by explaining fileId's role (identifies the file) and expanding on includeLibraries: it specifies the output includes libraryFileId and libraryFileName, and how to use them with penpot_add_component_instance. This goes beyond the minimal schema description.
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 that the tool lists a file's existing components, explicitly contrasting it with alternative approaches like creating components manually or parsing snapshot data. It also distinguishes from sibling tools like penpot_get_file_snapshot by emphasizing the ease of use.
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 explicitly states when to use this tool: 'instead of requiring the caller to have created them itself in the same session or parse penpot_get_file_snapshot's data.components by hand.' It also provides guidance on the includeLibraries parameter, explaining when to set it true and the resulting behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses behavior: checkpoint not consumed, can be restored repeatedly, throws on unknown id, details corrective actions for shapes. Very transparent.
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?
Well-structured with main purpose first, then mechanism, then edge cases. Slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers both page-level and file-level checkpoints, mentions related tools, explains error condition. Complete for a tool with no output schema.
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?
Single parameter checkpointId has no schema description, but description adds meaning: it is a valid checkpoint id, and explains consequences of unknown id. Compensates for 0% schema coverage.
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 undoes shape changes since a checkpoint, with specific verb 'undo' and resource 'shape changes', and distinguishes it from siblings like penpot_discard_checkpoint and penpot_checkpoint.
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?
Provides context for when to use (undo shape changes) and mentions alternatives (discard checkpoint) and prerequisites (checkpoint must exist). Lacks explicit when-not-to-use but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: locking prevents deletion, creator-only constraint, user-created snapshots only, and need to unlock to delete. No contradictions.
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 efficient sentences with no wasted words. The main action is front-loaded, and restrictions are clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description is complete. It covers purpose, restrictions, and counter-action (unlock). No gaps.
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?
The single parameter snapshotId is implied by context but not explicitly described in the description. Schema coverage is 0%, so description should add more detail. However, the tool's purpose makes the parameter clear, so adequacy is borderline.
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 locks a user-created snapshot to prevent deletion. It specifies the scope (only user-created, only by creator) and distinguishes from siblings like unlock and delete.
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?
Explicitly states when to use (to prevent deletion of user-created snapshots) and restrictions (only creator can lock, only user-created snapshots). References the unlock sibling tool, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: snapshot scope, persistence (disk vs memory based on server config), reusability, and lifecycle. It also explains the relationship with other checkpoint tools.
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 single well-structured paragraph that front-loads the core purpose and progressively adds detail. It is concise without unnecessary words, though bullet points could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description comprehensively covers input semantics, side effects, persistence behavior, and lifecycle. It provides all necessary context for an agent to invoke correctly.
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% schema description coverage, the description adds significant meaning: clarifies that pageId scopes snapshot to a single page and omitting it creates a whole-file checkpoint. fileId is implied but not elaborated, but the schema already marks it required.
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's purpose: 'Snapshot shapes so a subsequent penpot_restore_checkpoint call can undo whatever happens between now and then' and gives a concrete scenario (undo delete_shapes). It distinguishes itself from sibling tools like penpot_restore_checkpoint and penpot_discard_checkpoint.
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?
Explicit guidance on when to use ('Call this immediately before a risky multi-step edit'), how to supply pageId vs omit it for whole-file checkpoint, and what to do with the returned checkpointId. The description also clarifies reuse and discard lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly describes behavioral traits: implicit z-order, no reparenting, actions and their effects, and no-op conditions. Covers edge cases.
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?
Description is information-dense and well-structured, front-loading purpose then detailing actions. Every sentence adds value; no wasted words.
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 complexity and no output schema, description covers action semantics, constraints, and key differentiators. Lacks mention of error conditions or prerequisites, but is otherwise complete for a reorder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds significant meaning: explains action enum values and their semantics, mentions targetId for before/after. FileId, pageId, shapeId are standard context from sibling tools.
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?
Description clearly states the tool changes stacking order among siblings, matching Penpot UI actions. Distinguishes from sibling tools like penpot_update_shapes by explicitly noting that reparenting is not done here.
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?
Explicitly explains when to use each action (front, back, forward, backward, before, after), including no-op conditions for forward/backward at ends. Provides alternative for reparenting (penpot_update_shapes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![penpot-mcp MCP server](https://glama.ai/mcp/servers/tvolodi/penpot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tvolodi/penpot-mcp)

Score Badge

Copy to your README.md:

[![penpot-mcp MCP server](https://glama.ai/mcp/servers/tvolodi/penpot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tvolodi/penpot-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/tvolodi/penpot-mcp'

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