Skip to main content
Glama

Get Signup Funnel Tool

get-signup-funnel-tool
Read-onlyIdempotent

Internal Coderbuds staff only. The whole signup and conversion funnel across every account, matching the /admin/activity/conversion dashboard.

Two funnels joined at "an account exists":

  • Front door — visitors sent to GitHub or BitBucket to authorize, how many came back, how many became an account, and how many were lost on the provider's own authorize screen. Broken down by provider and by campaign source. This is the only stage the account funnel structurally cannot see.

  • Activation — for accounts created in the window: what share reached each milestone (repository, GitHub App, first PR, first review, deploy tracking, deploy observed, Slack, MCP, paid) and the median days to get there; where open trials are stuck, counted by next step; the trial-state split; trials lapsing within a week; and per-account journeys with owner, milestone dates, next step and trial state.

Use it to ask why signups stall, which step loses the most people, whether a change to onboarding moved anything, or who is worth an email this week. Read the caveats it returns: rates over a tiny sample are flagged unreliable, three milestones are reported without a median because nothing records when they happened, and the per-account list is capped while every rate beside it is over the whole cohort.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far back the cohort reaches. 0 means every account since launch. Defaults to 365 — shorter windows are two or three signups and every rate reads 0%, 50% or 100%.
journey_limitNoHow many individual account journeys to list, newest first. Defaults to 50, capped at 200, and 0 omits the list entirely. Bounds only that list: every rate, blocker and median is over the whole cohort regardless.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
windowYesThe window in words.
front_doorYesProvider authorize step: attempts (sent to the provider), returned, registered (became an account), authenticated (came back as an existing user), abandoned (never returned — the authorize screen was declined or closed), failed; return_rate and new_account_rate; rates_are_reliable, false when there are too few attempts to divide by; by_provider; by_source with campaign source, direct traffic named.
window_daysYesThe window applied, in days. 0 means since launch.
signup_conversionYesActivation funnel: cohort_size and cohort_definition; stages, each with count, rate, not_reached and median_days (null where nothing records when the milestone happened — deploy tracking, GitHub App, Slack); blockers, open accounts grouped by next step and split on-trial versus trial-expired; trial_states; expiring_soon, trials lapsing within a week, soonest first; recent_teams, per-account journeys with owner, milestone timestamps, next step, trial state and where an owner went if they now work in another team.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, yet the description adds substantial behavior beyond them: the staff-only access constraint, three milestones reported without medians, unreliable rates flagged on tiny samples, and a capped per-account list whose surrounding rates still span the whole cohort. These are exactly the caveats an agent needs.

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?

The access restriction is front-loaded and the two funnels are cleanly segmented with bullets. It is a dense paragraph of its length but nearly every clause earns its place by describing a distinct output or caveat; still, some prose could be trimmed without loss.

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 already exists, so return values need not be explained; the description instead supplies the interpretive context (funnel stages, cohort window semantics, unreliable-rate caveats) an agent needs to use the results correctly. Nothing material is missing for a two-parameter read-only analytics tool.

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% and both parameters carry good inline docs, so the baseline is 3. The description reinforces the journey_limit cap ('the per-account list is capped while every rate beside it is over the whole cohort') but adds no syntax or format detail beyond the schema.

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 description states a specific verb and resource (signup and conversion funnel across every account) and differentiates itself from all siblings, which cover DORA, PRs, adoption, deployments, etc. It even distinguishes itself internally from the account funnel it builds on ('This is the only stage the account funnel structurally cannot see').

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 gives explicit intended questions ('why signups stall, which step loses the most people, whether a change to onboarding moved anything, who is worth an email') and an access restriction (staff only), so the agent knows when to reach for it. However, it names no alternative sibling to use instead in adjacent cases, so it stops short of full when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources