Skip to main content
Glama
LibreDesk MCP

LibreDesk MCP

by Passe12345

overview_tag_distribution

Retrieves tag distribution statistics from support reports for a chosen number of past days. Use it to see how conversations are spread across tags over time.

Instructions

Get Overview Tag Distribution Requires the reports:manage permission. GET /api/v1/reports/overview/tags Tags: Reports

Input Schema

NameRequiredDescriptionDefault
daysNoNumber of past days to include. 0 means today only. Values outside 0-365 are clamped. (query parameter)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden. It does disclose the required permission scope and that this is a GET read against /api/v1/reports/overview/tags, which is real behavioral context the schema cannot convey. It says nothing about rate limits, response shape, or whether results are aggregated across the whole workspace.

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

Conciseness3/5

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

It is short and front-loads the tool identity, but two of the four lines (the raw endpoint path and the 'Tags: Reports' label) are administrative noise for an agent, while the one sentence that would matter — what the report returns — is absent.

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

Completeness2/5

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

For a reporting tool with no output schema and no annotations, the description needs to describe the returned data and its aggregation semantics. It instead provides only permission and endpoint metadata, leaving the agent unable to predict the response.

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?

There is a single optional parameter (`days`) and the schema already documents it at 100% coverage, including default, 0-365 clamping, and query-parameter placement. The description adds no extra meaning, so the baseline of 3 applies.

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

Purpose3/5

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

The description restates the name ('Get Overview Tag Distribution') and adds only the endpoint path. It signals a reporting read but never defines what 'distribution' means (tag counts? per-conversation tags? over time?), and it does nothing to separate it from the sibling overview_counts, overview_charts, or overview_csat tools.

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

Usage Guidelines2/5

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

The only precondition given is the `reports:manage` permission, which is genuinely useful. There is no guidance on when an agent should pick this overview report over the other overview_* siblings, and no exclusions or alternative routing.

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