Skip to main content
Glama
ilhankilic

YaparAI MCP Server

by ilhankilic

read_conversation

Read the full message history of a social media DM or comment thread by providing conversation and account IDs.

Instructions

Read messages in a social media conversation.

Get the full message history of a DM or comment thread.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
conversation_idYesConversation ID (from list_inbox results)
account_idYesSocial account ID that received the messages
org_idNoOrganization ID (uses YAPARAI_ORG_ID env var if not provided)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'read_conversation' tool. It takes conversation_id, account_id, and optional org_id, resolves org_id, and calls client.social_get_conversation() to fetch full message history of a DM or comment thread.
    async def read_conversation(
        conversation_id: str,
        account_id: str,
        org_id: str | None = None,
    ) -> dict:
        """
        Read messages in a social media conversation.
    
        Get the full message history of a DM or comment thread.
    
        Args:
            conversation_id: Conversation ID (from list_inbox results)
            account_id: Social account ID that received the messages
            org_id: Organization ID (uses YAPARAI_ORG_ID env var if not provided)
    
        Returns:
            Dict with conversation messages, sender info, and timestamps.
        """
        oid = resolve_org_id(org_id)
        client = YaparAIClient()
        return await client.social_get_conversation(oid, conversation_id, account_id)
  • The tool registration line where 'read_conversation' is registered with the MCP server via mcp.tool().
    mcp.tool(read_conversation)
  • The underlying API client method (social_get_conversation) that sends the actual HTTP GET request to the conversation endpoint with the account_id parameter.
    async def social_get_conversation(self, org_id: str, conv_id: str, account_id: str) -> dict:
        """Get conversation messages."""
        return await self._request(
            "GET",
            f"/api/enterprise/orgs/{org_id}/social/inbox/{conv_id}",
            params={"account_id": account_id},
        )
  • Helper utility that resolves the org_id parameter (uses YAPARAI_ORG_ID env var as fallback). Used by the read_conversation handler.
    def resolve_org_id(org_id: str | None = None) -> str:
        """Return the org_id from parameter or YAPARAI_ORG_ID env var.
    
        Raises ValueError if neither is set.
        """
        oid = org_id or YAPARAI_ORG_ID
        if not oid:
            raise ValueError(
                "Organization ID is required. Either pass org_id parameter "
                "or set the YAPARAI_ORG_ID environment variable. "
                "Use list_organizations() to find your org ID."
            )
        return oid
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only states the tool reads messages, but does not disclose any side effects, authentication needs, rate limits, or error conditions.

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?

Two succinct sentences that clearly communicate the tool's purpose without any superfluous words. Each sentence adds value.

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?

The tool is low in complexity and has a high schema coverage and an output schema. The description covers the basics but lacks behavioral details; however, it is adequate for a simple read operation.

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 baseline is 3. The description adds no extra meaning beyond what the schema already provides for the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'read' and resource 'messages in a social media conversation', and specifies 'full message history' for DM or comment threads. This distinguishes it from siblings like list_inbox (list) and reply_to_message (write).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like list_inbox or reply_to_message. The parameter description hints that conversation_id comes from list_inbox, but the description itself lacks such context.

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/ilhankilic/yaparai-mcp'

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