Twist MCP Server

by mikemc

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized into inbox and threads categories, each targeting specific actions like archive, get, mark read/unread, pin, star, etc., with no overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a clear prefix (twist_inbox_ or twist_threads_) followed by a verb_noun structure. This makes the tool set highly predictable and easy to navigate.
Tool Count3/5
With 24 tools, the count feels heavy for a messaging/thread management server. While the tools cover many operations, it borders on being excessive, potentially overwhelming for agents to manage efficiently.
Completeness5/5
The tool set provides comprehensive coverage for inbox and thread management, including CRUD operations (add, get, update, remove), lifecycle actions (archive, pin, star, mute), and state management (read/unread marks). No obvious gaps exist for the domain.
Average 3/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Stars a thread' implies a mutation/write operation but doesn't specify permissions needed, whether the action is reversible, rate limits, or what happens if the thread is already starred. This leaves significant behavioral questions unanswered.
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 appropriately concise with two sentences that directly address the tool's purpose and parameter. However, the structure could be improved by front-loading more critical information rather than separating the parameter explanation into a separate 'Args' section.
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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'starring' means in this context, what the expected outcome is, or provide any error handling context. The agent would have significant gaps in understanding how to use this tool effectively.
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 it mentions the 'id' parameter, it provides no semantic context about what constitutes a valid thread ID, where to find it, or format requirements. The description adds minimal value beyond what's already evident from the schema structure.
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 ('Stars') and resource ('a thread'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'twist_threads_unstar' or 'twist_threads_pin', which would be needed for a perfect score.
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 no guidance on when to use this tool versus alternatives. There are multiple sibling tools for thread operations (like unstar, pin, mute), but no indication of when this specific star action is appropriate or what prerequisites might exist.
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 full burden. It states 'Updates an existing thread' which implies a mutation operation, but doesn't disclose behavioral traits like required permissions, whether updates are partial or complete, side effects (e.g., notifications), or error handling. This leaves significant gaps for a mutation tool.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter list is structured but could be more concise (e.g., combining related parameters). No redundant information is present, making it efficient overall.
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 a mutation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It covers parameters superficially but misses critical context like behavioral effects, error cases, and return values, leaving the agent under-informed for safe 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 lists all 7 parameters with brief explanations (e.g., 'id: The id of the thread', 'content: The content of the thread'), adding meaningful context beyond the schema's titles. However, it lacks details on formats (e.g., what 'actions' or 'attachments' objects contain) and defaults (parameters are nullable with defaults).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Updates an existing thread' which provides a clear verb ('Updates') and resource ('thread'), but it's vague about what specifically gets updated. It doesn't distinguish this from sibling tools like twist_threads_add (creates new) or twist_threads_remove (deletes), though the verb 'Updates' implies modification rather than creation or deletion.
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. The description doesn't mention prerequisites (e.g., needing thread ID), compare to twist_threads_add for creation, or specify use cases like editing content versus adding attachments. Without this, the agent lacks context for tool selection.
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 of behavioral disclosure. It states the action ('Archives all threads') but doesn't cover critical aspects like whether this is reversible (e.g., via 'twist_inbox_unarchive'), what permissions are required, if it's destructive to thread data, or how it handles errors. For a bulk mutation tool with zero annotation coverage, this is a significant gap.
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 appropriately sized with two sentences: one for the main purpose and one for the parameter. It's front-loaded with the core action, and the 'Args:' section is structured but could be more integrated. There's no wasted text, though it could be slightly more polished.
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 (a bulk archiving tool with mutation), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address reversibility, permissions, error handling, or what happens to archived threads, leaving the agent with insufficient context for safe and effective use.
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 adds the parameter 'older_than_ts' with a brief explanation ('Only archives threads that are the same or older than this timestamp'), which provides basic semantics. However, with 0% schema description coverage and only 1 parameter documented out of 1, the description compensates minimally but doesn't clarify the timestamp format (e.g., Unix timestamp in seconds/milliseconds) or default behavior when null.
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 verb ('Archives') and resource ('all threads in a workspace'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its sibling 'twist_inbox_archive', which likely archives individual threads rather than all threads, leaving some ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'twist_inbox_archive' (for single threads) or 'twist_inbox_mark_all_read' (for marking as read instead of archiving). It mentions an optional timestamp filter but doesn't explain when this filtering is appropriate or necessary.
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 full burden. It states the action but lacks critical behavioral details: it doesn't mention permissions required, whether unarchiving is reversible, what happens to thread visibility or notifications, or if there are rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
The description is front-loaded with the core action in the first sentence, followed by a brief parameter explanation. It's efficient with no wasted words, though the structure could be slightly improved by integrating the parameter info more seamlessly rather than as a separate 'Args:' section.
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 of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, return values, and how it fits with sibling tools. For a tool that modifies thread state, this leaves too much undefined for reliable agent use.
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 adds minimal semantics beyond the input schema: it specifies that 'id' is 'The ID of the thread to unarchive,' which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, this is adequate but not insightful—it doesn't explain ID format or sourcing, leaving room for improvement.
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 verb ('Unarchives') and resource ('a thread'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'twist_inbox_archive' beyond the obvious opposite action, missing an opportunity to clarify the relationship between archiving and unarchiving in this specific system.
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. With siblings like 'twist_inbox_get' and 'twist_threads_getone' that might retrieve thread status, there's no indication of prerequisites (e.g., whether the thread must be archived first) or context for when unarchiving is appropriate versus other actions like moving or updating threads.
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 full burden but offers minimal behavioral insight. It states the tool creates a thread but doesn't disclose permissions needed, rate limits, whether it's idempotent, what happens on failure, or the response format. This is inadequate for a mutation tool with zero annotation coverage.
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 structure is clear with a purpose statement followed by parameter list, but it's verbose with 11 parameter lines. Some descriptions like 'The title of the new thread' are redundant, and the format could be more streamlined without sacrificing clarity.
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 mutation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., error handling, side effects), usage guidelines, and output details, leaving significant gaps for an AI agent to operate effectively.
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 description lists all 11 parameters with brief explanations, adding significant value beyond the schema which has 0% description coverage. It clarifies purposes like 'The id of the channel' for channel_id and 'Displays the integration as the thread creator' for send_as_integration, though some explanations could be more detailed (e.g., what 'actions' entail).
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 verb 'Adds' and resource 'new thread to a channel', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'twist_threads_update' or 'twist_threads_move_to_channel', which would require explicit comparison for a perfect score.
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. The description doesn't mention prerequisites, when not to use it, or refer to sibling tools like 'twist_threads_update' for modifying existing threads or 'twist_threads_move_to_channel' for relocation.
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 full burden. It states the action ('marks all threads as read') but lacks critical behavioral details: whether this is reversible, what permissions are required, if it affects user notifications or history, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 efficiently structured with a clear main sentence followed by parameter explanations. Both sentences earn their place by stating the purpose and clarifying parameters, with no redundant or verbose language. It could be slightly improved by integrating parameter details more seamlessly, but it's well-front-loaded and 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 a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., effects, permissions), usage guidance relative to siblings, and detailed parameter semantics. The basic purpose and parameter listing are insufficient for safe and effective tool invocation in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (workspace_id and channel_id) and explains they identify the workspace or channel, adding basic semantics. However, it doesn't clarify the relationship between them (e.g., if both can be null, if channel_id implies workspace_id, or the scope when only one is provided), leaving ambiguity despite covering the 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?
The description clearly states the action ('marks all threads as read') and specifies the scope ('in the workspace or channel'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'twist_threads_mark_read' (singular) or 'twist_inbox_mark_all_read', leaving some ambiguity about when to choose this specific tool.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'twist_threads_mark_read' (for individual threads) or 'twist_inbox_mark_all_read' (for inbox vs threads), nor does it specify prerequisites, exclusions, or contextual triggers for choosing this bulk 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?
No annotations are provided, so the description carries full burden. It states the action ('marks unread') but doesn't disclose behavioral traits like whether this affects notifications, requires specific permissions, has side effects on other users, or what happens on success/failure. The parameter explanation adds some context but not enough for a mutation tool.
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 appropriately sized with two sentences: a purpose statement and parameter explanations. It's front-loaded with the main action. The parameter section is necessary given the 0% schema coverage, though the formatting could be slightly cleaner.
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 this is a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It explains parameters well but lacks information about behavioral aspects, return values, error conditions, or how this interacts with the sibling tools in the context.
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 description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'id' as the thread identifier and 'obj_index' with detailed explanation including the special value -1 for marking the whole thread unread. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Marks the thread as being unread') which is clear but vague about scope. It distinguishes from obvious opposites like 'mark_read' but doesn't differentiate from similar tools like 'twist_threads_clear_unread' or 'twist_threads_mark_unread_for_others' in the sibling 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 is provided. The description doesn't mention when this should be used instead of 'twist_threads_clear_unread' or 'twist_threads_mark_unread_for_others', nor does it specify any prerequisites or context for usage.
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 of behavioral disclosure. It states the action ('Moves') but doesn't describe effects (e.g., whether it preserves thread history, affects notifications, or requires specific permissions), error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are brief and relevant, though the structure could be improved by integrating usage context rather than listing args separately.
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 mutation tool with no annotations, no output schema, and low schema description coverage, the description is incomplete. It lacks details on behavioral effects, error handling, permissions, and how it interacts with sibling tools, leaving significant gaps for an AI agent to infer correct usage.
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 compensate. It adds basic meaning by naming parameters ('id' for the thread, 'to_channel' for the target) and implies their roles, but doesn't specify format details (e.g., integer ranges) or constraints beyond what the schema's types indicate. This provides marginal value over 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 the action ('Moves') and resource ('the thread'), specifying what the tool does. It distinguishes from siblings like 'twist_threads_get' or 'twist_threads_update' by focusing on relocation, but doesn't explicitly differentiate from similar tools like 'twist_threads_remove' or 'twist_threads_pin' in terms of purpose.
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. It doesn't mention prerequisites (e.g., thread must exist, user must have permissions), exclusions (e.g., cannot move to archived channels), or related tools like 'twist_threads_update' for other modifications.
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 of behavioral disclosure. It states the action (muting) and parameters but doesn't explain what muting entails (e.g., does it hide notifications, mark as read, affect other users?), whether it's reversible, requires permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter list. There's no wasted text, and it's structured for quick comprehension. However, the 'Args:' section could be integrated more smoothly, and it lacks additional context that might be necessary for completeness.
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 (a mutation tool with 2 parameters), no annotations, and no output schema, the description is incomplete. It covers the basic action and parameters but misses behavioral details (e.g., what muting does, error conditions, return values), usage context, and differentiation from siblings. For a tool that modifies thread state, this level of detail is insufficient.
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 compensate. It adds meaning by explaining 'id' as 'The id of the thread' and 'minutes' as 'The number of minutes to mute the thread', which clarifies the purpose of each parameter beyond the schema's basic types. However, it doesn't provide details like valid ranges for 'minutes' or format for 'id', leaving some gaps. This partial compensation earns a baseline score.
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's purpose: 'Mutes a thread for a number of minutes.' This is a specific verb+resource combination (mute + thread). However, it doesn't explicitly differentiate from sibling tools like 'twist_threads_unmute' or 'twist_threads_mark_unread', which could be related but distinct actions. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'twist_threads_unmute' for reversing the action, 'twist_threads_mark_unread' for similar notification control, or other thread management tools. There's no context on prerequisites, timing, or exclusions, leaving usage unclear.
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 full burden but only states the basic action ('Pins a thread'). It doesn't disclose behavioral traits such as permissions required, whether this is a destructive/mutative operation, rate limits, or what happens if the thread is already pinned. This leaves significant gaps for a mutation tool.
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 with two sentences, but the second sentence ('Args: id: The id of the thread') is redundant with the schema and could be omitted for better conciseness. The first sentence is clear but under-specified, making it efficient but not optimally structured.
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 complexity (a mutation operation with no annotations, no output schema, and low schema coverage), the description is incomplete. It doesn't explain what 'pinning' entails, the expected outcome, error conditions, or how it interacts with sibling tools, leaving the agent with insufficient context for reliable 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?
The description adds minimal but helpful context for the single parameter 'id' by specifying it's 'The id of the thread', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensates adequately, though more detail on format or constraints would be beneficial.
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 ('Pins') and resource ('a thread'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'twist_threads_star' or 'twist_threads_unpin' which might have similar conceptual purposes but different effects.
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 'twist_threads_unpin' or 'twist_threads_star'. The description lacks context about prerequisites, effects, or typical use cases, leaving the agent without usage direction.
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 states the tool 'Removes a thread' but doesn't clarify if this is permanent deletion, reversible, requires specific permissions, or has side effects (e.g., impact on related data). This leaves significant behavioral gaps for a mutation tool.
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 and front-loaded with the main action, followed by a brief parameter explanation. It avoids unnecessary words, though the structure could be slightly improved by integrating the parameter note more seamlessly.
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 complexity as a mutation operation with no annotations, no output schema, and incomplete parameter guidance, the description is inadequate. It fails to address critical aspects like permanence, permissions, or error handling, leaving the agent with insufficient context for safe invocation.
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 adds minimal semantics beyond the input schema: it specifies that 'id' is 'The id of the thread'. With 0% schema description coverage and only one parameter, this provides basic context, but doesn't elaborate on format, constraints, or examples, keeping it at the baseline for low coverage.
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 ('Removes') and resource ('a thread'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'twist_threads_move_to_channel' or 'twist_threads_archive' operations, which might also remove threads in different contexts.
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. With siblings like 'twist_threads_move_to_channel', 'twist_threads_archive', and 'twist_inbox_archive', it's unclear whether this is a permanent deletion, archiving, or something else, and no prerequisites or exclusions are 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('Unmutes') but doesn't disclose side effects, permissions required, rate limits, or what happens if the thread isn't muted. For a mutation tool with zero annotation coverage, this leaves critical gaps in understanding its behavior.
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 front-loaded with the core action ('Unmutes a thread.') and uses a clear 'Args:' section for parameters. It avoids unnecessary words, but the parameter explanation could be more informative (e.g., 'Thread ID as an integer'). Overall, it's efficient but slightly under-specified.
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 mutation nature, lack of annotations, no output schema, and low schema coverage (0%), the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, error conditions, or return values. For a tool that alters thread state, this leaves the agent with insufficient context to use it reliably.
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 adds basic semantics for the 'id' parameter ('The id of the thread'), which is helpful since schema description coverage is 0%. However, it doesn't specify format constraints (e.g., integer type, where to find the ID) or provide examples. With only one parameter, the baseline is 4, but the lack of detail reduces it to 3.
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 ('Unmutes') and resource ('a thread'), making the purpose immediately understandable. It distinguishes from siblings like 'twist_threads_mute' by specifying the opposite action. However, it doesn't specify what 'unmuting' entails in this context (e.g., notifications, visibility), which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., the thread must be muted first), contrast with similar tools like 'twist_threads_mute', or explain the effect of unmuting (e.g., restores notifications). The agent must infer usage from the name alone.
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 full burden but offers minimal behavioral insight. It states the action is 'unpins' which implies a mutation, but doesn't disclose permissions needed, whether it's reversible, side effects, or what happens if the thread isn't pinned. No rate limits or error conditions are mentioned.
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 appropriately brief with two sentences: a clear purpose statement followed by parameter documentation. It's front-loaded with the core action. The 'Args:' section is standard but could be integrated more seamlessly.
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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what 'unpinning' means in this context, what the response looks like, error scenarios, or how it interacts with other thread states (e.g., starred, muted).
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 compensate but only partially does. It documents the single parameter 'id' and states it's 'The id of the thread', which adds basic meaning. However, it doesn't explain format constraints, where to find thread IDs, or validation rules.
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 ('Unpins') and resource ('a thread'), making the purpose immediately understandable. It distinguishes from obvious opposites like 'twist_threads_pin' but doesn't explicitly differentiate from all sibling tools like 'twist_threads_remove' or 'twist_threads_update'.
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. The description doesn't mention prerequisites (e.g., thread must be pinned first), when not to use it, or how it relates to sibling tools like 'twist_threads_pin' or 'twist_threads_remove'.
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 of behavioral disclosure. It states the tool 'gets' a thread object, implying a read-only operation, but doesn't cover aspects like authentication requirements, error handling (e.g., for invalid IDs), rate limits, or what the return object includes. This leaves significant gaps for a tool with no annotation support.
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 appropriately sized and front-loaded, with the core purpose stated first ('Gets a thread object by id.') followed by parameter details. There's minimal waste, though the 'Args:' section could be integrated more seamlessly.
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 (one parameter) but lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'thread object' contains, how errors are handled, or any behavioral traits, making it inadequate for safe and effective use by an AI agent without additional 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?
The description adds meaningful context for the single parameter 'id' by specifying it as 'The id of the thread,' which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., valid ID ranges).
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's purpose as 'Gets a thread object by id,' which is a specific verb (gets) and resource (thread object). It distinguishes from siblings like twist_threads_get (likely lists threads) and twist_threads_get_unread (filters by unread status), but doesn't explicitly mention these distinctions in the description text itself.
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 no guidance on when to use this tool versus alternatives. It doesn't mention siblings like twist_threads_get (for listing threads) or twist_threads_get_unread (for unread threads), nor does it specify prerequisites or contexts for retrieval by ID.
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 states the action ('Marks the thread as being read') but doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens if the thread is already read, or any rate limits. The description is minimal and misses key operational 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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. It avoids unnecessary words, though the structure could be slightly improved by integrating the Args more seamlessly. Every sentence adds value, but it's very brief.
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 of a mutation tool with no annotations and no output schema, the description is incomplete. It covers the basic action and parameters but lacks information on behavioral aspects (e.g., side effects, error conditions) and return values. For a tool that modifies state, this leaves significant gaps for an AI agent.
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 description includes an 'Args' section that explains both parameters: 'id' as 'The id of the thread' and 'obj_index' as 'The index of the last known read message'. With schema description coverage at 0%, this adds significant meaning beyond the bare schema, clarifying the purpose of each parameter. However, it doesn't detail format constraints (e.g., integer ranges) or examples.
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's purpose with a specific verb ('Marks') and resource ('the thread as being read'), distinguishing it from siblings like twist_threads_mark_unread or twist_threads_clear_unread. However, it doesn't explicitly differentiate from twist_inbox_mark_all_read or twist_threads_mark_all_read, which are broader operations.
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 twist_threads_mark_all_read (for all threads) or twist_threads_clear_unread (which might have similar functionality). The description lacks context about prerequisites, such as whether the thread must be unread first, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Unstars') but doesn't mention permissions required, whether the change is reversible, error conditions, or what happens if the thread isn't starred. This is a significant gap for a mutation tool.
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 appropriately brief with a clear main sentence followed by parameter documentation. The two-sentence structure is efficient, though the Args formatting could be slightly more integrated with the main description.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'unstarring' means in this context, what the expected outcome is, or any behavioral details. The parameter documentation helps but doesn't compensate for the overall lack of 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?
The description adds meaningful context for the single parameter by specifying 'The id of the thread' in the Args section. With 0% schema description coverage and only one parameter, this adequately compensates and provides necessary semantic information beyond the basic 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 the action ('Unstars') and the resource ('a thread'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'twist_threads_star' or other thread manipulation tools, which would be needed for a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'twist_threads_star' for starring threads, nor does it explain prerequisites like needing a starred thread first. Usage context is implied but not stated.
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 full burden. 'Archives a thread' implies a mutation operation but doesn't disclose behavioral traits like whether this is reversible (hinting at twist_inbox_unarchive), what 'archive' means functionally, permission requirements, or side effects. This leaves significant gaps for a tool that modifies data.
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 and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. Every sentence earns its place with no wasted words, making it easy to parse quickly.
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 complexity (a mutation with no annotations or output schema) and rich sibling context, the description is incomplete. It doesn't explain what 'archive' entails, how it differs from deletion or hiding, or what the expected outcome is, leaving the agent with insufficient information for reliable 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?
With 0% schema description coverage and only one parameter, the description adds essential meaning by explaining 'id' as 'The ID of the thread to archive'. This compensates fully for the lack of schema documentation, making the parameter's purpose clear without redundancy.
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 ('Archives') and resource ('a thread'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like twist_inbox_archive_all or twist_inbox_unarchive, which would require more specific language about scope or reversibility.
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. With siblings like twist_inbox_archive_all (archive all threads) and twist_inbox_unarchive (reverse this action), the description lacks context on appropriate use cases, prerequisites, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't mention whether this is reversible, if it requires authentication, potential rate limits, or what happens to archived or muted threads. This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 of a mutation tool (marking all threads as read) with no annotations and no output schema, the description is insufficient. It doesn't explain the return value, error conditions, or side effects, leaving the agent with incomplete information to use the tool effectively.
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 tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add any parameter information, which is appropriate here, but it doesn't compensate for any gaps since there are none to address.
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 ('marks as read') and the resource ('all inbox threads in the workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'twist_threads_mark_all_read', which might cause confusion about scope (inbox vs. threads).
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 no guidance on when to use this tool versus alternatives like 'twist_threads_mark_all_read' or 'twist_inbox_archive_all'. It lacks context about prerequisites, such as whether the user needs specific permissions or if this applies to all inboxes or a specific one.
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 of behavioral disclosure. While 'Clears unread threads' implies a mutation operation, it doesn't specify whether this requires permissions, affects other users, is reversible, or has side effects. The description lacks critical behavioral context for a tool that modifies thread states.
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 with a single sentence that directly states the tool's purpose. There is zero wasted language, and it's front-loaded with the core action. Every word earns its place.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'clears' means operationally, what the tool returns, or how it differs from similar sibling tools. For a tool that likely modifies thread states, more context is needed.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps, earning a baseline score of 4 for this dimension.
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 ('Clears') and resource ('unread threads in workspace'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'twist_threads_mark_all_read' or 'twist_threads_mark_read', which likely serve similar unread management purposes.
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 no guidance on when to use this tool versus alternatives. With siblings like 'twist_threads_mark_all_read' and 'twist_threads_mark_read', it's unclear whether this tool clears unread status for all threads, specific threads, or has other differentiating behavior. No context or exclusions are 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 are provided, so the description carries full burden. It states the action ('marks as unread') but lacks critical behavioral details: required permissions (e.g., admin rights), whether it's reversible, rate limits, or what 'for others' entails (e.g., all users or specific groups). The description is minimal and doesn't compensate for the absence of annotations.
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 front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args:' section. It's efficient with minimal waste, though the parameter explanations could be slightly more detailed without losing conciseness.
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 no annotations, no output schema, and 2 parameters with 0% schema coverage, the description is moderately complete. It covers the purpose and parameter basics but lacks behavioral context (e.g., permissions, effects) and output details. For a mutation tool affecting others, this is a significant gap, though the parameter semantics help.
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 adds meaningful semantics for both parameters: 'id' as the thread identifier and 'obj_index' with specific behavior ('-1 marks the whole thread as unread'). This clarifies usage beyond the bare schema, though it could explain 'obj_index' values more fully (e.g., positive indices).
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 verb ('marks') and resource ('the thread') with a specific scope ('as being unread for others'), which distinguishes it from similar tools like 'twist_threads_mark_unread' that likely affect only the current user. However, it doesn't explicitly differentiate from all sibling tools beyond this implied distinction.
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 no guidance on when to use this tool versus alternatives like 'twist_threads_mark_unread' or 'twist_threads_clear_unread'. It mentions the effect ('for others') but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer context from tool names alone.
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 full burden. It states it's a read operation ('Gets') and implies authentication, but lacks details on rate limits, error handling, or return format. This is inadequate for a tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly.
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 low complexity (0 parameters, no output schema) and lack of annotations, the description is minimally adequate. It covers the basic purpose but misses behavioral details like response format or error cases, which are needed for full completeness.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, aligning with the 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 the action ('Gets') and resource ('inbox count'), specifying it's for a workspace and authenticated user. It distinguishes from siblings like twist_inbox_get (which likely retrieves inbox items) by focusing on count retrieval, though not explicitly contrasting them.
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. It doesn't mention when to prefer this over twist_inbox_get or other inbox-related tools, nor does it specify prerequisites or exclusions, leaving usage context implied.
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 full burden. It states it's a read operation ('Gets'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, error handling, or what 'unread' means contextually. For a tool with zero annotation coverage, this leaves significant 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential information.
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 has 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, and output format. For a read operation with no annotations, it should ideally provide more context about what 'unread threads' entails and how results are returned.
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 tool has 0 parameters, and schema description coverage is 100%. With no parameters to document, the description doesn't need to add parameter semantics. A baseline of 4 is appropriate as it's not required to compensate for any parameter gaps.
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 verb ('Gets') and resource ('unread threads'), specifying the scope ('in a workspace for the authenticated user'). It distinguishes from siblings like 'twist_threads_get' by focusing on unread threads, but doesn't explicitly contrast with other unread-related tools like 'twist_threads_clear_unread' or 'twist_inbox_get_count'.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when-not scenarios, prerequisites, or compare with siblings like 'twist_threads_get' (which might get all threads) or 'twist_inbox_get' (which might handle inbox-specific threads).
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 of behavioral disclosure. It states it 'Gets all threads' but doesn't describe what 'gets' entails (e.g., read-only operation, returns data in a specific format, pagination behavior, error conditions, or authentication requirements). The parameter details add some context but don't fully cover behavioral traits like rate limits 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?
The description is appropriately sized and well-structured: a clear purpose statement followed by a bullet-point list of parameters with concise explanations. Every sentence earns its place by providing essential information. It could be slightly more front-loaded with usage context, but overall it's efficient and organized.
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 complexity (13 parameters, no annotations, no output schema), the description is partially complete. It thoroughly documents parameters but lacks behavioral context (e.g., output format, error handling, authentication). For a tool with no structured fields beyond the input schema, this leaves gaps in understanding how the tool behaves in practice.
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 description coverage is 0%, so the description must compensate. It provides detailed semantics for all 13 parameters, including explanations of what each parameter does, default values, and constraints (e.g., 'default is 20, maximum is 500' for limit, filter options). This adds significant value beyond the bare schema, fully documenting parameter meanings.
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's purpose: 'Gets all threads in a channel.' This is a specific verb ('Gets') + resource ('threads in a channel'). However, it doesn't explicitly differentiate from sibling tools like 'twist_threads_getone' (gets one thread) or 'twist_threads_get_unread' (gets unread threads), which would be needed for a score of 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'twist_threads_getone' for single threads or 'twist_threads_get_unread' for filtered results, nor does it specify prerequisites or exclusions. The parameter documentation implies usage but doesn't offer explicit guidelines.
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 effectively describes the core functionality (retrieving inbox threads with filtering) and mentions default values, which adds useful context. However, it lacks information about authentication requirements, rate limits, error conditions, or pagination behavior, which are important for a retrieval tool with multiple parameters.
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 well-structured with a clear purpose statement followed by organized parameter documentation. Each parameter explanation is concise and informative. While efficient, the initial purpose statement could be slightly more detailed to better distinguish from sibling tools, but overall it's appropriately sized with minimal waste.
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 retrieval tool with 6 parameters and no output schema, the description provides good parameter documentation but lacks information about the return format, authentication requirements, and error handling. With no annotations and no output schema, the agent needs more context about what to expect from the response and any behavioral constraints.
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?
Given 0% schema description coverage, the description compensates fully by providing detailed parameter documentation. It explains all 6 parameters with clear semantics, including default values, constraints (e.g., 'maximum is 500'), valid values for enums (e.g., 'all', 'archived', 'active'), and usage context (e.g., 'based on last_updated attribute'). This adds significant value 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 the verb ('Get') and resource ("the authenticated user's inbox"), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like twist_inbox_get_count or twist_threads_get, which also retrieve inbox-related data, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. With multiple sibling tools for inbox and thread operations (e.g., twist_inbox_get_count, twist_threads_get), there's no indication of when this specific 'get inbox' tool is appropriate versus other retrieval tools, leaving the agent without contextual usage direction.
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:

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

Score Badge

Copy to your README.md:

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

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/mikemc/twist-mcp-server'

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