QuintaDB

get_public_page

Read-onlyIdempotent

A table's PUBLIC page — the address its owner gives to people who have no account. Answers every switch of the page with its meaning, what a visitor can do there right now in plain words, what a visitor GETS (visitor_gets: the columns sent to them and the hidden ones, what the search takes, the «nothing found» words, the address that opens ONE record), and the addresses to hand out: the page's link, short link and embed code, and the same three for the public FORM that adds a record. Call it when the person asks for a link to share, a link to one record, an embed code for their site, or whether their data is open.

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": "get_public_page"
  }
}

Input Schema

Name	Required	Description
`app_id`	Yes	Project ID (from list_projects)
`entity_id`	Yes	The table
`report_id`	No	A report of that table (from get_reports): the public page of the REPORT — its own switches, columns and search. Leave it out for the table's own page

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / report_id

Added value: +{
+  "description": "A report of that table (from get_reports): the public page of the REPORT — its own switches, columns and search. Leave it out for the table's own page",
+  "type": "string"
+}

AddedOct 8, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, which covers the safety profile. The description goes further by detailing the return payload — visitor_gets columns, visible vs hidden columns, search behavior, "nothing found" wording, and the link/short-link/embed triple for both page and form — which is genuine behavioral value.

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

Conciseness3/5

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

It is front-loaded with the core concept, but the middle is one long, densely parenthesized rumination that is hard to parse on first read ("Answers every switch of the page with its meaning..."). Shorter, structured phrasing would communicate the same content with less friction.

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 no output schema and no annotations about returns, the description carries the burden and largely meets it, enumerating the link/embed outputs and visitor capability details. Minor gaps remain around the exact response shape, but an agent has enough to call and interpret the tool.

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 coverage is 100%, so all three parameters, including the report_id switch between the table page and the report page, are already documented in the schema. The description restates the report variation ("the address that opens ONE record", "the public FORM") without adding format or syntax detail beyond the structured fields.

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?

States a specific verb and resource — retrieves a table's public (no-account) page — and defines the concept crisply as "the address its owner gives to people who have no account." It does not explicitly distinguish itself from the nearby get_portal_page / update_public_page siblings, so an agent must infer the boundary rather than being told it.

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

Usage Guidelines4/5

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

Ends with an explicit trigger list: "Call it when the person asks for a link to share, a link to one record, an embed code for their site, or whether their data is open." It gives clear when-to-use context but never names when-not or a competing sibling (e.g., update_public_page for changes), leaving the negative case to inference.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?