Skip to main content
Glama
mikemc
by mikemc

twist_inbox_archive

Archive threads in Twist workspaces to organize your inbox by removing completed or inactive conversations.

Instructions

Archives a thread.

Args: id: The ID of the thread to archive

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Implementation Reference

  • The handler function that executes the tool logic: archives a specific inbox thread by its ID using the Twist API endpoint 'inbox/archive'.
    def twist_inbox_archive(
        ctx: Context,
        id: int
    ) -> str:
        """Archives a thread.
    
        Args:
            id: The ID of the thread to archive
        """
        token = ctx.request_context.lifespan_context.twist_token
    
        params = {"id": id}
    
        try:
            logger.info(f"Archiving thread with ID: {id}")
    
            result = twist_request("inbox/archive", params=params, token=token, method="POST")
    
            logger.info(f"Successfully archived thread with ID: {id}")
            return f"Successfully archived thread with ID: {id}"
        except Exception as error:
            logger.error(f"Error archiving thread: {error}")
            return f"Error archiving thread: {str(error)}"
  • main.py:42-48 (registration)
    Dynamic registration of all functions starting with 'twist_' from src.inbox and src.threads modules as MCP tools using FastMCP.tool() decorator. This registers 'twist_inbox_archive'.
    # Register all tools from tool modules
    for module in [src.inbox, src.threads]:
        for name, func in inspect.getmembers(module, inspect.isfunction):
            if name.startswith('twist_') and func.__module__ == module.__name__:
                logger.info(f"Registering tool: {name}")
                mcp.tool()(func)
  • Helper function used by the handler to make the actual API request to Twist's 'inbox/archive' endpoint.
    def twist_request(endpoint, params=None, token=None, method="GET"):
        """
        Make an API request to Twist.
    
        Args:
            endpoint (str): API endpoint to call (without the base URL)
            params (dict, optional): Dictionary of parameters to include in the request
            token (str, optional): Authentication token (if None, uses the one from get_api_client)
            method (str, optional): HTTP method to use (default: "GET")
    
        Returns:
            dict: Response data as a dictionary
    
        Raises:
            Exception: If the API request fails
        """
        if token is None:
            token = get_api_client()
    
        base_url = "https://api.twist.com/api/v3/"
        headers = {"Authorization": f"Bearer {token}"}
        url = f"{base_url}{endpoint}"
    
        try:
            if method == "GET":
                response = requests.get(url, params=params, headers=headers)
            elif method == "POST":
                response = requests.post(url, data=params, headers=headers)
            else:
                raise ValueError(f"Unsupported HTTP method: {method}")
    
            response.raise_for_status()  # Raise an exception for 4XX/5XX responses
            return response.json()
        except requests.exceptions.RequestException as e:
            logger.error(f"Twist API request failed: {e}")
            raise
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.

Install Server

Other Tools

Latest Blog Posts

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