Skip to main content
Glama

Zernio

by com.zernio

Get daily aggregated metrics

analytics_get_daily_metrics
Read-only

Get daily aggregated metrics

Args:
    platform: Filter by platform (e.g. "instagram", "tiktok"). Omit for all platforms.
    profile_id: Filter by profile ID. Omit for all profiles.
    account_id: Filter by social account ID
    from_date: Inclusive start date (ISO 8601). Defaults to 180 days ago.
    to_date: Inclusive end date (ISO 8601). Defaults to now.
    source: Filter by post origin. "late" for posts published via Zernio, "external" for posts imported from platforms.
    attribution: How each post's engagement is attributed to a day.

"publish" (default) sums each post's lifetime total on its publish date. "received" buckets the per-day increase in engagement by the day it actually arrived (engagement-over-time), so engagement on older posts appears on the day it was gained rather than the post's publish date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNoall
to_dateNo
platformNo
from_dateNo
account_idNo
profile_idNo
attributionNopublish

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond the schema: inclusive ISO dates, the default 180-day lookback, source semantics ('late'/'external'), and the attribution difference between 'publish' and 'received'. It does not describe response shape, but an output schema exists.

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 opening sentence is a clear summary, and the parameter list is compact with each entry adding necessary context. The attribution explanation is longer, but the concept actually requires that level of detail. No filler or redundant restatement of the schema.

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 read-only tool with an output schema, the description fully covers the input parameters, their semantics, and defaults, so an agent can invoke it successfully. It is slightly incomplete on tool selection guidance because it does not say how this relates to analytics_get_analytics, which is a relevant sibling.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden. It explains every parameter, including default null-to-date behavior, filter omission meaning, source values, and attribution modes. This is strong compensation for a schema with zero descriptions.

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?

States a concrete action and resource: 'Get daily aggregated metrics'. The description also gives the main filter dimensions, so an agent can tell it is a metrics-aggregation tool. However, it does not explicitly distinguish itself from sibling analytics tools such as analytics_get_analytics or analytics_get_post_timeline.

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

Usage Guidelines3/5

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

The intended usage is implied by 'daily aggregated metrics' and by the parameter defaults and filter semantics, but there is no explicit statement about when to choose this tool over the other analytics siblings. It would benefit from saying 'use this for daily aggregate numbers; use analytics_get_analytics for X' or similar.

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

All Zernio toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation3/5

Many tools are clearly separated by domain prefix, but several overlap: posts_publish_now duplicates posts_create's publish_now mode, posts_edit_post vs posts_update is confusing without reading both descriptions, and analytics_get_analytics broadly overlaps the more specific analytics metrics tools. The descriptions do help disambiguate, but the large number of similar post/analytics helpers still creates selection risk.

Naming Consistency3/5

Most tools follow a readable lower_snake resource_verb format, with domains like accounts_, posts_, profiles_, and queue_. However, there is notable drift: redundant suffixes (queue_create_queue_slot, tracking_tags_get_tracking_tag_stats), singular/plural mismatch (account_groups_ vs accounts_), non-prefixed helpers (call_tool, search_tools, docs_search), and paired verbs that seem arbitrary (posts_edit_post vs posts_update). It is readable but not cleanly consistent.

Tool Count2/5

51 tools is far above the range where an agent can quickly select the right one, and many entries are wrappers or variants: publish_now, edit_post, retry_all_failed, and multiple analytics/queue helpers could be consolidated. The broad domain justifies more tools than a tiny server, but this count is excessive and will add navigation overhead.

Completeness4/5

The server covers the core social media management lifecycle well: profiles, accounts, posts, scheduling, queueing, analytics, comments, mentions, media uploads, tracking tags, and usage billing are all represented. There are minor gaps—tracking tags are read-only, there is no direct account connection/disconnection flow, and published-post deletion is unsupported—but agents can complete the main workflows with these tools.

Resources