Skip to main content
Glama

FlowCastle

by ai.flowcastle

get_funnel_analytics

Read-only

Return the measured conversion funnel of the workspace's busiest entry flow over the last 30 days: how many new contacts entered, which blocks they reached, where most of them stop, which buttons lead nowhere (pressed then silence), and how many recorded a goal. Read-only, computed on demand from the execution log — the same numbers Pulse's recommendations are grounded in. The result carries the follow-up sequence playbook; read both before proposing any marketing/nurture sequence, and propose nothing when the funnel is healthy or too thin.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applicationIdNoApplication (workspace) id. Optional: an application-scoped key (app_...) defaults to its own application, but a personal key (usr_...) has no default and omitting it fails with MCP_APPLICATION_REQUIRED. Call list_applications to get the id.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces the read-only nature while adding context: the data is computed on demand from the execution log, serves as the basis for Pulse's recommendations, and the result carries the follow-up sequence playbook. This goes meaningfully beyond the annotations, though it stops short of describing failure modes or exact response structure.

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 description is front-loaded with the core purpose and metric breakdown, then provides context and usage guardrails. A few phrases like 'pressed then silence' add color but are still informative, and no sentence is wasted.

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?

For a tool with one optional parameter and no output schema, the description covers the source, the time window, the metrics returned, the bundled playbook, and the decision rule about when not to propose. A bit more precision about response shape would make it fully complete, but nothing essential for correct invocation is missing.

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?

There is only one optional parameter with 100% schema description coverage, so the schema fully documents the applicationId semantics. The description adds no additional parameter-level meaning, which is acceptable given the high schema coverage.

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: 'Return the measured conversion funnel of the workspace's busiest entry flow over the last 30 days.' It enumerates the exact metrics delivered and distinguishes itself from sibling analytics tools by focusing on the conversion funnel and its relationship to Pulse recommendations.

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?

Provides clear context: the tool should be read before proposing any marketing/nurture sequence, and the agent should propose nothing when the funnel is healthy or too thin. It does not explicitly contrast with alternatives like get_broadcast_analytics or get_workspace_summary, but the usage condition is unambiguous.

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

All FlowCastle toolsInspect
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.1/5.0
Disambiguation4/5

Each get_/list_ tool targets a distinct resource and the descriptions carefully separate similar pairs like get_application_context vs get_workspace_summary and get_broadcast_details vs get_broadcast_analytics. The main ambiguity is apply_actions vs validate_actions, since one runs the other's validation, but the descriptions make that relationship explicit.

Naming Consistency4/5

Names consistently follow verb_object snake_case and use familiar verbs like create, get, list, and update. Minor deviations such as read_messages instead of list_messages, apply_actions/validate_actions with plural nouns, and run_flow_autotest are still predictable and readable.

Tool Count2/5

33 tools exceeds the 25-tool threshold and makes the surface feel heavy, even though the domain is broad. Many of the read-only getters are individually useful but could be consolidated, such as merging module catalog/details or workspace/application context.

Completeness4/5

Core workflows are covered: application lifecycle, flow editing through apply_actions, deployment, contacts, broadcasts, modules, and message/event reads. Minor gaps exist, such as no dedicated delete for contacts, applications, or broadcasts, and no rollback for deployments, but agents can work around or avoid these.

Resources