FastMCP Agent Tools Reference

toorow mounts a single governed MCP surface on the microkernel server (server/core/main.py). Every tool is declared: its profile, whether it reads or writes, and what it may touch are part of the declaration, not of the code that answers the call.

This page describes the surface and documents the tools you will reach first. It is not a listing of all 147 tools: the tool catalog a host receives at tools/list is generated from the server itself, and that catalog is the reference which cannot fall behind. Every tool named on this page is checked against the server registry by a conformance test.

1. Three profiles, one surface

A host does not see all 147 tools. It sees the profiles its session is entitled to, and nothing else.

Profile	Tools	What it may do	Reached when
`insights`	60	Reads only. Never mutates.	Always — this is the floor, with no token and no proof of workspace
`operations`	47	Runs, drafts, schedules, compositions	The session proves an endpoint and a workspace
`governance`	40	Publishes definitions, capabilities and master data	The session proves an endpoint, a workspace, and verified interactive presence

A tool that writes cannot be declared insights — the server refuses to assemble a surface where one is. 52 tools are declared confirmed write: each is refused before it runs unless a person is verifiably present at the host. Some of those additionally consume a single-use confirmation issued by a preceding prepare_* call, so the act and its authorisation cannot be the same request.

2. Reading what the platform already holds

`get_daily_report`

Canonical daily marketing metrics for a project, across every active connector.

get_daily_report(
    project_id: str = "default",
    date_range: dict | None = None,
    connectors: list[str] | None = None,
    as_of: str | None = None
) -> dict

The answer carries its own provenance: the pull that produced each row, the moment it landed, and the freshness of the data behind it. An agent that quotes a number from this tool can always say where the number came from.

`get_report`

Runs a saved report definition and returns its rows.

get_report(project_id: str, report_id: str, date_from: str = "", date_to: str = "") -> dict

list_reports, get_report_versions and run_report_version cover the rest of the report lifecycle. A report version names the query intent and the default presentation; running it produces a new immutable Result.

`get_data_quality_report`

The state of the ten data-quality monitors for a project, or for one connector.

get_data_quality_report(project_id: str = "default", connector: str | None = None) -> dict

See Data Quality for what each monitor watches and what its findings mean.

`get_source_capabilities`

What one connected source can actually deliver: fields, supported grains, filter bounds.

get_source_capabilities(project_id: str, connection_ref_id: str) -> dict

3. Asking a new question: the analytical path

toorow has one governed analytical path, and these tools are its steps. Query intent becomes an immutable Result; a Result may become a Render; Renders may be composed into a Dossier; a Dossier version or a single Render may be handed out through a revocable Share. See Renders, Dossiers and Sharing.

`explore_analyze_query`

States a question against a Semantic View — governed measures, governed dimensions, a grain and a window — and executes it.

explore_analyze_query(
    project_id: str,
    semantic_view_id: str,
    semantic_view_version_id: str,
    measures: list[str],
    dimensions: list[str],
    time_grain: str = "",
    last_n_days: int = 0,
    name: str = ""
) -> dict

discover_analyze_matches and list_analyze_facets are the read-only tools that let an agent find which Semantic View and which governed names to ask for, before it asks.

`execute_analyze_query_spec`

Re-executes an existing Query Spec version. Same question, new data.

execute_analyze_query_spec(project_id: str, query_spec_version_id: str) -> dict

`analyze_result`

Opens an existing Result — its data, its definitions, its quality, its provenance, its freshness, and its reasoning path (or an explicit No AI path).

analyze_result(project_id: str, result_id: str) -> dict

`render_analyze_result`

Turns a Result into a presentation, either from a saved Visualization Spec version or from a Chart Template version.

render_analyze_result(
    project_id: str,
    result_id: str,
    visualization_spec_version_id: str | None = None,
    visualization_template_version_id: str | None = None
) -> dict

`compose_dossier`

Keeps what the model drew and wrote. Each figure is frozen server-side into an immutable Render, and the narrative blocks are stamped with their author — the model, or a person — in the same transaction as the Dossier version.

compose_dossier(
    project_id: str,
    label: str,
    blocks: list[dict],
    description: str = "",
    dossier_id: str = ""
) -> dict

A block referencing a figure from another project fails the whole call: no partial Dossier is ever written.

4. Governed flows and configuration

`flows_list`

Lists datastreams and report configurations for a project.

flows_list(project_id: str, kind: str | None = None) -> dict

`flows_get`

Retrieves one datastream or report definition.

flows_get(project_id: str, kind: str, id: str) -> dict

`flows_upsert`

Creates or updates a datastream configuration. flows_validate checks a definition without writing it.

