QuintaDB

create_report

Create a report (filter/view) for a form. Supports filter conditions, grouping, the sum/average per group, visible columns, sorting. For dates: yesterday, today, last_7_days, last_30_days, this_month, this_week, between (+ from/to), before, after and so on.

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": {
      "app_id": "<app_id>",
      "entity_id": "<entity_id>",
      "name": "<name>"
    },
    "name": "create_report"
  }
}

Input Schema

Name	Required	Description
`asc`	No	true = ascending (default), false = descending. Applies to sort_by.
`name`	Yes	Report name
`order`	No	asc or desc — the sort direction of the GROUPS (only when group_field_ids is given). This is NOT a sort field — use sort_by for that.
`app_id`	Yes	Project ID (from list_projects)
`sort_by`	No	ID or name of the field to sort the records by (used together with asc).
`per_page`	No	Records per page (default 10)
`criterias`	No	Filter conditions. For dates: yesterday, today, today_or_later, before_today, last_7_days, last_30_days, last_60_days, this_week, this_month, next_7_days, next_30_days, next_60_days, next_90_days, next_120_days (a window that moves with the day: «due in the next 60 days» = next_60_days, no from/to), between (+ from/to — two fixed calendar dates as YYYY-MM-DD, never a word like «today»), before, after. For texts: is, is_not, contains, not_contains, starts_with, ends_with, is_empty, is_not_empty. For numbers: is, is_not, less_than, greater_than, between.
`entity_id`	Yes	Form ID (from list_forms or describe_project)
`no_data_text`	No	The text the owner sees when NO record matches the report's filters. ⚠️ ALWAYS write it for reports with a filter — a new project has no records yet, so this report is first shown empty. In the user's language and about THEIR business: «No visits today yet — they will appear here as soon as a client books», not «no data».
`property_ids`	No	IDs or names of the fields shown (empty = all)
`total_by_group`	No	1 = show the sum of a number field for each group. total_by_group_column_id must be given.
`group_field_ids`	No	IDs of the fields to group by (GROUP BY). For example, group by status.
`average_by_group`	No	1 = show the average of a number field for each group. average_by_group_column_id must be given.
`only_groupname_and_count`	No	1 = show only the group's name and its number of records (no details)
`total_by_group_column_id`	No	ID or name of the number field whose sum per group is counted.
`average_by_group_column_id`	No	ID or name of the number field whose average per group is counted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedOct 26, 2026

changedInput schema / properties / asc / description

Previous value: -"true=за зростанням (default), false=за спаданням. Застосовується до sort_by."New value: +"true = ascending (default), false = descending. Applies to sort_by."

changedInput schema / properties / average_by_group / description

Previous value: -"1 = показати середнє числового поля по кожній групі. Обов'язково вказати average_by_group_column_id."New value: +"1 = show the average of a number field for each group. average_by_group_column_id must be given."

changedInput schema / properties / average_by_group_column_id / description

Previous value: -"ID або назва числового поля для підрахунку середнього по групі."New value: +"ID or name of the number field whose average per group is counted."

changedInput schema / properties / criterias / description

Previous value: -"Умови фільтрації. Для дат: yesterday, today, today_or_later, before_today, last_7_days, last_30_days, last_60_days, this_week, this_month, next_7_days, next_30_days, next_60_days, next_90_days, next_120_days (a window that moves with the day: «due in the next 60 days» = next_60_days, no from/to), between (+ from/to — two fixed calendar dates as YYYY-MM-DD, never a word like «today»), before, after. Для текстів: is, is_not, contains, not_contains, starts_with, ends_with, is_empty, is_not_empty. Для чисел: is, is_not, less_than, greater_than, between."New value: +"Filter conditions. For dates: yesterday, today, today_or_later, before_today, last_7_days, last_30_days, last_60_days, this_week, this_month, next_7_days, next_30_days, next_60_days, next_90_days, next_120_days (a window that moves with the day: «due in the next 60 days» = next_60_days, no from/to), between (+ from/to — two fixed calendar dates as YYYY-MM-DD, never a word like «today»), before, after. For texts: is, is_not, contains, not_contains, starts_with, ends_with, is_empty, is_not_empty. For numbers: is, is_not, less_than, greater_than, between."

changedInput schema / properties / criterias / items / properties / field / description
```
Previous value: -"Назва або ID поля"New value: +"Field name or ID"
```
changedInput schema / properties / criterias / items / properties / from / description
```
Previous value: -"Від (для between)"New value: +"From (for between)"
```

changedInput schema / properties / criterias / items / properties / join / description

Previous value: -"and або or (default: and)"New value: +"and or or (default: and)"

changedInput schema / properties / criterias / items / properties / search / description

Previous value: -"Значення для порівняння"New value: +"Value to compare with"

changedInput schema / properties / criterias / items / properties / search_n / description

Previous value: -"N для last_n_days, next_n_days тощо"New value: +"N for last_n_days, next_n_days and so on"

changedInput schema / properties / criterias / items / properties / to / description
```
Previous value: -"До (для between)"New value: +"To (for between)"
```

changedInput schema / properties / group_field_ids / description

Previous value: -"ID полів для групування (GROUP BY). Наприклад, групувати по статусу."New value: +"IDs of the fields to group by (GROUP BY). For example, group by status."

changedInput schema / properties / name / description

Previous value: -"Назва звіту"New value: +"Report name"

changedInput schema / properties / no_data_text / description

