Pg Slow Queries

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 does not state whether this is a read-only operation, whether it queries pg_stat_statements directly, whether it requires specific permissions, what time range or ordering is applied, or what the output contains. The parenthetical mention of pg_stat_statements hints at the data source but adds no behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is extremely short, which is concise, but it is under-specified rather than efficiently informative. It is front-loaded with the topic but does not earn its place as a complete tool definition. A single noun phrase is not enough for a tool with a generic schema and no annotations.

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

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

Given the generic schema (any object), no annotations, and no output schema details, the description is incomplete. An agent cannot know what arguments to pass, what the tool returns, or how it behaves. The output schema exists but is not shown in the provided context, so the description should still explain the tool's purpose and parameters. It does not.

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

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

The schema has one 'params' field that accepts any object or null, with 0% schema description coverage. The description does not explain what parameters can be passed (e.g., limit, order, time range). Since the schema is a generic passthrough, the description should compensate by documenting accepted parameters, but it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Медленные запросы (pg_stat_statements)' translates to 'Slow queries (pg_stat_statements)'. It identifies the resource (slow queries from pg_stat_statements) but lacks a verb and doesn't explain what the tool does with them (lists? analyzes? returns?). It is a noun phrase rather than a clear action statement, and it doesn't distinguish it from sibling tools like pg_stats or pg_activity beyond the topic.

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

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

No guidance is provided about when to use this tool versus alternatives. The sibling list includes many PostgreSQL tools (pg_connections, pg_locks, pg_activity, pg_stats, pg_replication, pg_tables) and the description does not state when slow queries are the right choice. The only implied context is the pg_stat_statements source, which is not enough to route an agent.

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