Skip to main content
Glama
snss10

DBeast

by snss10
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

maintenance_analysis

Analyze database maintenance status including indexes, vacuum, table bloat, and foreign keys. Identify unused or duplicate indexes, tables needing vacuum, and missing foreign key indexes.

Instructions

Table and index maintenance - analyzes indexes, vacuum status, table bloat, FK indexes.

LEVEL: Database ↔ Schema ↔ Table (multi-level tool)

  • schema='all': Database level - maintenance status for ALL schemas

  • schema='': Schema level - all tables in that schema (supports ANY schema name: 'sales', 'billing', 'auth', 'analytics', etc.)

  • table='users': Table level - specific table analysis

REQUIRED: Specify schema explicitly - use 'all' for all schemas or a specific schema name.

USE FOR: finding unused indexes, duplicate indexes, tables needing vacuum, FK missing indexes, table sizes, TOAST analysis, autovacuum status, "which indexes should I drop?". DO NOT USE FOR: live connections/locks (use database_health), slow query history (use query_performance), specific query optimization (use query_optimizer), schema structure (use get_schema), partitioned tables (use partition_analysis). STATIC: Analyzes stored statistics, not real-time activity.

ERROR RECOVERY:

  • "not connected": Call connect() first or pass url parameter

  • "schema not found": Verify schema exists with get_schema()

  • Large payload: Use summary_only=True or include='indexes' to filter results

  • "permission denied": User needs read access to pg_catalog views

INCLUDE OPTIONS:

  • 'all': Everything (default)

  • 'indexes': All indexes, unused indexes, duplicate indexes, tables needing indexes, largest indexes

  • 'tables': Table statistics, hot tables (most active)

  • 'vacuum': Bloated tables, never vacuumed, tables needing freeze, autovacuum settings

  • 'fk_indexes': Foreign keys missing supporting indexes

  • 'toast': TOAST storage analysis (large object storage)

Examples: maintenance_analysis() - All tables in public schema (default) maintenance_analysis(schema='all') - All schemas (database-wide) maintenance_analysis(schema='billing') - All tables in billing schema maintenance_analysis(schema='auth', table='users') - Specific table in auth schema maintenance_analysis(include='indexes') - Only index analysis maintenance_analysis(include='vacuum') - Only vacuum/bloat analysis maintenance_analysis(include='fk_indexes') - Only FK index analysis

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
includeNoWhat to include: 'all', 'indexes', 'tables', 'vacuum', 'fk_indexes', 'toast'all
tableNoSpecific table (or all tables if not specified)
schemaNoSchema to analyze. Omit for all schemas, or specify one. Use get_schema() to list available.
urlNoDatabase URL for auto-connection
formatNoOutput format: 'json' or 'markdown'json
summary_onlyNoReturn only summary counts and issues, not detailed lists

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the tool is 'STATIC: Analyzes stored statistics, not real-time activity' and explains the multi-level behavior (database, schema, table). It also covers error recovery. However, it does not explicitly state if the tool is read-only (implied but not stated), which slightly reduces 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 lengthy but well-structured with sections (LEVEL, REQUIRED, USE FOR, DO NOT USE FOR, STATIC, ERROR RECOVERY, INCLUDE OPTIONS, Examples). It front-loads the core purpose and uses bullet points for readability. While not maximally concise, the structure compensates.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, multi-level scope, multiple include options), the description is comprehensive. It covers error recovery, examples, parameter details, and usage boundaries. With an output schema present, return values are documented elsewhere, so this description provides sufficient context for an agent to invoke the tool correctly.

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

Parameters4/5

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

Schema description coverage is 100% (all 6 parameters described in schema). The description adds significant value beyond the schema: it explains the 'include' options in detail, provides examples for schema/table parameters, and clarifies the behavior of default values. This goes beyond the baseline of 3.

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 tool's function: 'Table and index maintenance - analyzes indexes, vacuum status, table bloat, FK indexes.' It also lists specific use cases like finding unused indexes, duplicate indexes, etc., and distinguishes from sibling tools through the 'DO NOT USE FOR' section.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use ('USE FOR') and when not to use ('DO NOT USE FOR'), including specific sibling tool names. It also offers examples and error recovery steps, making it exceptionally clear for an agent.

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/snss10/DBeast'

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