Skip to main content
Glama
@mitr-analytics/mcp

@mitr-analytics/mcp

by shiv9thakur

Get funnel conversion results

get_funnel_results
Read-only

Compute conversion results for one funnel over a date range, including entered and converted counts, conversion rate, and step drop-off. Defaults to the last 30 days.

Instructions

Compute conversion results for one funnel over a date range: entered/converted counts, conversion rate, and drop-off at each step. Defaults to the last 30 days.

Input Schema

NameRequiredDescriptionDefault
endNoISO 8601 end of the range (default: now).
startNoISO 8601 start of the range (default: 30 days ago).
funnelIdYesThe funnel's id, from list_funnels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds the result shape (entered/converted counts, conversion rate, drop-off per step), but its other claim, the 30-day default, restates the schema's own defaults, so incremental behavioral value is modest.

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, zero filler, with the core purpose and output shape front-loaded before the default-window note. Nothing could be removed without losing information.

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?

There is no output schema, and the description usefully enumerates the returned metrics and the default time window. What's missing is any note on ordering or shape of the per-step drop-off data across an arbitrary number of funnel steps, which matters for a variable-length result.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters including formats and defaults are already documented in the schema, which sets the baseline at 3. The description's 'over a date range' and 'last 30 days' add nothing the start/end descriptions don't already say.

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 opens with a specific verb and resource ('Compute conversion results for one funnel') and enumerates the returned metrics, so an agent knows exactly what it gets. It doesn't name or contrast with siblings like get_app_report or get_workspace_overview, so the differentiation comes from the schema's funnelId reference to list_funnels rather than the description itself.

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?

Usage is only implied: 'for one funnel' plus the default 30-day window signal a single-funnel analytics read. There is no explicit statement of when to prefer this over other reporting tools, nor any prerequisite or exclusion (e.g., funnel must already be created via create_funnel).

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