flows_upsert(project_id: str, definition: dict) -> dict

5. Connectors: installed, verified, activated

There is no per-connector tool. A connector is not a tool surface — it is a source the platform knows how to pull. Three read tools answer the three questions a host actually asks, and list_connectors enumerates the catalog.

`get_connector_installation_status`

Is this connector present in the running server?

get_connector_installation_status(connector_name: str) -> dict

`get_connector_verification_status`

Has this connector been proved against a real account?

get_connector_verification_status(connector_name: str) -> dict

`get_connector_activation_status`

Is this connector connected and pulling for this organization?

get_connector_activation_status(connector_name: str, org_id: str) -> dict

6. Context, insights and feedback

`get_context_hub`

The registered context of a project: what happened, when, and who recorded it. add_context_event records one. correct_context_event appends a correction and preserves the original wording — a correction never overwrites. withdraw_context_event withdraws one, auditably, and a withdrawal is not undone. search_context and get_context_adherence read.

`preview_daily_insight` / `publish_daily_insights`

Composes the daily narrative, then publishes it.

preview_daily_insight(project_id: str, payload: dict) -> dict
publish_daily_insights(
    project_id: str,
    insight_date: str,
    items: list[dict] | None = None,
    status: str = ""
) -> dict

get_daily_insight_readiness says whether there is anything to publish, and retract_daily_insight withdraws a published one as an audited transition — never as a deletion.

`submit_feedback`

Records a rating and commentary against a trace, a report or a connector.

submit_feedback(
    project_id: str,
    rating: int,           # 1 or -1
    trace_id: str | None = None,
    comment: str = "",
    report_ref: str = "",
    connector: str = "",
    handle: str = ""
) -> dict

submit_analyze_feedback is the equivalent on the analytical path: it attaches the rating to the exact observation the reader was looking at.

Next Steps & Cross-References

Renders, Dossiers and Sharing

How an answer becomes a frozen figure, a document, and a revocable link.

Agent Rules

Review system instructions and constraints for tool execution.

MCP App Use Cases

Explore interactive MCP App UI widgets powered by tool outputs.

Host Integration

Connect Claude, ChatGPT or another MCP host to your workspace.

Product Overview

Core Features & Analytics

AI Agents & MCP Protocol

API Reference

FastMCP Agent Tools Reference

1. Three profiles, one surface

2. Reading what the platform already holds

`get_daily_report`

`get_report`

`get_data_quality_report`

`get_source_capabilities`

3. Asking a new question: the analytical path

`explore_analyze_query`

`execute_analyze_query_spec`

`analyze_result`

`render_analyze_result`

`compose_dossier`

4. Governed flows and configuration

`flows_list`

`flows_get`

`flows_upsert`

5. Connectors: installed, verified, activated

`get_connector_installation_status`

`get_connector_verification_status`

`get_connector_activation_status`

6. Context, insights and feedback

`get_context_hub`

`preview_daily_insight` / `publish_daily_insights`

`submit_feedback`

Next Steps & Cross-References

Renders, Dossiers and Sharing

Agent Rules

MCP App Use Cases

Host Integration

​1. Three profiles, one surface

​2. Reading what the platform already holds

​get_daily_report

​get_report

​get_data_quality_report

​get_source_capabilities

​3. Asking a new question: the analytical path

​explore_analyze_query

​execute_analyze_query_spec

​analyze_result

​render_analyze_result

​compose_dossier

​4. Governed flows and configuration

​flows_list

​flows_get

​flows_upsert

​5. Connectors: installed, verified, activated

​get_connector_installation_status

​get_connector_verification_status

​get_connector_activation_status

​6. Context, insights and feedback

​get_context_hub

​preview_daily_insight / publish_daily_insights

​submit_feedback

​Next Steps & Cross-References

Renders, Dossiers and Sharing

Agent Rules

MCP App Use Cases

Host Integration

1. Three profiles, one surface

2. Reading what the platform already holds

`get_daily_report`

`get_report`

`get_data_quality_report`

`get_source_capabilities`

3. Asking a new question: the analytical path

`explore_analyze_query`

`execute_analyze_query_spec`

`analyze_result`

`render_analyze_result`

`compose_dossier`

4. Governed flows and configuration

`flows_list`

`flows_get`

`flows_upsert`

5. Connectors: installed, verified, activated

`get_connector_installation_status`

`get_connector_verification_status`

`get_connector_activation_status`

6. Context, insights and feedback

`get_context_hub`

`preview_daily_insight` / `publish_daily_insights`

`submit_feedback`

Next Steps & Cross-References