Staats

Conversion funnel

funnel

Read-only

Ordered conversion funnel across up to 5 steps within the period. Each step is a pageview path ({kind:'path', value:'/pricing'}) or a custom event ({kind:'event', value:'signup'}); a visitor counts for step N only after completing step N-1. Visitor identity rotates daily for privacy, so journeys spanning multiple days undercount (strongest for same-visit conversion). If site context has a stored funnel, run those steps when asked how the site is doing and compare against the previous period.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	ISO end, alternative to period
`from`	No	ISO start, alternative to period
`site`	No	the site's data-site code, from its script tag or list_sites. Omit when the account has a single site. In a tracked project, read the code from the script tag before asking the user.
`steps`	Yes	ordered funnel steps, each a pageview path or a custom event name
`period`	No	relative period like '24h', '7d' (default), '4w'

Output Schema

TableJSON Schema

Name	Required	Description	Default
`site`	Yes
`funnel`	Yes
`period`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by explaining the visitor-count rule (step N requires step N-1), the daily identity rotation causing undercounting, and the stored-funnel fallback behavior. These are non-obvious behaviors an agent must know for correct interpretation.

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?

The description is three dense sentences with no wasted words. It front-loads the core definition, then delivers the counting caveat, then the usage instruction. Every sentence earns its place.

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 the output schema present, all parameters documented in the schema, and annotations declaring read-only behavior, the description's added caveats and usage context make it complete. An agent has enough to choose, invoke, and interpret this tool 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. The description adds meaningful semantics by illustrating the exact step object structure for both paths and events, and by referencing the site context's stored funnel. This elevates it above baseline.

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 clearly defines the tool as an ordered conversion funnel across up to 5 steps and specifies the step format (path or event) and counting rule. It stops short of naming sibling tools or using an explicit verb like 'compute' or 'return', and does not explicitly distinguish itself from siblings like 'journeys'.

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 provides a clear usage directive: if a stored funnel exists in site context, run those steps when asked how the site is doing and compare against the previous period. It also warns about the undercounting caveat for multi-day journeys, but it does not state explicit exclusions or alternative tools for different scenarios.

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

All Staats tools Inspect

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

A4/5.0

Disambiguation5/5

Each tool maps to a distinct resource or action: site management, site context, annotations, overviews, dimensional queries, funnels, journeys, and anomaly checks. Overlapping pairs like funnel/journeys are explicitly disambiguated in the descriptions, and what_broke vs what_changed cleanly separate problems from notable movements.

Naming Consistency3/5

Most tools follow a clear verb_noun pattern such as create_site, list_annotations, and update_site_context, but funnel, journeys, portfolio_overview, what_broke, and what_changed break that pattern. The names are still readable and somewhat grouped by intent, but the mixed conventions make it harder to predict a tool's role from its name alone.

Tool Count5/5

At 15 tools this sits at the upper edge of the ideal range, and each tool earns its place: site lifecycle, context, annotation timeline, core analytics, discovery reports, and post-deploy checks are all covered. There is no obvious redundancy or filler.

Completeness4/5

The set covers site management, context editing, annotations, overview/query/funnel/journeys/portfolio analytics, and what_broke/what_changed checks, so most workflows have no dead ends. Minor gaps exist, such as no way to edit or delete a mistaken annotation and no explicit tool for updating data-retention settings, but these are workaroundable rather than blocking.

Resources

Need Help?