Skip to main content
Glama

profile_sheet

Analyze an Excel sheet to reveal column types, null counts, min/max values, metadata, and sample data, helping inspect spreadsheet structure before edits or queries.

Instructions

Profile sheet data: metadata, inferred types, null counts, min/max, sample values.

Args: path: Path to the .xlsx file, or the name of a preloaded file. Omit if only one file is configured. sheet: Sheet name. sample_rows: Number of non-null sample values to return per column.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
sheetYes
sample_rowsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the tool reads the entire sheet (performance), whether profiling a large sheet has limits, whether it requires the file to be open/unlocked, or any side effects. The argument hints are documented but add little behavioral context.

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-loaded with the return payload then a short Args block. Minimal and efficient, though the summary sentence is a terse fragment rather than a full description of what the tool does.

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?

With no annotations and 0% schema coverage, the description does a fair job naming parameters and output fields. But it leaves behavioral questions (full-sheet scan cost, error conditions for a missing sheet, whether the file must be configured first) unanswered, and there is no output schema detail for the profile object shape.

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 0%, so the prose args section is the only source of parameter meaning. It explains path (xlsx path or preloaded file name, omit if only one file is configured) and sample_rows (non-null sample values per column), which is helpful, but it omits what 'sheet' accepts and never mentions that sample_rows has a default of 3.

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 (profile) and resource (sheet) and enumerates what is produced: metadata, inferred types, null counts, min/max, sample values. That distinguishes it from siblings like get_workbook_info, read_sheet, and aggregate_sheet, though the description never explicitly names those alternatives.

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?

No when-to-use guidance beyond the implicit 'call it to get profile data'. There is no mention of when to prefer read_sheet or aggregate_sheet, no prerequisites, and no cost or performance context for a profiling operation that likely scans the whole sheet.

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