buffer_list_daily_limitsReturns each channel's daily posting limit, scheduled and sent counts, and whether the limit is reached. Use it to avoid exceeding Buffer daily caps.
Return each channel's daily posting limit, how many posts are scheduled and sent, and whether the limit is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date. Defaults to now. | |
| channelIds | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating what is returned (limit, scheduled count, sent count, limit-reached flag), but says nothing about permission requirements, per-channel failure behavior, or whether channelIds are validated.
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?
A single sentence that leads with the primary return value and enumerates the remaining fields in a natural order. No filler, no redundancy with the title.
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?
With no output schema, the description carries the return-value burden and does so by listing the four returned fields. It leaves minor gaps around the meaning of 'scheduled vs sent' counting and the default-date semantics, but an agent has enough to call it correctly.
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?
Schema description coverage is 50%: the optional 'date' parameter is documented as an ISO 8601 date defaulting to now, while the required 'channelIds' array has no schema description. The description's phrase 'each channel's' only loosely implies channelIds, so it does not compensate for the undocumented required parameter, but the partially-documented schema keeps this at the baseline.
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?
States a specific verb ('Return') and a precisely scoped resource ('each channel's daily posting limit') plus the derived fields (scheduled/sent counts, whether the limit is reached). This is unmistakably distinct from siblings like buffer_list_posts or buffer_get_channel, which return content rather than quota state.
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?
The purpose implies the use case (checking quota before scheduling), but there is no explicit when-to-use statement, no prerequisite, and no mention of alternatives such as buffer_get_channel or buffer_list_channels. Usage must be inferred from the description's content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.