Skip to main content
Glama
semantic-rails

Semantic Rails MCP Server

Official

profile_columns

Read-onlyIdempotent

Inspect column distributions with counts, min/max, and sample rows (up to 20) for tables up to one million rows, read-only.

Instructions

Per-column counts, min/max and up to 20 samples (sample_limit=0 for none), sampling tables above max_rows (at most one million). Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
columnsNo
max_rowsNo
relationYes
duckdb_pathNo
project_pathNo
sample_limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

B3.2/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 behavior, so the description's 'Read-only' is redundant. However, it adds real behavioral context about sampling limits, sample_limit=0 disabling samples, and the max_rows cap, which goes beyond the annotations.

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?

The description is a single compact sentence, but the parenthetical stacking makes it awkward and slightly ambiguous. Every phrase is information-dense, yet the lack of clear structure reduces readability.

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

Completeness2/5

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

The output schema exists, so return-value documentation is not required, but the description leaves several parameters unexplained and does not clarify the relationship between 'up to 20 samples' and the sample_limit default. For a tool with six parameters, this is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter semantics, but it only explains sample_limit and max_rows. Required parameters like relation and important optional parameters like columns, duckdb_path, and project_path are not described. The 'up to 20 samples' claim is also potentially confusing given the default sample_limit of 5.

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 clearly states what the tool produces: per-column counts, min/max, and samples. This is specific enough to identify it as a data-profiling tool rather than a schema or row-preview tool, though it never explicitly names a sibling to distinguish itself from.

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?

The read-only and sampling behavior implies this is for quick exploratory profiling, but there is no explicit guidance on when to choose it over alternatives like describe_table or preview_query. The description gives context but no exclusions or comparison to siblings.

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