Skip to main content
Glama
antonbabenko

Deliberation

by antonbabenko
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

analyze

Read-only

Inspect recent debug-log timings and session verdicts to receive advisory tuning suggestions (disable slow/redundant models, lower reasoning, adjust fanout). Local, read-only, with timing and agreement lenses.

Instructions

Analyze recent runs from the opt-in debug log (latency/tokens/reasoning-effort per model) plus the session store (verdict agreement rate), and return advisory tuning suggestions (disable a slow/redundant model in ask-all, lower an OpenRouter model's reasoning, adjust maxFanout). Two lenses reported side by side - timing and agreement are NOT joined (no shared run id). Requires debug.enabled for the timing lens. Local and read-only (no provider calls, writes nothing); returns a text-wrapped JSON envelope with the two lenses + suggestions. The /deliberation:analyze slash command renders this for humans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNoOnly analyze runs newer than this window, e.g. "30m", "24h", "7d", or a bare number of seconds. Gates BOTH lenses so timing and agreement cover the same period. Omit for all time. Max 10 years; an invalid or out-of-range value is an error, never a silent fallback.
sessionsNoHow many recent session records to read for the agreement lens. Default -1 (no caller cap), still bounded to 500 parsed records; truncation is reported in meta.truncated.sessions.
limitBytesNoTail size of the debug log to read, in bytes (default 1048576, or 33554432 when `since` is set). Clamped to 33554432.
configuredOnlyNoReport only models present in the current config (default true). Excluded rows and the reason each was dropped are listed in meta.excluded. Set false to include retired/unconfigured models.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv3.14.1
    • addedInput schema / properties / configuredOnly
      Added value: +{
+  "description": "Report only models present in the current config (default true). Excluded rows and the reason each was dropped are listed in meta.excluded. Set false to include retired/unconfigured models.",
+  "type": "boolean"
+}
    • changedInput schema / properties / limitBytes / description
      Previous value: -"Tail size of the debug log to read, in bytes (default 1048576)."New value: +"Tail size of the debug log to read, in bytes (default 1048576, or 33554432 when `since` is set). Clamped to 33554432."
    • changedInput schema / properties / sessions / description
      Previous value: -"How many recent session records to read for the agreement lens (default 50)."New value: +"How many recent session records to read for the agreement lens. Default -1 (no caller cap), still bounded to 500 parsed records; truncation is reported in meta.truncated.sessions."
    • addedInput schema / properties / since
      Added value: +{
+  "description": "Only analyze runs newer than this window, e.g. \"30m\", \"24h\", \"7d\", or a bare number of seconds. Gates BOTH lenses so timing and agreement cover the same period. Omit for all time. Max 10 years; an invalid or out-of-range value is an error, never a silent fallback.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare `readOnlyHint: true` and `destructiveHint: false`. The description goes far beyond this by explaining nuances: the opt-in nature of the log, the local execution ('no provider calls, writes nothing'), the two lenses not being joined, the requirement for `debug.enabled`, and the exact return format ('text-wrapped JSON envelope'). This is exemplary behavioral disclosure for a read-only analysis tool.

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 a single dense paragraph, which given the complexity of the tool (two lenses, two data sources, exclusions, return format) is justifiable and efficient. Every sentence carries meaningful information: purpose, caveats, requirements, execution model, return format, and human-friendly alternative. Front-loaded with the primary action, with critical caveats following naturally, then closing with the alternative rendering.

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?

For a complex analysis tool with 4 parameters, no output schema, and rich sibling context available, the description covers: the input sources, the analysis logic, the output format, the caveats (not joined), the requirement (debug.enabled), side effects (none), and the alternative. The overloading of parameters is documented in the schema, and the description ties it all together. There is no practical gap an agent would face when deciding to call this tool.

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% and each parameter already has rich descriptions. The description adds high-level context by explaining the two data sources and the 'two lenses' concept that maps to the parameters (`since` gates both lenses, `sessions` for agreement, `limitBytes` for tail size, `configuredOnly` for filtering). It doesn't fully explain every parameter's interaction (e.g., limitBytes default changes with `since`), but the schema handles that. A 4 is warranted because the high-level semantics add value on top of the schema.

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 starts with 'Analyze recent runs from the opt-in debug log... plus the session store' and clearly specifies the two data sources, the two lenses (timing and agreement), and the deliverable (advisory tuning suggestions). It explicitly notes the lenses are NOT joined, which distinguishes its analytical scope. The description also names a sibling renderer (`/deliberation:analyze`) and differentiates from its siblings by being local and read-only.

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 explicitly states when to use it ('Analyze recent runs from the opt-in debug log...') and includes critical caveats: 'timing and agreement are NOT joined (no shared run id)', 'Requires `debug.enabled` for the timing lens', and 'Local and read-only (no provider calls, writes nothing)'. It also names the alternative format for humans ('The `/deliberation:analyze` slash command renders this for humans'), which helps an agent decide between calling the tool directly versus delegating to the human-facing command. This replaces potentially harmful default assumptions.

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/antonbabenko/deliberation'

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