Oviond

Add section to report

add_report_section

Add a saved section (asset) to a report — works for both reports and dashboards. Find the section first with list_assets (filter by name, type, or datasource). Page handling is automatic: a single-page report (typical dashboard) uses its one page; a multi-page report returns its pages so you can pass the right page_id.

Input Schema

TableJSON Schema

Name	Required	Description
`page_id`	No	Page to place it on (from list_pages). Omit to auto-use a single-page report, or to list pages when there are several.
`asset_id`	Yes	Saved section to add (from list_assets — filter by name, type, or datasource)
`client_id`	Yes	Client id (from list_clients)
`report_id`	Yes	Report or dashboard id to add the section to (from list_reports)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No	Either what was added — the page it landed on and the new widget ids — or, when the report has several pages and none was named, those pages so you can choose one and call again.
`success`	Yes	True when the call succeeded. A failure comes back as an error result instead.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "description": "Either what was added — the page it landed on and the new widget ids — or, when the report has several pages and none was named, those pages so you can choose one and call again."
+    },
+    "success": {
+      "description": "True when the call succeeded. A failure comes back as an error result instead.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

First observedSep 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation is expected. The description adds valuable behavioral context: it explains automatic page handling (single-page auto-use, multi-page returns pages) and clarifies that the tool works for both reports and dashboards. This goes beyond what annotations provide, though it doesn't detail side effects like whether adding a section modifies the report irreversibly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the first states the core action and scope, the second gives the prerequisite lookup, the third explains the page-handling nuance. Information is front-loaded and no filler exists.

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?

The description covers the key operational details: what to find first, how page_id behaves, and that it applies to both reports and dashboards. With an output schema present and annotations covering safety, the description is nearly complete. It could mention what happens if the asset is already on the page or whether the section is added at a specific position, but these are minor gaps.

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 description coverage is 100%, so the schema already documents all four parameters. The description adds extra meaning by explaining the page_id behavior (omit for single-page, or to list pages when multiple) and by clarifying that asset_id refers to a saved section from list_assets. This supplements the schema rather than merely repeating it.

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?

The description states a specific verb ('Add'), a specific resource ('a saved section (asset) to a report'), and explicitly notes it works for both reports and dashboards. It also distinguishes itself from sibling tools by naming list_assets as the prerequisite finder, which helps an agent understand what this tool does versus other 'add_*' tools.

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?

The description gives clear when-to-use guidance: find the section first with list_assets, and explains page handling behavior (single-page vs multi-page) so the agent knows when to pass page_id. It also implicitly differentiates from sibling add_*_widget tools by focusing on saved sections/assets rather than widgets.

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

All Oviond 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?