Skip to main content
Glama
heroku

Heroku MCP server

Official
by heroku

pg_outliers

Identify and optimize resource-intensive database operations on Heroku MCP server. Analyze slow queries, track performance patterns, and improve database workload efficiency.

Instructions

Identify resource-intensive database operations. Use this tool when you need to: 1) Find slow or expensive queries, 2) Analyze query performance patterns, 3) Optimize database workload, 4) Track query statistics over time. The tool helps identify opportunities for performance optimization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesThe name of the Heroku app whose query statistics to analyze.
databaseNoConfig var containing the connection string, unique name, ID, or alias of the database. To access another app's database, prepend the app name to the config var or alias with `APP_NAME::`. If omitted, DATABASE_URL is used.
numNoThe number of queries to display. Defaults to 10.
resetNoWhen true, resets statistics gathered by pg_stat_statements.
truncateNoWhen true, truncates queries to 40 characters.

Implementation Reference

  • Handler function that constructs the 'heroku pg:outliers' command using CommandBuilder with options, executes it via HerokuREPL, and returns processed output.
    async (options: PgOutliersOptions): Promise<McpToolResponse> => {
      const command = new CommandBuilder(TOOL_COMMAND_MAP.PG_OUTLIERS)
        .addFlags({
          app: options.app,
          num: options.num?.toString(),
          reset: options.reset,
          truncate: options.truncate
        })
        .addPositionalArguments({ database: options.database })
        .build();
    
      const output = await herokuRepl.executeCommand(command);
      return handleCliOutput(output);
    }
  • Zod schema defining the input parameters for the pg_outliers tool, including app, num, reset, truncate, and database.
    export const pgOutliersOptionsSchema = z.object({
      app: z.string().describe('Target app name'),
      num: z.number().optional().describe('Number of queries to show. Default: 10'),
      reset: z.boolean().optional().describe('Reset pg_stat_statements stats'),
      truncate: z.boolean().optional().describe('Truncate queries to 40 chars'),
      database: z
        .string()
        .optional()
        .describe('Database identifier. Format: APP_NAME::DB for other apps. Default: DATABASE_URL')
    });
  • Registration function that registers the 'pg_outliers' tool with the MCP server, providing name, description, schema, and handler.
    export const registerPgOutliersTool = (server: McpServer, herokuRepl: HerokuREPL): void => {
      server.tool(
        'pg_outliers',
        'Find resource-heavy queries: performance, patterns, optimization',
        pgOutliersOptionsSchema.shape,
        async (options: PgOutliersOptions): Promise<McpToolResponse> => {
          const command = new CommandBuilder(TOOL_COMMAND_MAP.PG_OUTLIERS)
            .addFlags({
              app: options.app,
              num: options.num?.toString(),
              reset: options.reset,
              truncate: options.truncate
            })
            .addPositionalArguments({ database: options.database })
            .build();
    
          const output = await herokuRepl.executeCommand(command);
          return handleCliOutput(output);
        }
      );
    };
  • src/index.ts:80-80 (registration)
    Invocation of the pg_outliers tool registration during server initialization.
    data.registerPgOutliersTool(server, herokuRepl);
  • Constant mapping the PG_OUTLIERS key to the Heroku CLI command 'pg:outliers' used in the tool handler.
    PG_OUTLIERS: 'pg:outliers',
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 the tool helps 'identify opportunities for performance optimization' and 'track query statistics over time', which implies read-only analysis, but doesn't explicitly state whether it's safe (non-destructive) or has side effects. It doesn't disclose that the 'reset' parameter can modify database statistics (a behavioral trait), nor does it cover permissions, rate limits, or output format. For a tool with parameters that can reset data, this is a significant gap in transparency.

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 front-loaded: it starts with the core purpose ('Identify resource-intensive database operations'), then lists four specific use cases in a bullet-like format, and ends with a summary sentence. Every sentence adds value by clarifying when and why to use the tool. There's no redundant or vague language, though it could be slightly more structured (e.g., separating purpose from guidelines more clearly).

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 tool's complexity (performance analysis with potential side effects via 'reset'), lack of annotations, and no output schema, the description is moderately complete. It covers the 'why' and high-level 'when' but misses critical behavioral details (e.g., that 'reset' modifies data, what the output looks like). For a tool with 5 parameters and no structured safety hints, it should do more to explain risks and results, leaving gaps in contextual understanding.

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 already documents all five parameters thoroughly (e.g., 'app' for Heroku app name, 'reset' for resetting statistics). The description doesn't add any parameter-specific information beyond what's in the schema—it focuses on high-level use cases instead. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra semantic context but doesn't detract either.

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: 'Identify resource-intensive database operations' and lists specific use cases (find slow queries, analyze performance patterns, optimize workload, track statistics). It distinguishes itself from sibling tools by focusing on database performance analysis rather than app management, deployment, or other pg_* operations like backups or maintenance. However, it doesn't explicitly differentiate from all pg_* tools (e.g., pg_locks, pg_ps) in the same domain.

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 provides implied usage guidelines by listing four scenarios when to use the tool (e.g., 'Find slow or expensive queries', 'Optimize database workload'). However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools (e.g., pg_locks for lock analysis, pg_ps for process listing, or get_app_logs for broader app monitoring). The guidance is helpful but lacks exclusion criteria or direct sibling comparisons.

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

Related 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/heroku/heroku-mcp-server'

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