Flowlines - MCP Analytics

Get product opportunities

get_opportunities

Read-onlyIdempotent

Analyze buying intent, product needs, and configured adoption signals. Explicit launch/export and workflow expansion requests belong in needs, including fulfilled requests. Adoption covers only inferred recurring_workflow and sustained_value usage. Use view/facet adoption and query.adoptionKind for its counts and evidence; adoption has no incidence rate and inferred usage is not buying intent. Needs and adoption have independent assessment statuses. Use overview for totals and coverage; buying for product/stage/strength/blocker/agent/use-case distributions; needs for stable groups ranked by known users then sessions; trends for daily counts/rates; sessions for matching evidence and turn/canonical MCP references. query.groupId retrieves a group and its drilldowns. Reuse the returned snapshot, start and end across views/pages; send nextCursor as query.cursor. The previous period has equal duration. Counts are exact distinct sessions and known users; recurringUsers counts known users with multiple matching sessions. Rates divide by successfully evaluated facet sessions before finding filters and require 20 evaluations. Unsupported/failed/skipped/pending/insufficient evidence are not evaluated-empty. Stages are distributions, never a conversion funnel; buckets can overlap. Pending needs remain visible; no emerging/growing labels. Prefer aggregate views before evidence sessions. Results may contain end-user personal data: quote minimally and mask direct identifiers.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`view`	No		overview
`query`	No
`reason`	Yes	A short phrase saying why you are calling this tool, for example: find unpaid invoices.
`user_intent`	Yes	One sentence describing what the user is trying to accomplish. Keep it the same across calls until the user's goal changes.
`namespace_id`	Yes	Flowlines namespace UUID.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`notice`	No
`truncation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantial operational context: exact count semantics, rate denominators and evaluation thresholds, overlap in stage buckets, pending needs visibility, and PII handling requirements. It also clarifies what is not evaluated-empty, which is important for interpreting results correctly.

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 dense but front-loads purpose and view routing before caveats, and most sentences carry useful semantic constraints. It could be more scannable with structure, but there is little empty filler for such a complex multi-view analytics 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?

Given the tool’s complexity, many nested parameters, and existing output schema, the description covers the critical context an agent needs: view selection, facet behavior, counts/rates interpretation, snapshot reuse, paging, privacy handling, and known analytical limitations. Annotations cover the safety profile, so no major behavioral gap remains.

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 moderate at 60%, and the description compensates by clarifying key parameter relationships: view/facet adoption, query.adoptionKind, query.groupId drilldowns, snapshot/start/end reuse, and query.cursor paging. It does not fully document every nested query parameter, but it adds meaningful semantics beyond what the schema alone provides.

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 analytical purpose: analyzing buying intent, product needs, and configured adoption signals. It clearly distinguishes the tool’s internal views and facets, which lets an agent separate buying, needs, adoption, trends, and evidence-session use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent among views and facets: overview for totals, buying for distributions, needs for ranked groups, trends for daily counts, and sessions for evidence. It also gives exclusion-style guidance such as preferring aggregate views before evidence sessions and using query.adoptionKind for adoption counts.

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

All Flowlines - MCP Analytics tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?