QuintaDB

add_record_comment

Add a comment to a record.

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>",
      "record_id": "<record_id>",
      "body": "<body>"
    },
    "name": "add_record_comment"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	Comment text
`app_id`	Yes	Project ID (from list_projects)
`record_id`	Yes	Record ID (from get_records or search_records)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- changedInput schema / properties / body / description
```
Previous value: -"Текст коментаря"New value: +"Comment text"
```
First observedJun 27, 2026

TDQS

B3.1/5.0

Behavior3/5

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

The description is basic and relies primarily on the annotations to convey behavioral traits (e.g., it is not destructive, it is not read-only). It adds no unique behavioral context beyond the obvious meaning of 'add'.

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?

The single sentence is perfectly concise. It avoids fluff and delivers the core function immediately and effectively.

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?

Given the simple nature of the operation and the full coverage of input parameters, the description is functionally complete. It lacks depth regarding potential error states or limitations, but is adequate for invocation.

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%, meaning the schema provides complete semantic information for the input parameters. The description adds no additional meaning or constraints beyond that provided in the schema, thus hitting the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Add a comment') and the target ('a record'). However, it fails to distinguish this action from similar siblings like 'delete_record_comment' or 'update_record_comment'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus related tools (e.g., when to update an existing comment or delete one). It offers no usage context or alternatives.

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?