Skip to main content
Glama
Sign In

fivebar

by ar.fiveb
OverviewDiscussionsAdmin

Site hours

get_site_hours
Read-onlyIdempotent

When a site's traffic comes, by the hour of the day and the day of the week in its own time zone, over a range. The answer's caveats are the rules that apply to its figures, such as visitors being visitor-days or today being partial: read them before reporting any figure, and pass on those that change what it means. Name the site, range and filters as for get_site_summary, which refuses the same things. hours gives each hour, 00 to 23, its pageviews, visits and visitors summed over the range's days, and share, its part of the pageviews counted by the hour, a fraction of 1. weekdays gives each day of the week, Monday first, its counts and days, how many of it the range holds. A range of one or two days adds series, each hour in turn up to the current one. totals are the range's counts, counted_by_hour what the hours add up to, and coverage its part of totals. The hours are counted by page, so a goal, entry or exit filter rules them out, answered with available: false, why and what to try.

Input Schema

NameRequiredDescriptionDefault
toNoWith from: the last day, as YYYY-MM-DD, not after today.
daysNoThe last this many days, ending today unless ending says yesterday.
fromNoWith to: the first day, as YYYY-MM-DD.
rangeNoA preset, as get_site_summary's range says what each covers.
domainYesA domain from list_sites, or any public site's.
endingNoWith days: the last day, today by default.
filtersNoEach narrows every figure to what has exactly that value, case and all, so google is not Google; all must hold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / range / enum
      Previous value: -[
-  "today",
-  "yesterday",
-  "this-week",
-  "this-week-sun",
-  "last-7-days",
-  "last-week",
-  "last-week-sun",
-  "last-14-days",
-  "this-month",
-  "last-30-days",
-  "last-month",
-  "all-time"
-]New value: +[
+  "today",
+  "yesterday",
+  "this-week",
+  "this-week-fri",
+  "this-week-sat",
+  "this-week-sun",
+  "last-7-days",
+  "last-week",
+  "last-week-fri",
+  "last-week-sat",
+  "last-week-sun",
+  "last-14-days",
+  "this-month",
+  "last-30-days",
+  "last-month",
+  "all-time"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: figures are computed in the site's own time zone, a caveats collection qualifies the answer, and unsupported filters return available: false with why and what to try. That failure-mode disclosure is exactly what an agent needs before invoking and reporting.

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?

The purpose is front-loaded, but the body is a dense run of long clauses covering output fields and edge cases in one block, with little structural separation. Since no output schema exists the return-value content earns its place, yet it could be broken up or trimmed of repeated framing without losing information.

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?

With no output schema, the description takes on the full burden of describing return values and does so thoroughly: hours (00–23 with pageviews, visits, visitors, share), weekdays (Monday first, with day counts), series for short ranges, totals, counted_by_hour and coverage. Combined with failure-mode and time-zone notes, nothing essential is missing for correct invocation.

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 coverage is 100%, so the schema carries date, range, domain and filter documentation. The description nonetheless adds meaning the schema lacks, notably that hours are counted by page so goal/entry/exit filter dimensions will be refused despite appearing in the enum, and it defers remaining parameter semantics to get_site_summary for consistency.

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?

"When a site's traffic comes, by the hour of the day and the day of the week in its own time zone, over a range" states the specific resource (hourly/weekday traffic distribution) and its time-zone scoping, which distinguishes it from get_site_summary or get_site_breakdown. The phrasing is oblique (no direct verb like "get" or "report"), and no sibling is named as the contrasting alternative, but an agent can identify the resource unambiguously.

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?

It explicitly tells the agent to read the caveats before reporting figures and to pass on those that change meaning, and it defines an exclusion: goal, entry and exit filters are ruled out and answered with available: false. It does not say when to prefer this over get_site_breakdown or get_site_summary, so the selection guidance is contextual rather than comparative.

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

All fivebar toolsInspect
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