SupaBird

Get Daily Performance Report

get_daily_performance_report

Read-onlyIdempotent

Fetch a daily X performance report from your SupaBird DailyStats history (markdown: tables, tweet cards, images when available).

When to call:

Omit local_date for the most recent completed day (yesterday in your Analytics timezone).
Pass local_date as YYYY-MM-DD for a specific calendar day.

IMPORTANT: After the tool returns, show the response verbatim to the user (full markdown). Do not rewrite it as a short prose summary—users need tables, tweet cards, and image previews.

If SupaBird has no stats for that day, the tool returns a clear message (coverage starts March 4, 2026, or no row for that date).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_daily_performance_report"
  }
}

Input Schema

Name	Required	Description	Default
`local_date`	No	Calendar date in your Analytics timezone (YYYY-MM-DD). Omit to default to yesterday.
`social_set`	No	The social set (brand) this is for: its name, id or one of its handles. Omit when the user has one set.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the response format, the empty-state behavior and the start of coverage on March 4, 2026, and the requirement to show the response verbatim. These are behavioral traits an agent could not infer from the schema or annotations alone.

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?

The content is front-loaded and organized under clear headings, with no redundant sentences. The bold emphasis and repeated format cues are slightly heavy but still serve the instruction, so it earns a 4 rather than a 5.

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 two-parameter reporting tool without an output schema, the description covers return format, default behavior, and empty results. It does not explain how to choose social_set when a user has multiple sets, which is a minor gap for an otherwise complete definition.

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?

The schema description coverage is 100%, so the schema already documents both local_date and social_set. The description reinforces that local_date defaults to yesterday in the Analytics timezone, but adds no new syntax or constraint details, so the baseline of 3 is appropriate.

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

Purpose4/5

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

The description uses a specific verb and resource: 'Fetch a daily X performance report from your SupaBird DailyStats history,' and it names the output format (markdown tables, tweet cards, images). This lets an agent distinguish it from analytics siblings. It does not explicitly differentiate from related siblings such as get_overview_analytics, so it stops short of a 5.

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?

A dedicated 'When to call' block gives explicit conditions: omit local_date for yesterday, pass YYYY-MM-DD for a specific day. That is clear guidance for both parameters. It does not name alternatives or when-not-to-use cases, which keeps it from a 5.

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

All SupaBird tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?