Data Recon MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool has a distinct purpose: data source management, discovery, validation, various checks, and job control. No significant overlap; similar tools like compare_table_structures and run_schema_check are differentiated by usage context.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase and underscores, e.g., add_datasource, validate_table_exists, run_row_count_check. No naming inconsistencies or mixed conventions.
Tool Count4/5
With 23 tools, the set is slightly on the higher side but each tool fulfills a clear role in the reconciliation workflow. The count is justified by the need for separate validation, discovery, and check functions.
Completeness4/5
The tool surface covers the core reconciliation lifecycle: source management, discovery, validation, structural and data checks, job creation, monitoring, and results retrieval. Minor gaps like updating datasource configuration exist but do not hinder the primary workflow.
Average 3.6/5 across 23 of 23 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 26, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states the basic action without detailing whether it is read-only, requires permissions, or what side effects exist. This is inadequate for safe invocation.
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 very short (two sentences) and front-loaded, but it sacrifices necessary detail. Conciseness is valued, but here it leads to incompleteness rather than efficiency.
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?
Given two untyped object parameters, no output schema, and no annotations, the description fails to provide enough context for an agent to understand inputs, outputs, or behavior. It is not complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description gives zero information about what 'source' and 'target' parameters represent (e.g., table names, connection strings). The agent cannot determine how to populate these objects.
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 states it compares table schemas (column names, data types), which is clear. However, it does not differentiate itself from the nearly identical sibling tool 'compare_table_structures', leaving potential confusion for the agent.
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 a brief 'USE' sentence but no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives. Given the similar sibling, this is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only mentions 'quick statistics' and hints at speed for estimation. It does not state that the operation is read-only, non-destructive, or any authentication/rate-limit requirements. The behavioral disclosure is minimal and leaves gaps.
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 description is extremely concise with two sentences: the first states the purpose, the second provides usage guidance. Every sentence adds value without redundancy. No wasted words.
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 tool has four parameters (three required) and no output schema. The description covers purpose and usage but lacks parameter explanations and behavioral details (e.g., performance, accuracy, side effects). Given the complexity and absence of annotations, the description is incomplete for comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters (datasource_name, database, table, schema). It does not explain what each parameter represents or how to use them. The agent must rely entirely on parameter names, which may be ambiguous.
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 the tool retrieves quick statistics (row count, column count, size). The verb 'Get' and resource 'statistics' are specific. While it does not explicitly differentiate from siblings like get_table_schema or get_sample_data, the context of 'quick statistics' implies a lightweight summary, distinguishing it from structural or sample data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a use case: 'For sanity check before reconciliation, to estimate how long checks might take.' This gives clear context for when to use the tool. It does not mention when not to use it or alternatives, but the guidance is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention any side effects, authentication requirements, rate limits, or error behaviors (e.g., what happens if the table doesn't exist).
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 description is extremely concise with two sentences. The core purpose is front-loaded, and every sentence adds value. No wasted words.
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?
For a simple schema retrieval tool with no output schema, the description gives the key output details. However, it lacks parameter explanations and behavioral details, which are needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no additional meaning for the parameters (datasource_name, database, table, schema). It does not explain their roles or that schema is optional.
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 the tool returns column definitions (name, type, nullable, primary key). It uses a specific verb and resource. However, it does not differentiate from siblings like compare_table_structures which also deals with table schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: understand table structure, find numeric columns for aggregates, find primary keys for sample checks. It implies when to use but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states it verifies column existence but does not specify return value, side effects, error handling, or authentication requirements. Critical details are missing.
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?
Concise single-sentence description with a warning emoji for emphasis. However, it lacks structure such as parameter descriptions or return value details, but remains compact.
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?
Given five parameters and no output schema, the description fails to convey what the tool returns, how errors are reported, or detailed parameter roles. It is incomplete for an agent to use without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The tool description adds no information about any of the five parameters (e.g., datasource_name, database, table, columns, schema). This is inadequate for proper usage.
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?
Clearly states the verb 'Verify columns exist' and the resource 'columns'. Distinguishes from sibling tools like run_aggregate_check by explicitly stating it is a prerequisite for aggregate checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to call this before run_aggregate_check and explains the benefit (prevent errors from typos/missing columns). However, it does not mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool prevents errors but does not describe what happens upon success or failure (e.g., return value, error handling), nor does it mention any permissions or side effects.
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?
The description is brief and front-loads critical information with a warning symbol and clear instructions. It could be slightly more concise but is well-structured for quick understanding.
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?
Given the lack of output schema, annotations, and parameter documentation, the description fails to cover essential context like return format, handling of missing tables, or optional schema usage. The tool is simple but the description leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation for any of the 4 parameters (datasource_name, database, table, schema). The agent receives no guidance on parameter meaning or valid values.
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?
The description clearly states 'Verify a table exists' and explicitly mentions it must be called before sibling tools like run_row_count_check, run_aggregate_check, run_schema_check, and run_sample_check, distinguishing its role as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use instructions ('REQUIRED BEFORE CHECKS', always call for both source and target tables before specific checks) and mentions the benefit of preventing wasted time. It lacks explicit exclusion guidance for other tools but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It only says 'Cancel a running job' without disclosing whether the cancellation is reversible, requires permissions, or produces any output.
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 description is extremely concise with two sentences. The first sentence states the action, and the second provides usage context. No wasted words.
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?
Given the simplicity (1 parameter, no output schema) and the clear purpose, the description is moderately complete. However, it lacks behavioral details that would be expected given the absence of annotations.
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%. The description does not explain the 'job_id' parameter beyond its obvious meaning; no details on format or allowed values.
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 'Cancel a running job' with a specific verb and resource. It adds context with 'long-running reconciliation', effectively distinguishing from sibling tools like get_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE: When user wants to stop long-running reconciliation', providing clear guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It says 'recent' but does not define recency, order, scoping (user-specific vs global), or pagination behavior beyond the limit parameter's default. This leaves significant ambiguity.
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 description is extremely concise at two sentences, with no wasted words. Every sentence serves a purpose: stating what the tool does and when to use it.
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?
Given the simplicity of the tool (2 parameters, no output schema, no annotations), the description is insufficient. It fails to explain parameter usage, behavioral details like ordering or recency definition, leaving gaps that an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters. However, it mentions no details about the 'limit' or 'status_filter' parameters, leaving the agent without any semantic guidance beyond the schema's enum values.
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?
The description clearly specifies the tool lists 'recent reconciliation jobs' and states its use for seeing job history or finding previous results. This distinguishes it from sibling tools like cancel_job or get_job_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE: To see job history or find previous results,' providing clear context for when to use. However, it does not exclude alternatives or mention when not to use it, such as for getting detailed job results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses async execution and directs to get_job_status for monitoring. It mentions prerequisites but omits other behavioral aspects like failure modes, idempotency, or required permissions.
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 description is two sentences with no fluff: first sentence states purpose, second covers async behavior and prerequisites. Information is front-loaded and well-structured.
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?
Given the complexity (nested parameters, async job creation) and absence of output schema, the description lacks key details: return value (e.g., job ID), error handling, result interpretation. It covers only purpose and a few constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (source, target, checks, partition_config). The description fails to add meaning beyond the schema, leaving the agent without guidance on how to fill these objects.
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?
The description clearly states the tool creates a comprehensive reconciliation job with multiple checks, using specific verb 'create' and resource 'reconciliation job'. It distinguishes from sibling tools like individual check runs by emphasizing 'comprehensive' and listing prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes prerequisites (validate_table_exists, compare_table_structures) and notes the async nature with monitoring via get_job_status. However, it does not explicitly contrast when to use this tool vs running separate individual checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose read-only nature, authentication needs, pagination, or output format. Only states it lists tables, with no further 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose and immediate usage guidance. Perfect conciseness.
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?
Adequate for a simple list tool, but lacks details on return format, behavior when schema is omitted, and any performance notes. With 3 params and no output schema, description could be more complete.
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 coverage is only 33% (schema param has description). The tool description adds no additional meaning beyond 'database/schema'—it does not explain datasource_name or database parameters. Baseline 3 not met due to low coverage and no compensation.
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 the verb 'List' and resource 'tables' with scope 'in a database/schema'. It distinguishes from sibling search_tables by referencing it, but could be more explicit about the difference between listing all vs. filtering.
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 'PREFER search_tables if user mentions a specific table name pattern.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It notes the tool is fast and catches major issues, implying a read-only check, but does not explicitly state behavioral traits like nondestructiveness or rate limits. More context about what happens during execution would improve transparency.
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?
Three sentences, each adding value. Front-loaded with key purpose and urgency. No redundancy or wasted words. Efficient and clear.
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?
The description covers prerequisites and a common use case (partitioned large tables) but lacks details about return values, error scenarios, or behavior when source/target tables don't exist (assuming validate_table_exists handles that). Given no output schema, more context on results would enhance completeness.
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 coverage is low (33%), with only partition_config having a description. The description adds no semantic meaning for required source and target parameters beyond the schema. For partition_config, it adds 'for incremental comparison', which helps, but overall insufficient to compensate for the coverage gap.
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 the tool compares row counts and is a fast first check. It implies a preliminary role but does not explicitly differentiate from siblings like 'run_aggregate_check' or 'run_schema_check', missing explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites ('validate_table_exists'), recommends using it first, and gives guidance for large tables with partition_config. However, it does not mention when to avoid using this tool or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only operation and specifies the condition (after job completion), but does not disclose whether results are retrievable multiple times, any side effects, or authentication needs.
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 description consists of two concise sentences with no fluff. The main purpose is front-loaded, and the usage instruction is clear. Every sentence earns its place.
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?
Given the tool's simplicity (1 param, no output schema), the description covers the essential purpose and usage condition. However, it lacks information about return values (what 'detailed results' entails) and does not reinforce that job_id is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (job_id) with 0% description coverage, and the description does not mention job_id at all. It adds no meaning beyond what the schema provides, failing to compensate for low schema coverage.
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 the tool's purpose: retrieving detailed results after a job completes. It uses specific verb 'Get' and resource 'detailed results', distinguishing it from siblings like get_job_status. However, 'detailed results' is somewhat vague and could be more precise.
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?
The description explicitly states when to use this tool: after get_job_status shows status=completed. It references the sibling tool and provides a clear precondition, making it excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states it compares aggregates but does not disclose behavioral traits like read-only, side effects, or performance implications. More detail is needed.
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 description is concise with three sentences, each earning its place: purpose, prerequisites, and usage. It front-loads the core function.
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 tool has 5 parameters, nested objects, no output schema, and no documentation of return values. The description only covers prerequisites and usage timing, missing details on source/target objects and partition_config.
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 only 20%, with only 'columns' having a brief description. The description adds context for the aggregates parameter by listing the options, but source, target, and partition_config remain underspecified. Baseline 3 is appropriate as it adds some value but not enough.
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?
The description clearly states the verb 'Compare' and the resource 'column-level aggregates', specifying the aggregate functions. It distinguishes from sibling tools like run_row_count_check or run_schema_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (validate_table_exists, validate_columns_exist) and usage guidance ('After row counts match, to verify numeric data integrity'). It does not mention when not to use it, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool identifies mismatched rows, but does not state if it's read-only, permission requirements, or output format. Behaviour is adequately described for a check tool.
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?
The description is brief and front-loaded with the tool's purpose. Every sentence adds value, though the emoji and ALL CAPS could be removed without loss.
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?
With 5 parameters, no schema descriptions, and no output schema, the description is too sparse. It does not explain the structure of source/target objects, the role of columns, or how sample_size limits comparisons. An agent lacks sufficient information to use the tool correctly.
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 coverage is 0%; the description only mentions 'primary key' and 'actual row values' but does not elaborate on parameters like source, target, sample_size, or columns. Agents must infer parameter usage from names alone.
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?
The description clearly states the tool's purpose: 'Compare actual row values by primary key' for detailed validation after row counts and aggregates pass, distinguishing it from siblings like run_row_count_check and run_aggregate_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'USE: After row counts and aggregates pass' and a prerequisite: 'PREREQUISITE: validate_table_exists, know the primary key.' It lacks explicit alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the tool shows column differences and type mismatches, implying a read-only comparison. However, it lacks details on required permissions, error conditions, or whether changes are made. The behavior is adequately described for a comparison tool but not fully comprehensive.
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 description is concise at two sentences, with key information front-loaded using an emoji and bold text. Every sentence adds value: the first states the action and recommendation, the second explains the output and its importance. No wasted words.
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?
Given the tool has 8 parameters, no output schema, and zero schema descriptions, the description is too brief. It explains the high-level purpose but fails to specify the output format or how parameters relate to source/target identification. For a complex tool with many siblings, more detail is needed.
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 coverage is 0%, meaning the input schema has no parameter descriptions. The tool description does not explain any of the 8 parameters (e.g., source_datasource, target_schema), leaving the agent to infer from names alone. This is a significant gap that the description fails to fill.
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?
The description clearly states the tool's function: side-by-side comparison of source and target schemas to show column differences and type mismatches. It positions itself as the recommended first step before running data checks, distinguishing it from sibling tools like run_schema_check which execute actual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool BEFORE running data checks and as a recommended first step, providing clear context for when to use it. However, it does not mention when not to use or suggest specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Test connection' without disclosing behavioral traits such as whether it modifies anything, what happens on success/failure, or any side effects. For a test tool, likely read-only but not stated.
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?
Extremely concise: one sentence describing purpose plus a usage hint. No unnecessary words, perfectly front-loaded.
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?
Given only 1 parameter and no output schema, the description covers purpose and usage but lacks details on behavioral specifics (e.g., what 'test' entails, error handling). Adequate but could be more complete.
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%, and the parameter 'datasource_name' is already described as 'Name of the data source to test' in the schema. The description does not add any additional meaning beyond this, so baseline score of 3 applies.
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?
Description clearly states 'Test connection to a data source' which is a specific verb+resource. It distinguishes from sibling tools like add_datasource, remove_datasource, list_datasources, etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios: 'After adding a new data source, when user reports issues, or before starting reconciliation.' This gives clear context on when to use, though it doesn't explicitly list when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read-only preview operation ('Preview'), but does not disclose behavioral traits such as idempotency, authentication requirements, or error handling. The description is minimal but not misleading.
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 description is extremely concise: two sentences and a one-line usage directive. Every sentence earns its place with no redundancy. Front-loaded with the core purpose.
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?
For a tool with 5 parameters and no output schema, the description covers purpose and usage but lacks parameter details. It does not explain what the preview returns (e.g., column types, row format). However, given the tool's simplicity, it is minimally adequate.
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?
With 0% schema description coverage, the description should compensate by explaining parameters. It only mentions 'first N rows' correlating to the 'limit' parameter, but does not describe 'datasource_name', 'database', 'table', or 'schema'. The required parameters are self-explanatory, but the description adds no semantic value beyond the schema.
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?
The description clearly states 'Preview first N rows of a table', which is a specific verb+resource. It distinguishes from sibling tools like get_tables, get_table_schema, and run_sample_check by emphasizing verification and preview before expensive checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE: To VERIFY you found the correct table before running expensive checks. Show user what data looks like.' This provides clear when-to-use guidance, though it does not name alternative tools for the expensive checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It explains that the tool searches by pattern (substring match via example) but does not disclose details like case sensitivity, result limits, or behavior when no matches are found. The description is clear on usage but lacks comprehensive behavioral traits.
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?
The description is short and front-loaded with the critical usage note. It includes an emoji and all-caps emphasis, which are effective but slightly verbose. The example is useful. Overall, it communicates efficiently with minimal extra verbiage.
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?
Given the tool has 3 parameters, no output schema, and many siblings, the description covers the essential usage context. However, it lacks information about the return format (e.g., table names with schema details) and any limitations. This gap means the agent might not fully understand what to expect from the tool.
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 67% (pattern and database have descriptions, datasource_name does not). The description adds value through an example demonstrating pattern usage, but does not explain datasource_name or provide additional semantics beyond the schema. The baseline is 3 due to moderate schema coverage, and the description adds marginal value.
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?
The description clearly states the tool's purpose: 'Search for tables by name pattern.' It uses a specific verb ('search') and resource ('tables'), and distinguishes from siblings like get_tables (which lists all tables) and validate_table_exists (checks existence). The critical note reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'CRITICAL - USE FIRST when user mentions a table name' and 'NEVER assume table names exist - always search first.' It does not explicitly mention when-not-to-use or alternatives, but the priority instruction is strong and context from sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It states the tool lists all databases (read-only), but omits details like error handling, authentication needs, or output format.
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?
Two concise sentences front-load the purpose and usage hint. No redundant or irrelevant information.
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?
The description is mostly complete for a simple list tool with one parameter, but does not explain return value structure (e.g., list of names or objects), which would be helpful since no output schema exists.
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 100% for the single parameter. The description adds no extra semantic meaning beyond the schema's description of 'datasource_name'.
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?
The description clearly states 'List all databases in a data source' with a specific verb and resource, and adds an explicit use case hint to distinguish from siblings like 'get_tables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint (discover databases before listing tables), implying the tool is a precursor step. However, it does not explicitly mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Indicates write operation and post-use step, but lacks detail on side effects, failure modes, or permissions.
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?
Three sentences with no waste: main action, post-use instruction, config details. Front-loaded and efficient.
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?
Adequate for a registration tool with 3 required params and no output schema. Includes post-use step; could mention duplicate name handling or failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters; description adds specific config fields for MySQL and Snowflake, providing meaning beyond the generic 'connection configuration object'.
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?
Clear verb 'register' and resource 'database connection' with explicit types (MySQL or Snowflake), distinguishing from sibling tools like list_datasources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call test_datasource after use, but does not state when not to use or alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses polling behavior and the format of progress updates, which is transparent for a status-checking tool. Does not mention auth or side effects, but those are unlikely for a read-only status tool.
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?
Two sentences with no waste. First sentence states purpose, second provides actionable usage guidance. Every word earns its place.
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?
No output schema, but description indirectly specifies return fields via the example report. Suggests polling frequency. Lacks explicit return type and error handling, but for a simple status tool it is sufficiently complete given typical usage.
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?
Only parameter job_id is obvious and needs little explanation. Schema description coverage is 0%, but the description adds no extra detail about job_id (e.g., format or source). However, the tool context makes the parameter self-explanatory, so it's minimally adequate.
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?
Description explicitly states tool retrieves job progress (status, percent complete, current check). Verb 'Get' and resource 'job progress' are clear, distinguishing it from siblings like get_job_results or cancel_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on polling every few seconds while running and suggests a reporting template. Context is clear but no explicit exclusions or alternative tool names are given, though the polling instruction implicitly directs use during job execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description warns about potential slowness for large databases, a key behavioral trait. It also implies a full return scope. Slight lack of detail on output structure, but sufficient for transparency.
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?
Three concise, front-loaded sentences covering purpose, usage, and warning with no redundancy. Every sentence adds value.
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?
Given the tool returns a full metadata catalog with no output schema or parameter details, the description provides essential context (when to use, performance) but lacks specifics on return structure or exact behavior.
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 0% for the sole parameter 'datasource_name'. The description implies it identifies the data source but does not explain format or constraints. Partial compensation but not detailed.
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?
The description uses specific verb 'Get' and resource 'FULL metadata catalog (all databases, schemas, tables)', clearly distinguishing its broad scope from sibling tools like search_tables.
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 states when to use ('When starting with a data source') and when to prefer an alternative ('prefer search_tables for targeted queries'), providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive behavior: 'CAUTION: This deletes the configuration permanently.' This is critical for agent decision-making.
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 description is minimal (two sentences) with zero fluff. The caution is front-loaded for immediate agent attention.
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?
For a simple destructive operation with one parameter and no output schema, the description adequately covers purpose, behavior, and parameter. It could optionally mention undo or confirmation steps.
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 100%, so the baseline is 3. The description does not add meaning beyond the schema, but it contextualizes the parameter within the operation.
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?
The description clearly states the action ('Remove') and the resource ('a registered data source'). It distinguishes from sibling tools like 'add_datasource' and 'list_datasources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The caution about permanent deletion implies when to use (only when certain) and when not to use (if reusability is needed). However, it does not explicitly compare to alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It correctly identifies the tool as listing data sources (a read operation), which is transparent. No behavioral traits beyond listing are needed, though a mention of non-destructiveness would improve it.
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 description consists of two concise sentences. The purpose is stated first, followed by crucial usage guidance. No word is wasted.
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?
For a zero-parameter, no-output-schema tool, the description covers the purpose, usage context, and referral to a sibling. It is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters with 100% schema coverage, so the baseline is 4. The description adds no parameter info, which is acceptable since there are no parameters.
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?
The description clearly states 'List all registered data sources.' with a specific verb and resource, and it distinguishes itself from sibling tools like add_datasource, remove_datasource, and test_datasource.
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?
The description explicitly indicates this is the 'FIRST STEP' and advises what to do if the list is empty: 'guide user to add data sources with add_datasource.' This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![data-recon-mcp MCP server](https://glama.ai/mcp/servers/hindocharaj1997/data-recon-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hindocharaj1997/data-recon-mcp)

Score Badge

Copy to your README.md:

[![data-recon-mcp MCP server](https://glama.ai/mcp/servers/hindocharaj1997/data-recon-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hindocharaj1997/data-recon-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hindocharaj1997/data-recon-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server