Previous value: -"Текст, який побачить власник, коли під фільтри звіту не підпадає ЖОДЕН запис. ⚠️ Пиши його ЗАВЖДИ для звітів із фільтром — у новому проєкті записів ще нема, тож першим цей звіт покажуть саме порожнім. Мовою користувача і про ЙОГО бізнес: «Сьогодні візитів ще немає — вони зʼявляться тут, щойно клієнт запишеться», а не «немає даних»."New value: +"The text the owner sees when NO record matches the report's filters. ⚠️ ALWAYS write it for reports with a filter — a new project has no records yet, so this report is first shown empty. In the user's language and about THEIR business: «No visits today yet — they will appear here as soon as a client books», not «no data»."

changedInput schema / properties / only_groupname_and_count / description

Previous value: -"1 = показати лише назву групи та кількість записів (без деталей)"New value: +"1 = show only the group's name and its number of records (no details)"

changedInput schema / properties / order / description

Previous value: -"asc або desc — напрям сортування ГРУП (лише коли задано group_field_ids). Це НЕ поле для сортування — для цього використовуй sort_by."New value: +"asc or desc — the sort direction of the GROUPS (only when group_field_ids is given). This is NOT a sort field — use sort_by for that."

changedInput schema / properties / per_page / description

Previous value: -"Записів на сторінку (default 10)"New value: +"Records per page (default 10)"

changedInput schema / properties / property_ids / description

Previous value: -"ID або назви полів що відображаються (пусто = всі)"New value: +"IDs or names of the fields shown (empty = all)"

changedInput schema / properties / sort_by / description

Previous value: -"ID або назва поля для сортування записів (використовується разом з asc)."New value: +"ID or name of the field to sort the records by (used together with asc)."

changedInput schema / properties / total_by_group / description

Previous value: -"1 = показати суму числового поля по кожній групі. Обов'язково вказати total_by_group_column_id."New value: +"1 = show the sum of a number field for each group. total_by_group_column_id must be given."

changedInput schema / properties / total_by_group_column_id / description

Previous value: -"ID або назва числового поля для підрахунку суми по групі."New value: +"ID or name of the number field whose sum per group is counted."

Changed1 schema field changedOct 10, 2026

changedInput schema / properties / criterias / description

Previous value: -"Умови фільтрації. Для дат: yesterday, today, last_7_days, last_30_days, this_week, this_month, next_7_days, between (+ from/to), before, after. Для текстів: is, is_not, contains, not_contains, starts_with, ends_with, is_empty, is_not_empty. Для чисел: is, is_not, less_than, greater_than, between."New value: +"Умови фільтрації. Для дат: yesterday, today, today_or_later, before_today, last_7_days, last_30_days, last_60_days, this_week, this_month, next_7_days, next_30_days, next_60_days, next_90_days, next_120_days (a window that moves with the day: «due in the next 60 days» = next_60_days, no from/to), between (+ from/to — two fixed calendar dates as YYYY-MM-DD, never a word like «today»), before, after. Для текстів: is, is_not, contains, not_contains, starts_with, ends_with, is_empty, is_not_empty. Для чисел: is, is_not, less_than, greater_than, between."

Changed1 schema field changedAug 9, 2026

addedInput schema / properties / no_data_text

Added value: +{
+  "description": "Текст, який побачить власник, коли під фільтри звіту не підпадає ЖОДЕН запис. ⚠️ Пиши його ЗАВЖДИ для звітів із фільтром — у новому проєкті записів ще нема, тож першим цей звіт покажуть саме порожнім. Мовою користувача і про ЙОГО бізнес: «Сьогодні візитів ще немає — вони зʼявляться тут, щойно клієнт запишеться», а не «немає даних».",
+  "type": "string"
+}

Changed3 schema fields changedJul 5, 2026

changedInput schema / properties / asc / description

Previous value: -"true=за зростанням (default), false=за спаданням"New value: +"true=за зростанням (default), false=за спаданням. Застосовується до sort_by."

changedInput schema / properties / order / description

Previous value: -"ID поля для сортування"New value: +"asc або desc — напрям сортування ГРУП (лише коли задано group_field_ids). Це НЕ поле для сортування — для цього використовуй sort_by."

addedInput schema / properties / sort_by

Added value: +{
+  "description": "ID або назва поля для сортування записів (використовується разом з asc).",
+  "type": "string"
+}

First observedJun 27, 2026

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered; the description adds no context beyond that — nothing about whether duplicate report names are allowed, whether the report is immediately visible to portal users, or whether creation can fail. With annotations carrying the safety burden the bar is lower, but the description contributes essentially nothing on the behavioral side.

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?

Two sentences, front-loaded with the core action and then a compact capability list. The date-condition tail partly duplicates the schema, which is the only wasted space, but overall it is tight and well ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter creation tool with no output schema, the description says nothing about what comes back (a report ID?) or what happens on success. The very rich inline schema compensates for most of this, so the definition is callable, but the narrative layer is thinner than the tool's complexity warrants.

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 the baseline is 3. The description groups parameters functionally ('filter conditions, grouping, the sum/average per group, visible columns, sorting') and lists date condition values, but those values are already enumerated almost identically in the criterias schema description, so the added meaning is marginal.

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 opens with a specific verb and resource ('Create a report (filter/view) for a form') and enumerates the capabilities (filters, grouping, sums/averages per group, visible columns, sorting). It does not, however, distinguish this from the sibling create_saved_view or explain how a 'report' differs from a chart or saved view, so an agent must infer the boundary.

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?

Usage is only implied: the description tells you what a report can contain, which suggests when it is useful, but it never states when to prefer this over create_saved_view or create_chart, nor does it mention prerequisites such as needing an existing form. The agent must derive the triggering context from the capabilities list.

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

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