7IT Solutions

US Store Speed Index (weekly)

get_store_speed_index

Read-onlyIdempotent

Use this when someone asks how fast US online stores are right now, or wants a current benchmark to compare a store against. Returns 7IT's weekly US Store Speed Index: median Google phone score, time to main content, share of stores scoring 50 or more, and median apps per store for a fixed panel of 100 US online stores, week by week, with the source link. Medians only; no store is named.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`panel`	Yes	Number of stores in the fixed panel
`title`	Yes
`series`	Yes	One entry per week, oldest first
`updated`	Yes	Date of the latest weekly reading, YYYY-MM-DD
`source_url`	Yes	Page to cite

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "panel": {
+      "description": "Number of stores in the fixed panel",
+      "type": "number"
+    },
+    "series": {
+      "description": "One entry per week, oldest first",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "date": {
+            "type": "string"
+          },
+          "median_apps": {
+            "description": "Median third-party apps and tags per store",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "median_lcp_s": {
+            "description": "Median seconds until the main content shows",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "median_score": {
+            "description": "Median Google phone performance score, 0 to 100",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "score_50_plus": {
+            "description": "Percent of stores scoring 50 or more",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "stores": {
+            "description": "Stores measured that week",
+            "type": "number"
+          }
+        },
+        "required": [
+          "date",
+          "stores",
+          "median_score",
+          "median_lcp_s",
+          "score_50_plus",
+          "median_apps"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source_url": {
+      "description": "Page to cite",
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "updated": {
+      "description": "Date of the latest weekly reading, YYYY-MM-DD",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "title",
+    "panel",
+    "updated",
+    "series",
+    "source_url"
+  ],
+  "type": "object"
+}

AddedOct 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely new behavioral context: it is a fixed panel of 100 stores, week-by-week, medians only with no store named, and the response includes a source link — all constraints an agent would otherwise have to guess.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the trigger condition, then the payload. Every clause carries information (metrics list, panel definition, aggregation caveat); nothing is redundant padding.

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?

An output schema exists so return-value structure needn't be described, and the description still covers scope, panel, granularity, aggregation level, and provenance. Nothing an agent needs to call it correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering or scoping input is needed.

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?

States a specific verb+resource ('Returns 7IT's weekly US Store Speed Index') and enumerates the exact metrics returned, so an agent can distinguish it from test_store_speed, which presumably tests one store rather than reporting an aggregate panel.

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?

Opens with an explicit trigger: 'Use this when someone asks how fast US online stores are right now, or wants a current benchmark to compare a store against.' Clear context, but it never names test_store_speed as the alternative for a single-store measurement, leaving the sibling routing to inference.

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

All 7IT Solutions tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?