Skip to main content
Glama

conversations_by_date

Retrieve conversations from any specific date in YYYY-MM-DD format. Select date and optional limit to get a focused set of indexed chat history from your AI interactions.

Instructions

Get conversations from a specific date (YYYY-MM-DD format).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Handler function for the 'conversations_by_date' MCP tool. Queries the DuckDB conversations view for conversations on a specific date (YYYY-MM-DD), returning a formatted markdown string with conversation IDs, titles, sources, and models.
    @mcp.tool()
    def conversations_by_date(date: str, limit: int = 30) -> str:
        """
        Get conversations from a specific date (YYYY-MM-DD format).
        """
        con = get_conversations()
        results = con.execute("""
            SELECT DISTINCT conversation_id, conversation_title, source, model, created
            FROM conversations
            WHERE CAST(created AS DATE) = CAST(? AS DATE)
            ORDER BY created DESC
            LIMIT ?
        """, [date, limit]).fetchall()
    
        if not results:
            return f"No conversations found on {date}"
    
        output = [f"## Conversations on {date} ({len(results)} found)\n"]
        for conv_id, title, source, model, _ in results:
            output.append(f"- **{title or 'Untitled'}**")
            output.append(f"  {source}/{model} | ID: {conv_id[:20]}...")
        return "\n".join(output)
  • Registration function that registers the conversations_by_date tool (along with others) via the @mcp.tool() decorator. Called from server.py line 43.
    def register(mcp):
        """Register conversation tools with the MCP server."""
  • Server entry point imports and calls tools_conversations.register(mcp) which registers conversations_by_date as an MCP tool.
    from . import tools_conversations
    from . import tools_search
    from . import tools_synthesis
    from . import tools_stats
    from . import tools_prosthetic
    from . import tools_github
    from . import tools_analytics
    
    tools_conversations.register(mcp)
    tools_search.register(mcp)
  • Helper that provides the DuckDB connection with a conversations view over parquet data, used by the conversations_by_date handler to query conversation data.
    def get_conversations() -> duckdb.DuckDBPyConnection:
        """Get cached DuckDB connection with conversations view.
    
        Automatically checks for new source data and re-ingests if needed
        (lazy sync — no background threads, just mtime checks).
        """
        global _conversations_db
    
        # Lazy sync: check for new files before serving
        _check_and_sync()
    
        cfg = get_config()
        if _conversations_db is None:
            if not cfg.parquet_path.exists():
                raise FileNotFoundError(
                    f"Conversations parquet not found at {cfg.parquet_path}. "
                    "Run the ingest pipeline first."
                )
            _conversations_db = duckdb.connect()
            _conversations_db.execute(f"""
                CREATE VIEW IF NOT EXISTS conversations
                AS SELECT * FROM read_parquet('{cfg.parquet_path}')
            """)
        return _conversations_db
  • Dashboard tool registry entry describing the conversations_by_date tool's name, description, category, required resources, parameters, and probe data for testing.
    {
        "name": "conversations_by_date",
        "description": "What happened on a specific date",
        "category": "Conversation",
        "requires": ["conversations"],
        "params": {"date": "str"},
        "probe": {"date": "2025-01-15"},
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 it retrieves conversations by date, omitting key details like read-only nature, pagination (via limit), or scope. This is insufficient for safe invocation.

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 concise (one sentence) but under-specifies. It could be expanded with key details (e.g., return format) without becoming verbose.

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?

Without annotations and param descriptions, the description is too minimal. The output schema exists but is not leveraged. The tool's behavior (e.g., scope, sorting) is unclear, leaving gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should elaborate on parameters. It only mentions the date format. The 'limit' parameter's purpose is implied but not explicitly described, and no default behavior is explained. This adds negligible value over 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 ('Get conversations') and the filter ('specific date'), with the date format specified. It distinguishes from siblings like 'search_conversations' and 'get_conversation' by focusing on date-based retrieval.

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?

The description implies usage when a specific date is known but provides no guidance on when to avoid this tool or alternatives. No comparisons to sibling tools are made.

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/mordechaipotash/brain-mcp'

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