dForms

Get form analytics

get_form_analytics

Read-onlyIdempotent

The funnel of one form, computed by dForms exactly as its Results screen shows it: views, starts, submissions, completion rate, median time to complete, partials, bookings and the drop-off per question, each with its definition. These are the figures to report: no other rate is derived here, and null means no data, not zero. A question is named as written, so a [placeholder] in it stays as is: it counts every respondent, whose own values differ.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "form_id": "<form_id>"
    },
    "name": "get_form_analytics"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day, inclusive (YYYY-MM-DD, in time_zone) or epoch ms.
`from`	No	First day (YYYY-MM-DD, in time_zone) or epoch ms. Omit for all time.
`form_id`	Yes	The form id, from list_forms or get_form.
`time_zone`	No	IANA zone the days are counted in, e.g. America/Bogota. Default: the workspace zone. An unknown zone is refused.
`workspace_id`	No	The workspace this call acts in: an id from list_my_workspaces. Required for a person signed in with several workspaces and for staff of this deployment; optional with an API key or with only one workspace.
`include_daily`	No	Also return one point per day: at most the most recent 366 days of the range (daily_truncated says when it was cut).

Output Schema

Name	Required	Description
`daily`	No
`range`	Yes
`window`	Yes
`dropoff`	Yes
`form_id`	Yes
`metrics`	Yes
`warnings`	No	What did not go exactly as sent, or what the user needs to know.
`workspace`	Yes	The workspace this call acted in, to compare with the one the user means.
`definitions`	Yes
`daily_truncated`	No	With include_daily: true when daily is at its 366-day cap and the range may hold earlier days (always for a range longer than 366 days). Narrow from and to to read them.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety needs no restating. The description instead adds genuinely non-structured semantics: null means no data rather than zero, rates are not re-derived here, and question labels preserve any [placeholder] while still counting every respondent. These are exactly the interpretive details an agent would otherwise get wrong, though pagination/truncation behavior is only implied by the schema.

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 metric list is front-loaded in the first sentence, followed by two short caveat sentences, with no marketing filler. The closing clause ('it counts every respondent, whose own values differ') is cryptic enough to require a re-read, which costs a little clarity against an otherwise efficient structure.

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?

With an output schema present, enumerating returned metrics is partly redundant, but the description's real contribution is interpretive: null-vs-zero semantics and label fidelity. All six parameters are schema-documented, so nothing essential is missing for a correct call. It could still mention that the window is bounded or how the daily points interact with the requested range.

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 every parameter (form_id, from, to, time_zone, workspace_id, include_daily) is already documented with format, defaults, and constraints in the schema. The description adds no parameter-level meaning such as date-range conventions or how the time zone affects the returned daily points. Baseline 3 applies when the schema carries this load.

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 names a specific resource and scope ('the funnel of one form') and enumerates the exact metrics returned: views, starts, submissions, completion rate, median time to complete, partials, bookings, and per-question drop-off. That is far more specific than the title alone and lets an agent tell it apart from raw-response tools. It stops short of naming a sibling (e.g. get_form_summary or get_response_facets) as the alternative, so it earns 4 rather than 5.

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?

There is a directive on output authority ('These are the figures to report: no other rate is derived here'), which implies this is the tool to reach for when reporting funnel numbers. However, there is no explicit when-to-use versus when-not-to-use guidance and no named alternative for related tasks such as per-response breakdowns. Usage is inferable but not instructed.

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

All dForms tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?