Skip to main content
Glama
Sign In

fivebar

by ar.fiveb
OverviewDiscussionsAdmin

Site speed

get_site_speed
Read-onlyIdempotent

How fast a site's pages were over a range, as its Speed page's tiles show, beside the period before. The answer's caveats are the rules that apply to its figures, such as each p75 being approximate, or some figures being counted only from a later day: 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. metrics gives each of TTFB, FCP, LCP, INP, CLS and PLT: p75, the 75th percentile of the page loads that measured it, in milliseconds, or a score for CLS; rating, good at or under good_up_to, poor over poor_over, needs_improvement between (Google's thresholds, fivebar's own for PLT); ratings, the part of the loads in each, fractions of 1; page_loads_measured, as not every browser measures every metric and INP needs an interaction; by_device; for CLS, no_shift_share; previous; and change, how far p75 moved as a whole percentage, a fall being faster, or for CLS steadier. server_timing, only where the site's server sends a Server-Timing header, is up to ten of its own entries by name, each with p75 in milliseconds, measured (the page loads and server events' calls that reported it), previous and change, and no rating; a share is out of page_loads plus server_timing_calls. page_loads is every page load counted, and statuses the HTTP statuses they were answered with. Speed is counted by page, so a goal, entry or exit filter rules it 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.6/5.0
Behavior5/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, yet the description adds substantial behavioral context: p75 figures are approximate, some are counted only from a later day, server_timing appears only when the server sends a Server-Timing header (max ten entries), shares are computed over page_loads plus server_timing_calls, and incompatible filters produce a graceful available:false response.

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?

Every sentence carries information and the purpose is front-loaded; since there is no output schema, the metric-by-metric enumeration earns its space. The prose is a single dense block with semicolon-chained clauses ('ratings, the part of the loads in each, fractions of 1') that make scanning harder than necessary.

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 carries the full return-shape burden and does so thoroughly: per-metric fields, previous-period comparison, change direction conventions (a fall is faster; steadier for CLS), device breakdown, and CLS's no_shift_share. The filter-failure path is also documented, leaving nothing an agent needs to call it correctly.

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 baseline is 3, but the description adds real constraint knowledge: goal/entry/exit filters are invalid for this tool, and range/filters semantics are delegated to get_site_summary for consistency. The remaining parameters (from, to, days, ending, domain) are left entirely to the schema, so it is not a 5.

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

Purpose5/5

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

The opening sentence gives a specific resource (a site's page-speed figures, per Speed-page tiles) and scope (over a range, compared against the preceding period), which no sibling tool covers. It then enumerates exactly what comes back (TTFB, FCP, LCP, INP, CLS, PLT with p75, ratings, page_loads, server_timing), so an agent can tell it apart from get_site_summary or get_site_breakdown immediately.

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 routes the agent to get_site_summary for naming the site, range and filters, and gives a clear when-not rule: goal, entry or exit filters rule out speed, returning available: false with why and what to try. It also instructs reading the caveats before reporting figures. It stops short of naming an alternative for page-level-only analysis, so 4 rather than 5.

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