Skip to main content
Glama
crazyrabbitLTC

Twitter MCP Server

markAsRead

Mark Twitter direct messages as read to manage your inbox and track conversations. Requires message ID input and may need special API access.

Instructions

Mark direct messages as read (Note: May require special API access)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageIdYesThe ID of the message to mark as read
conversationIdNoOptional conversation ID for context

Implementation Reference

  • The main handler function that executes the markAsRead tool logic, checking for Twitter client and attempting to mark the message as read (placeholder implementation noting API limitations).
    export const handleMarkAsRead: TwitterHandler<MarkAsReadArgs> = async (
        client: TwitterClient | null,
        { messageId, conversationId }: MarkAsReadArgs
    ): Promise<HandlerResponse> => {
        if (!client) {
            return createMissingTwitterApiKeyResponse('markAsRead');
        }
        try {
            // Note: The Twitter API v2 doesn't have a direct "mark as read" endpoint
            // This would typically be handled through the conversation update endpoint
            // For now, we'll provide a placeholder implementation
            
            // In a real implementation, you might need to:
            // 1. Get the authenticated user's ID
            // 2. Update the conversation state
            // 3. Use private API endpoints that may not be publicly available
    
            const userId = await client.v2.me().then(response => response.data.id);
            
            // This is a conceptual implementation - the actual API endpoint may vary
            // The Twitter API v2 may not expose this functionality directly
            console.log(`Attempting to mark message ${messageId} as read for user ${userId}`);
            
            return createResponse(`Message ${messageId} marked as read. Note: This functionality may require special API access or may not be available in the public Twitter API v2.`);
        } catch (error) {
            if (error instanceof Error) {
                if (error.message.includes('404')) {
                    throw new Error(`Failed to mark message as read: Message ${messageId} not found.`);
                }
                throw new Error(`${formatTwitterError(error, 'marking message as read')}. Note: This functionality may not be available in the public Twitter API v2.`);
            }
            throw error;
        }
    };
  • src/tools.ts:565-581 (registration)
    Tool registration in the TOOLS object, defining the description and input schema for the markAsRead tool used by MCP.
    markAsRead: {
        description: 'Mark direct messages as read (Note: May require special API access)',
        inputSchema: {
            type: 'object',
            properties: {
                messageId: { 
                    type: 'string', 
                    description: 'The ID of the message to mark as read' 
                },
                conversationId: { 
                    type: 'string', 
                    description: 'Optional conversation ID for context' 
                }
            },
            required: ['messageId']
        }
    },
  • TypeScript interface defining the input arguments for the markAsRead handler.
    export interface MarkAsReadArgs {
        messageId: string;
        conversationId?: string;
    }
  • src/index.ts:368-374 (registration)
    Dispatch/registration in the main server request handler switch statement that routes calls to the markAsRead tool to its handler function.
    case 'markAsRead': {
        const { messageId, conversationId } = request.params.arguments as {
            messageId: string;
            conversationId?: string;
        };
        response = await handleMarkAsRead(client, { messageId, conversationId });
        break;
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. It discloses that the tool performs a mutation ('mark as read') and hints at an access requirement ('may require special API access'), which adds useful context. However, it doesn't describe what 'mark as read' entails operationally (e.g., whether it updates server state, affects notifications, or has side effects), leaving behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose upfront. The parenthetical note about API access is relevant but could be integrated more smoothly. 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 mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the basic action and a potential access constraint, but lacks details on behavior, error conditions, or return values, which are important given the tool's mutative nature and context among many sibling tools.

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 100%, so the schema fully documents both parameters. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where the schema handles the documentation burden.

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 ('mark as read') and resource ('direct messages'), making the purpose unambiguous. However, it doesn't differentiate this tool from potential siblings like 'getDirectMessages' or 'getDirectMessageEvents' that might also handle message status, though those appear to be read-only 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?

The description provides no guidance on when to use this tool versus alternatives. It mentions a special API access requirement, but doesn't specify conditions, prerequisites, or exclusions for usage relative to other messaging tools in the sibling list.

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/crazyrabbitLTC/mcp-twitter-server'

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