Skip to main content
Glama

get_quick_stats

Retrieve productivity metrics from Slack, Calendar, and Gmail without generating full summaries. Use this tool to analyze activity data quickly with customizable date ranges.

Instructions

Get quick productivity metrics (Slack, Calendar, Gmail) without generating a full summary. Fast lightweight query.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
days_backNoNumber of days to analyze (default: 7)
start_dateNoOptional start date in YYYY-MM-DD format
end_dateNoOptional end date in YYYY-MM-DD format

Implementation Reference

  • The main execution function for the 'get_quick_stats' tool. Calculates date range, generates lightweight data collection instructions for Slack, Calendar, and Gmail, processes optional stats data, and returns structured results.
    export async function getQuickStats(args) {
      const startTime = Date.now();
      
      try {
        // Calculate date range
        const { startDate, endDate, days } = calculateDateRange(args);
        
        // Generate lightweight data collection instructions
        const instructions = `
    # Quick Stats Data Collection
    
    Collect basic metrics for **${startDate} to ${endDate}** (${days} days):
    
    ## Slack Metrics
    Use mcp_playground-slack-mcp_slack_my_messages:
    - Count total messages
    - List top 5 channels by activity
    - Count threads participated in
    
    ## Calendar Metrics  
    Use mcp_gworkspace-mcp_calendar_events:
    - Count total events
    - Calculate total meeting hours
    - Identify longest meeting
    
    ## Gmail Metrics
    Use mcp_gworkspace-mcp_read_mail (lightweight - no body):
    - Count emails sent (from:me)
    - Count emails received
    - List top 3 email contacts
    
    Return raw counts and lists only - no deep analysis needed.
    `;
        
        const result = {
          success: true,
          message: 'Quick stats collection initiated. Follow instructions to gather lightweight metrics.',
          period: {
            start: startDate,
            end: endDate,
            days,
          },
          instructions,
          note: 'This tool provides a faster alternative to full summary generation. Collect basic metrics only without detailed analysis.',
        };
        
        // If stats data is provided, structure it
        if (args.stats_data) {
          result.stats = processStatsData(args.stats_data);
        }
        
        result.generation_time_ms = Date.now() - startTime;
        
        return result;
        
      } catch (error) {
        throw {
          code: error.code || 'STATS_FAILED',
          message: error.message || 'Failed to get quick stats',
          details: error.details || error.stack,
        };
      }
    }
  • JSON schema definition for the 'get_quick_stats' tool inputs, including parameters for date range specification.
    {
      name: 'get_quick_stats',
      description: 'Get quick productivity metrics (Slack, Calendar, Gmail) without generating a full summary. Fast lightweight query.',
      inputSchema: {
        type: 'object',
        properties: {
          days_back: {
            type: 'integer',
            description: 'Number of days to analyze (default: 7)',
            default: 7,
            minimum: 1,
            maximum: 90,
          },
          start_date: {
            type: 'string',
            description: 'Optional start date in YYYY-MM-DD format',
            pattern: '^\\d{4}-\\d{2}-\\d{2}$',
          },
          end_date: {
            type: 'string',
            description: 'Optional end date in YYYY-MM-DD format',
            pattern: '^\\d{4}-\\d{2}-\\d{2}$',
          },
        },
      },
    },
  • Tool dispatch registration in the main handler switch statement, routing 'get_quick_stats' calls to the getQuickStats implementation.
    case 'get_quick_stats':
      result = await getQuickStats(args);
      break;
  • Helper function to structure and normalize collected stats data from Slack, Calendar, and Email into a consistent format.
    function processStatsData(data) {
      return {
        slack: {
          total_messages: data.slack?.total_messages || 0,
          top_channels: data.slack?.top_channels || [],
          threads_participated: data.slack?.threads_participated || 0,
          reactions_given: data.slack?.reactions_given || 0,
          reactions_received: data.slack?.reactions_received || 0,
        },
        calendar: {
          total_events: data.calendar?.total_events || 0,
          total_meeting_hours: data.calendar?.total_meeting_hours || 0,
          average_daily_meetings: data.calendar?.average_daily_meetings || 0,
          longest_meeting_hours: data.calendar?.longest_meeting_hours || 0,
          focus_time_hours: data.calendar?.focus_time_hours || 0,
        },
        email: {
          total_emails: data.email?.total_emails || 0,
          emails_sent: data.email?.emails_sent || 0,
          emails_received: data.email?.emails_received || 0,
          top_contacts: data.email?.top_contacts || [],
        },
      };
    }
  • Import statement registering the getQuickStats handler function for use in the main tool dispatcher.
    import { getQuickStats } from './quick-stats.js';
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 mentions 'fast lightweight query' which hints at performance characteristics, but doesn't describe what specific metrics are returned, whether authentication is required, rate limits, error conditions, or the format of the response. For a tool with no annotations and no output schema, this leaves significant 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.

Conciseness5/5

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

The description is two concise sentences that efficiently convey purpose and key characteristics. Every word earns its place: 'Get quick productivity metrics' establishes the core function, '(Slack, Calendar, Gmail)' specifies scope, 'without generating a full summary' differentiates from siblings, and 'Fast lightweight query' adds behavioral context. No wasted words.

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 no annotations, no output schema, and 3 parameters, the description is incomplete. While it clearly states purpose and differentiates from some siblings, it lacks details about what metrics are returned, authentication requirements, rate limits, or error handling. For a tool that presumably returns productivity data across multiple services, more context about the output format and behavioral constraints would be helpful.

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%, with all three parameters (days_back, start_date, end_date) well-documented in the schema including descriptions, defaults, and constraints. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

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 verb 'Get' and the resource 'quick productivity metrics (Slack, Calendar, Gmail)', specifying what data sources are included. It distinguishes from siblings by noting it provides 'quick metrics without generating a full summary', differentiating it from summary-generation tools like generate_daily_summary or get_summary. However, it doesn't explicitly contrast with compare_periods or list_summaries.

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 context by stating 'without generating a full summary' and 'fast lightweight query', suggesting this tool is for quick overviews rather than detailed reports. It doesn't explicitly state when to use this tool versus alternatives like compare_periods or list_summaries, nor does it provide exclusions or prerequisites. The guidance is present but not comprehensive.

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/philipbloch/summary-mcp'

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