Табуля

files_validations

Read-onlyIdempotent

Lists the data-validation rules in a Tabulya file, so you can inspect them before adding, replacing, or deleting. Scans every sheet unless 'sheet' is given. Each rule is { sheet, id, range (A1), kind ('checkbox'|'logical'|'dropdown'|'list'|'text'|'number'|'datetime'|'none') } plus its constraints under the same field names the files_set_* tools accept (values/source_range, min_length/max_length/exactly/contains/not_contains, min/max/greater_than/less_than/equals/not_equals, require_*/prohibit_* flags, date_*/time_* constraints) and 'strict'. Custom help/error texts appear as message_title/message_text/error_title/error_message; replacing by id via files_set_* rewrites the constraints but preserves these texts. Replacing by id overwrites all constraints, so read the current ones first. Extra markers: composite:true — the rule holds more conditions than these fields can express (do NOT blind-replace it); case_sensitive:true — a text rule matches case-sensitively (files_set_text_validation always writes case-insensitive rules); ignore_blank:false — the rule also validates empty cells (set tools always write true). Read-only; reflects the file's latest live state. Signature: files_validations(file_uuid, sheet?).

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": {
      "file_uuid": "<file_uuid>"
    },
    "name": "files_validations"
  }
}

Input Schema

Name	Required	Description	Default
`sheet`	No	Restrict to this sheet (defaults to all sheets).
`file_uuid`	Yes

Output Schema

Name	Required	Description	Default
`count`	Yes
`file_uuid`	Yes
`validations`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavioral detail: it scans all sheets by default, describes the per-rule return shape, discloses preservation of message/error texts on replacement, and warns about composite:true, case_sensitive, and ignore_blank:false markers that the set tools cannot reproduce.

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?

Front-loads the purpose and then packs in useful detail, with almost every clause carrying information. It is a dense single paragraph, however, and the long enumeration of constraint field names could be structured more scannably.

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

Completeness5/5

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

Covers scope (all sheets vs. one), return shape, marker semantics, preservation behavior, and the key blind-replace hazard. Since an output schema already exists, the extra return-shape detail is bonus rather than a requirement.

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 50%: 'sheet' is documented in the schema, while 'file_uuid' is not. The description repeats the sheet default ('Scans every sheet unless sheet is given') but adds little beyond the schema for parameters, and file_uuid is only listed in the signature without further semantics.

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?

States a specific verb ('Lists') and resource ('data-validation rules in a Tabulya file') and frames the inspection workflow relative to adding, replacing, and deleting. An agent can distinguish this from the files_set_* and files_delete_validation siblings without opening either schema.

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?

Explicitly says to inspect rules before adding, replacing, or deleting, and names the files_set_* tools as the replacement mechanism. It also warns 'Replacing by id overwrites all constraints, so read the current ones first,' which is a concrete when-to-use rule.

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

All Табуля 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?