Auto-discover validation rules from data — scan, profile, health-score. No rules to write.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 19 of 19 tools scored. Lowest: 2.9/5.
Tool purposes are mostly distinct, though 'profile', 'scan', and 'analyze_data' have overlapping scopes (all analyze data files) but descriptions clarify differences. 'explain_column' and 'get_column_detail' are similar but serve different presentation styles.
Consistent verb_noun pattern (e.g., 'install_domain', 'list_checks', 'explain_finding'), all lowercase with underscores. Minor deviation like 'approve_reject' still fits the pattern.
19 tools is slightly above the typical 3-15 range but justified by the broad scope of data quality analysis, covering scanning, profiling, review, validation, and domain management.
Covers a full lifecycle: scan, profile, explain, review, validate, and generate attestation. Missing apply-fix and delete-domain operations, but these are minor gaps for the domain.
analyze_dataCInspectAnalyze a data file to detect its domain, profile columns, and recommend a scanning strategy. Returns domain detection, column count, row count, strategy decisions, and alternative approaches.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file (CSV, Parquet, Excel) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits beyond outputs; side effects or read-only nature are not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no wasted words. Efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 1-param tool, but lacks usage context and behavioral details given 18 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Tool description adds context but no new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'analyze' and resource 'data file', with specific outputs like domain detection, column count, etc. However, does not explicitly differentiate from sibling tools like 'profile' or 'scan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
approve_rejectAInspectApprove (pin) or reject (dismiss) a review queue item. Decision must be 'pin' or 'dismiss'.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional reason for the decision | |
| item_id | Yes | Review item ID to update | |
| decision | Yes | Decision: 'pin' (approve) or 'dismiss' (reject) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It only states the action and decision values but does not disclose side effects, required permissions, reversibility, or return behavior. For a mutation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundancy. The first sentence states the core purpose, and the second clarifies the decision values. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema or annotations. The description covers the decision values but lacks details on what happens after the action, error conditions, or post-invocation state. Adequate for a simple action but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description clarifies the enum values by equating 'pin' with approve and 'dismiss' with reject, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it approves (pin) or rejects (dismiss) a review queue item, with a specific verb and resource. It distinguishes from sibling tools like 'review_queue' by focusing on the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used for making a decision on a review queue item, but does not explicitly state when to use it versus alternatives like 'review_queue' or 'analyze_data'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
auto_configureAInspectScan a data file, triage findings by confidence, and generate goldencheck.yml content from the pinned findings. Optionally accepts constraints to filter or adjust the generated config.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file | |
| constraints | No | Optional constraints: {min_confidence, severity_filter, include_columns, exclude_columns} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the process (scan, triage, generate) but does not mention potential side effects, authentication requirements, or whether the operation is destructive. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey the tool's function. No redundant words or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description adequately covers the purpose and optional constraints. It does not detail return values or full workflow, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds that constraints 'filter or adjust the generated config', which slightly enhances understanding but is already implied by the schema parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a data file, triages findings by confidence, and generates goldencheck.yml content. This is specific and distinguishes it from sibling tools like 'scan' or 'analyze_data' which don't generate config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating configuration after scanning, but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_domainsAInspectScan a file with every available domain pack (plus base/no-domain) and compare health scores. Recommends the best-fitting domain.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses core behavior (scan with all packs, recommend best) but does not mention potential performance impact, authorization needs, side effects, or output format. Adequate but minimal depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded with the core action. Every word contributes meaning; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is fairly complete. It covers the input, process, and output (recommendation). Could mention output format or destination, but acceptable given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds context by explaining how the file is used (scanned with domain packs), which goes beyond the basic schema description of 'Path to the data file'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scan, compare, recommend) and the resource (file with domain packs, health scores). It distinguishes the tool from siblings like 'health_score' (which likely reports a single score) and 'list_domains' (which just lists packs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for selecting the best domain by comparing all packs, but does not explicitly state when to use this vs alternatives like 'health_score' or 'scan'. It lacks when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_columnBInspectGet a natural-language health narrative for a specific column. Scans the file, profiles the column, and explains all findings.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | Column name to explain | |
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies read-only behavior by describing scanning and profiling without mentioning destructive actions, but does not explicitly confirm safety, state potential performance impacts, or describe what happens to findings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the purpose and process. No wasted words, though the key output ('health narrative') could be front-loaded more prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and steps, but lacks details on return format, expected runtime, or any side effects. For a tool that scans and profiles, more context would be helpful, given no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds minimal extra meaning ('for a specific column', 'scans the file') but does not introduce new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a natural-language health narrative for a specific column, involving scanning, profiling, and explaining. It distinguishes from siblings like 'profile' and 'get_column_detail' by focusing on narrative output, but does not explicitly compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'profile' or 'get_column_detail'. It lacks prerequisites, exclusions, or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_findingBInspectExplain a single finding in natural language. Requires the finding as a JSON dict and the file_path to load a profile for context.
| Name | Required | Description | Default |
|---|---|---|---|
| finding | Yes | Finding dict with keys: severity, column, check, message, affected_rows, confidence, sample_values | |
| file_path | Yes | Path to the data file (needed for profile context) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool requires specific inputs and explains in natural language, but does not mention side effects, permissions, rate limits, or whether it is read-only. The behavior is underspecified for an explanation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences covering purpose and requirements with no superfluous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify the return format. 'In natural language' is vague. It covers inputs well but omits output structure, error handling, or behavior in edge cases. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds context by explaining that file_path is needed 'to load a profile for context,' which goes beyond the schema. This adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains a single finding in natural language, specifying required inputs. It distinguishes from sibling 'explain_column' by focusing on findings rather than columns, but doesn't explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required inputs but provides no guidance on when to use this tool versus alternatives like 'explain_column' or other analysis tools. No when-not criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_column_detailCInspectGet detailed profile and findings for a specific column.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | Column name to inspect | |
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states it 'gets' information, implying a read-only operation, but lacks details on permissions, side effects, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too sparse. It doesn't explain what constitutes a 'detailed profile' or what findings are returned, leaving the agent with limited understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds no additional meaning beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a detailed profile and findings for a specific column, using a specific verb+resource structure. However, it doesn't explicitly differentiate from sibling tools like 'explain_column' or 'get_domain_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_domain_infoAInspectGet detailed info about a specific domain pack — lists all semantic types, their name hints, and suppression rules.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain pack name (e.g., healthcare, finance, ecommerce) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It fails to disclose read-only nature, authentication needs, rate limits, or any side effects. Assumed safe but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, extremely concise with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, description adequately outlines return content (semantic types, hints, suppression rules). Missing some details like format or additional metadata, but sufficient for a simple info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the 'domain' parameter with examples. Description adds no further semantic value beyond what schema provides, meriting baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'get' and resource 'domain pack info', and enumerates specific content: semantic types, name hints, suppression rules. Distinguishes from sibling tools like list_domains (which lists all packs) and compare_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when detailed info on a specific domain pack is needed, but lacks explicit when-to-use vs. alternatives or any exclusion criteria. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_scoreAInspectGet the health score (A-F, 0-100) for a data file. Quick summary of overall data quality.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly implies a read-only operation via 'Get', but does not explicitly state lack of side effects, required permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, just one short sentence that is front-loaded with key information (output format and purpose). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return (score with letter and number), but lacks clarity on the full return structure or how it compares to sibling tools that may also assess data quality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for file_path. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a health score (A-F, 0-100) for a data file, with 'Quick summary of overall data quality' hinting at its role. However, it does not explicitly differentiate from sibling tools like 'analyze_data' or 'profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a quick overview via 'Quick summary', but provides no explicit guidance on when to use this tool versus alternatives, or any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
install_domainAInspectDownload a community domain pack from the goldencheck-types repository and save it for use in future scans.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain pack name to install | |
| output_path | No | Output path (default: goldencheck_domain.yaml) | goldencheck_domain.yaml |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It reveals the source ('goldencheck-types repository') and effect ('saves for future scans'), but does not disclose whether it overwrites existing packs, requires network access, or checks for updates. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description adequately explains the action and purpose. However, it omits what the tool returns upon success (likely nothing or a confirmation), which is a gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond parameter names and their schema descriptions; it only provides context about the repository source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('download and save') and the resource ('community domain pack from goldencheck-types repository'), and explains the purpose ('for use in future scans'). This distinguishes it from siblings like list_domains and get_domain_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as list_domains or compare_domains. No explicit context about prerequisites or when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_checksAInspectList all available profiler checks and what they detect. No arguments needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description bears full responsibility for behavioral disclosure. It correctly conveys that this is a read-only listing operation with no side effects, and the statement 'No arguments needed' implies it is safe and stateless. However, it does not detail response format or potential edge cases, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences with no filler. It front-loads the action and resource, then confirms no parameters. Every word serves a purpose, and the structure is optimal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is reasonably complete. It tells the agent what the tool does and what it returns (list of checks and their detections). It does not mention prerequisites or whether the list is dynamic, but these are minor omissions for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds the explicit confirmation 'No arguments needed,' which reinforces the schema and eliminates any doubt. This meets the baseline standard and provides clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (all available profiler checks), and the scope (what they detect). It uses a specific verb and resource, leaving no ambiguity about the tool's purpose. It also explicitly notes that no arguments are needed, which removes any uncertainty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when one needs to see available profiler checks and their detection capabilities, but it does not explicitly state when to use it vs. alternatives or provide any exclusion criteria. The mention of 'No arguments needed' gives some usage context but is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsAInspectList all available domain packs (healthcare, finance, ecommerce, etc.). Domain packs provide specialized semantic type definitions for specific data domains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It clearly states the read-only listing behavior with no side effects mentioned, which is appropriate for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a parameterless list tool with no output schema; explains what domain packs are. Could optionally hint at output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline of 4 applies as per rules. Description adds no param details but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it lists domain packs with examples (healthcare, finance, ecommerce), clearly distinguishing from siblings like install_domain (install), get_domain_info (single item), compare_domains (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for browsing available domains before installation or detailed info, but no explicit when-not or alternatives listed. Context from sibling tools provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pipeline_handoffAInspectGenerate a structured quality attestation JSON for a data file. Includes health score, findings summary, pinned rules, and attestation status (PASS, PASS_WITH_WARNINGS, REVIEW_REQUIRED, FAIL).
| Name | Required | Description | Default |
|---|---|---|---|
| job_name | Yes | Job name for the handoff record | |
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output structure (health score, findings summary, etc.) and possible statuses, but does not mention side effects, authorization needs, or whether the tool is read-only or mutating. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence front-loading the verb 'Generate'. It is concise, free of fluff, and includes all essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains the return structure. Two parameters are fully documented in the schema. The context signals indicate low complexity, and the description covers the tool's purpose and output adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (file_path and job_name). The description adds context by stating 'for a data file' and 'for the handoff record', but does not add meaning significantly beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a structured quality attestation JSON for a data file, specifying components like health score, findings summary, pinned rules, and attestation status. This distinguishes it from siblings like analyze_data or approve_reject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for handoff after quality checks, but it does not explicitly state when to use it versus siblings or provide any exclusions or alternatives. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
profileAInspectProfile a data file and return column-level statistics: type, null%, unique%, min/max, top values, detected formats. Also returns a health score (A-F) based on finding severity.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file | |
| sample_size | No | Max rows to sample (default 100000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool profiles a data file (a read operation) and returns specific statistics, but does not mention file format support, size limits, or any potential side effects. While the output is clear, additional behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences. The first sentence lists the outputs concisely, and the second sentence adds the health score. There is no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is fairly complete. It enumerates the key statistics returned and mentions the health score. However, it could be improved by noting the return format (e.g., JSON structure) or any limitations like file size or encoding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new meaning beyond the schema; it implicitly refers to the parameters (file_path, sample_size) but provides no additional syntax or formatting details. The schema already explains both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that the tool profiles a data file and returns column-level statistics including type, null%, unique%, min/max, top values, detected formats, and a health score. This is a precise verb+resource combination that fully explains the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like analyze_data, explain_column, or health_score. There is no indication of prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_queueAInspectList all pending review items for a given job. Returns items that need human decision (medium-confidence findings).
| Name | Required | Description | Default |
|---|---|---|---|
| job_name | Yes | Job name to filter review items |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It indicates that only pending items are returned, but does not mention side effects, such as whether data is modified, or behavior when no items exist or job is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loads the action, and contains no fluff. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description adequately covers core purpose and item criteria. However, it could mention ordering, pagination, or that it is a prerequisite for approve_reject.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema: it simply restates that the tool filters by job_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('list') and resource ('pending review items'), and specifies its context ('for a given job', 'medium-confidence findings'), effectively distinguishing it from siblings like approve_reject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing medium-confidence findings but does not explicitly specify when to use this tool versus alternatives like approve_reject or analyze_data. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_statsAInspectGet review queue statistics for a job — counts of pending, pinned, and dismissed items.
| Name | Required | Description | Default |
|---|---|---|---|
| job_name | Yes | Job name to get stats for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of disclosing behavior. It indicates a read-only operation ('get') but lacks details on permissions, performance implications, or whether statistics are cached or real-time. The description is minimally adequate but does not go beyond stating the observed counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 12 words, front-loading the action and resource efficiently. No extraneous information is present, and it is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple statistics tool with no output schema, the description explains what counts are returned (pending, pinned, dismissed), which is helpful. However, it does not mention the return format or any other possible fields (e.g., total), leaving some ambiguity. It is nearly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'job_name', which is already described as 'Job name to get stats for'. The tool description adds no additional semantic meaning beyond what the schema provides, so it meets baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'review queue statistics for a job', specifying the exact counts (pending, pinned, dismissed). This distinguishes it from siblings like 'review_queue' and 'analyze_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for any job but does not provide explicit guidance on when to use this tool versus alternatives like 'review_queue' or 'get_domain_info'. No exclusions or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scanBInspectScan a data file (CSV, Parquet, Excel) for data quality issues. Returns findings with severity, confidence, affected rows, and sample values. No configuration needed — rules are discovered from the data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file (CSV, Parquet, Excel) | |
| llm_boost | No | Enable LLM enhancement (requires API key env var) | |
| sample_size | No | Max rows to sample (default 100000) | |
| llm_provider | No | LLM provider: 'anthropic' or 'openai' | anthropic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the return format (findings with severity, confidence, affected rows, sample values) and rule discovery, but does not cover side effects, performance, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading the core purpose and adding a key detail about no configuration. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description compensates by summarizing return fields. It omits clarifications on access requirements or types of issues, but is sufficient for a relatively straightforward scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meeting baseline. The description adds no extra semantic value beyond the schema's parameter descriptions; it only reiterates supported file types already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans data files for quality issues, specifying file types and return fields. It distinguishes from siblings by emphasizing no configuration needed, but lacks explicit comparison to related tools like 'validate' or 'profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'no configuration needed' implying automatic use, but provides no explicit guidance on when to use this tool versus siblings (e.g., 'validate', 'analyze_data') or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_fixAInspectPreview fixes for a data file without applying them. Shows what would change (columns, fix types, rows affected, before/after samples).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Fix mode: 'safe' (default) or 'aggressive' | safe |
| file_path | Yes | Path to the data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool is non-destructive ('without applying them') and lists the kind of output. It could add details like idempotency or rate limits, but it is sufficient for a read-only preview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core purpose, the second details the output. Information is front-loaded and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no output schema), the description covers the purpose, behavior, and output format adequately. No additional detail is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with 100% description coverage. The tool description does not add extra semantics beyond the schema, such as explaining the 'mode' enum values ('safe' vs 'aggressive'), so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews fixes without applying them, and enumerates what it shows (columns, fix types, rows affected, before/after samples). It distinguishes from sibling tools like 'approve_reject' and 'validate' by emphasizing dry-run behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when previewing fixes is desired ('Preview fixes... without applying'), but it does not explicitly state when not to use this tool or mention alternatives such as 'approve_reject' for applying fixes. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validateBInspectValidate a data file against pinned rules in goldencheck.yml. Returns validation findings (existence, required, unique, enum, range checks).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the data file | |
| config_path | No | Path to goldencheck.yml (default: ./goldencheck.yml) | goldencheck.yml |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions output types but does not disclose side effects (e.g., whether the tool modifies data or is read-only), permission requirements, or other behavioral traits, leaving the agent with incomplete information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and contains no extraneous information. Every word contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description provides a reasonable overview. However, it lacks details about the config_path parameter's default behavior and does not include an output schema, so the agent may need to infer the exact response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds context about validation checks, but does not further elaborate on the parameters beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a data file against pinned rules in goldencheck.yml and specifies the types of checks performed. While it distinguishes from siblings by focusing on this specific rule file, it does not explicitly contrast with similar tools like 'scan' or 'profile', so a slight deduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a data file needs to be validated against goldencheck.yml rules, but it does not provide guidance on when to prefer this tool over siblings like 'scan' or 'analyze_data', nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
