Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Wp db tables

wordpress_specialist_wp_db_tables
Read-only

Retrieve per-table row counts and data/index sizes to identify which WordPress database table is causing bloat.

Instructions

[UNIFIED] Read per-table size + row breakdown. Returns {database_name, table_prefix, tables: [{name, engine, rows, data_bytes, index_bytes, total_bytes, collation}]} ordered by total_bytes descending. Same source as wp_db_size — one row per WP table. Useful for 'which table is the bloat?' debugging (commonly options, postmeta, comments, or a plugin's log table). Requires Airano MCP Bridge v2.18.0+ and manage_options.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>"
    },
    "name": "wordpress_specialist_wp_db_tables"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so: it discloses the auth requirement (manage_options), the bridge version dependency (v2.18.0+), and the sort order (total_bytes descending). Error behavior and cost of the call are not covered, keeping it from a 5.

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?

Purpose is front-loaded in the first clause and the longer return-shape block follows, which is the right order. The inline object literal is bulky, but since there is no output schema it earns most of its space.

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

Completeness4/5

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

For a read-only, one-parameter tool with no output schema, the description supplies the return shape, ordering, prerequisites, and a debugging rationale — enough to call it correctly. The unaddressed `site` parameter is the main remaining hole.

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

Parameters2/5

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

The single required `site` parameter has 0% schema description coverage, and the description never mentions it — no guidance on whether it is a slug, ID, or URL. With one undocumented parameter and no compensating text, this falls below the 3 baseline.

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?

"[UNIFIED] Read per-table size + row breakdown" gives a specific verb (read) and resource (per-table size/rows), and the note "Same source as wp_db_size — one row per WP table" positions it against the nearest sibling. An agent can tell this is the per-table detail view rather than the aggregate.

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

Usage Guidelines4/5

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

It names the concrete use case — "which table is the bloat?" debugging — and even lists the usual culprits (options, postmeta, comments, plugin log tables). It stops short of an explicit rule for when to prefer this over wp_db_size, so it is clear context without full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools