typst_resolve_commentMarks a Typst comment thread as resolved or reopens it by setting resolved=false, enabling clear status updates for project feedback.
Mark a comment thread as resolved, or reopen it with resolved=false.
| Name | Required | Description | Default |
|---|---|---|---|
| resolved | No | ||
| comment_id | Yes | ||
| project_id | Yes | Project ID from typst_list_projects, e.g. 'pAbC123dEf456gHi789jKl' |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that this is a reversible toggle rather than a one-way action, but says nothing about permissions, what happens if the comment is already resolved, or error behavior on a missing thread.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the primary action comes first and the less common reverse case follows. Nothing could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple idempotent toggle with no output schema, and the reversible-state nuance is captured. However, an agent still doesn't know whether resolving requires ownership or specific project permissions, nor what a failure looks like on an unknown or already-resolved comment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: project_id is documented but comment_id and the resolved boolean are not described at all in the schema. The description compensates for the most consequential gap by explaining that resolved=false reopens rather than resolves, which is exactly the non-obvious semantics of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (mark resolved) and resource (comment thread), and adds the inverse operation (reopen) in the same sentence. It is distinguishable from siblings like typst_delete_comment or typst_reply_comment without opening a schema, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action itself – you call this to resolve or reopen a thread – and the resolved=false case is spelled out. There is no explicit when-not-to-use guidance or pointer to a sibling like typst_delete_comment for permanent removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.