Coderbuds

Get signup funnel

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

Name	Required	Description	Default
`days`	No	How 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_limit`	No	How 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

Name	Required	Description
`window`	Yes	The window in words.
`front_door`	Yes	Provider 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_days`	Yes	The window applied, in days. 0 means since launch.
`signup_conversion`	Yes	Activation 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.

First observedSep 11, 2026

TDQS

A4.6/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 still adds substantial context beyond them: unreliable rates over tiny samples are flagged, three milestones lack medians because nothing records their timing, and the per-account list is capped while rates cover the whole cohort. It also ties results to a specific dashboard for verification.

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?

Access restriction and the one-line summary are front-loaded, then two labeled bullets organize the funnel stages, and caveats close it. It is long, and the closing caveat paragraph restates some of what the journey_limit schema already says, but the density is warranted by a two-funnel, multi-metric tool.

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, yet the description still tells the agent what categories of results to expect (milestone shares, medians, blockers, trial splits, per-account journeys) and how to read them. For a complex analytics tool this leaves nothing an agent needs 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?

Schema coverage is 100% and both parameters are well documented there, so the baseline is 3. The description still adds rationale — why 365 is the default (shorter windows yield only two or three signups and degenerate rates) and that journey_limit bounds only the list, not the rates — which strengthens the choice of values.

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 and resource (get the signup and conversion funnel) and enumerates the two funnel stages, front door and activation, with the exact metrics each covers. No sibling tool covers signup/conversion funnel data, and the description makes that scope boundary unambiguous.

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?

Gives concrete question-shaped guidance ('why signups stall', 'which step loses the most people', 'whether a change to onboarding moved anything', 'who is worth an email this week') and an explicit audience restriction ('Internal Coderbuds staff only'). It never names an alternative tool for narrower questions, but no sibling overlaps this scope, so the omission costs little.

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

All Coderbuds tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?