Skip to main content
Glama
mikemc
by mikemc

twist_threads_get

Retrieve threads from a Twist channel with filtering options by date, status, and relevance to manage discussions effectively.

Instructions

Gets all threads in a channel.

Args: channel_id: The id of the channel as_ids: If enabled, only the ids of the threads are returned filter_by: A filter can be one of "attached_to_me" or "everyone". Default is "everyone" limit: Limits the number of threads returned (default is 20, maximum is 500) newer_than_ts: Limits threads to those newer when the specified Unix time older_than_ts: Limits threads to those older when the specified Unix time before_id: Limits threads to those with a lower than the specified id after_id: Limits threads to those with a higher than the specified id workspace_id: The id of the workspace is_pinned: If enabled, only pinned threads are returned is_starred: If enabled, only starred threads are returned order_by: The order of the threads returned. Either "desc" (default) or "asc" exclude_thread_ids: The thread ids that should be excluded from the results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channel_idYes
as_idsNo
filter_byNo
limitNo
newer_than_tsNo
older_than_tsNo
before_idNo
after_idNo
workspace_idNo
is_pinnedNo
is_starredNo
order_byNo
exclude_thread_idsNo

Implementation Reference

  • Handler function that implements the core logic of twist_threads_get tool by calling Twist API endpoint threads/get with provided parameters.
    def twist_threads_get(
        ctx: Context,
        channel_id: int,
        as_ids: Optional[bool] = None,
        filter_by: Optional[str] = None,
        limit: Optional[int] = None,
        newer_than_ts: Optional[int] = None,
        older_than_ts: Optional[int] = None,
        before_id: Optional[int] = None,
        after_id: Optional[int] = None,
        workspace_id: Optional[int] = None,
        is_pinned: Optional[bool] = None,
        is_starred: Optional[bool] = None,
        order_by: Optional[str] = None,
        exclude_thread_ids: Optional[List[int]] = None
    ) -> Union[str, List[Dict[str, Any]]]:
        """Gets all threads in a channel.
    
        Args:
            channel_id: The id of the channel
            as_ids: If enabled, only the ids of the threads are returned
            filter_by: A filter can be one of "attached_to_me" or "everyone". Default is "everyone"
            limit: Limits the number of threads returned (default is 20, maximum is 500)
            newer_than_ts: Limits threads to those newer when the specified Unix time
            older_than_ts: Limits threads to those older when the specified Unix time
            before_id: Limits threads to those with a lower than the specified id
            after_id: Limits threads to those with a higher than the specified id
            workspace_id: The id of the workspace
            is_pinned: If enabled, only pinned threads are returned
            is_starred: If enabled, only starred threads are returned
            order_by: The order of the threads returned. Either "desc" (default) or "asc"
            exclude_thread_ids: The thread ids that should be excluded from the results
        """
        all_params = locals()
        token = ctx.request_context.lifespan_context.twist_token
        params = {k: v for k, v in all_params.items() if k != 'ctx' and v is not None}
    
        try:
            logger.info(f"Getting threads for channel ID: {channel_id}")
            threads_data = twist_request("threads/get", params=params, token=token)
    
            if not threads_data:
                logger.info("No threads found")
                return "No threads found"
    
            logger.info(f"Retrieved {len(threads_data)} threads")
            return threads_data
        except Exception as error:
            logger.error(f"Error getting threads: {error}")
            return f"Error getting threads: {str(error)}"
  • main.py:42-48 (registration)
    Dynamic registration code that registers all twist_ prefixed functions from threads.py (including twist_threads_get) as MCP tools using FastMCP.tool() decorator.
    # 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)
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.

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