data-engineering-mcp

by paul-92

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource and action, but 'gerar_sql' and 'gerar_select' overlap as SELECT generators, and 'inferir_relacionamentos' versus 'gerar_join' both propose relationship candidates. Descriptions help resolve ambiguity in most cases.
Naming Consistency4/5
The set follows a strong snake_case verb_noun pattern like listar_tabelas, buscar_coluna, and descrever_tabela. 'status_catalogo' is a minor deviation since it is noun-first rather than verb-first, but the rest is consistent.
Tool Count5/5
Twelve tools is well-scoped for a data engineering catalog server. Each tool covers a meaningful operation around catalog metadata, schema exploration, relationship inference, and SQL generation without redundancy.
Completeness4/5
The tool surface covers catalog refresh, table/column search, schema description, relationship inference, path finding, and SQL generation/explanation. Minor gaps exist, such as no explicit tool for listing all columns of a table independently or managing relationship confidence thresholds, but core workflows are covered.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description must carry the full burden of behavioral disclosure. It does state that it does not execute SQL, which is a useful behavioral trait, but it omits other important details such as required schema context, potential errors, or limitations. The covered behavior 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but severely under-specified. It lacks necessary elaboration and structure, making it closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain generated SQL structure, parameter usage, or any nuances, making it impossible for an agent to use it correctly based on the description alone.
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%, so the description must compensate. It provides no information about the parameters (tabelas, colunas, filtros, permitir_baixa_confianca), their purpose, or how they map to the SQL generation. This leaves the agent without any guidance beyond the raw schema.
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 states it generates a structural, parameterized Oracle SELECT without executing SQL, which is a specific verb+resource. However, it does not differentiate from the sibling tool 'gerar_select', which likely has overlapping functionality, so it lacks 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to prefer this tool over gerar_select, gerar_join, or others, nor any exclusions or alternative suggestions.
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 alone must convey behavioral traits. It only states the tool finds paths with a confidence filter, but it does not disclose whether the operation is read-only, what the output structure represents, whether it mutates data, or any side effects. The presence of an output schema does not surface in the description, leaving behavior largely undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is not structured to maximize informativeness. It front-loads the core action but omits essential context. While brevity is valued, the sentence does not earn its place by conveying all necessary details; it could be expanded with usage guidance or parameter hints.
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 2 required parameters and an output schema, but the description does not explain how the output relates to the input, what the confidence levels imply, or how the tool integrates with the catalog system. The description leaves out crucial details that an agent would need to call the tool correctly, such as whether the path is directed, what 'best' means in terms of ranking, or if there are any constraints on the tables.
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 coverage is 0%, meaning the schema provides no descriptions for 'tabela_origem' and 'tabela_destino'. The description does not clarify the expected format, constraints, or semantics of these parameters beyond their names. It merely implies they are tables, but does not explain how they should be specified (e.g., exact table names, case sensitivity) or what 'path' means in their context.
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 states a clear action (finds best candidate relationship paths) and a specific filtering criterion (confidence MEDIUM or HIGH). The verb 'encontra' and resource 'caminhos de relacionamentos candidatos' are explicit, and the confidence filter adds precision. However, it does not distinguish itself from sibling tools like 'inferir_relacionamentos', which may also identify relationships, so it is not fully differentiated.
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 offers no guidance on when to use this tool versus alternatives such as 'inferir_relacionamentos' or 'gerar_join'. It does not mention prerequisites, scope, or any conditions that would lead an agent to prefer this tool. This is a significant omission given the overlapping 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 are provided, so the description bears full responsibility for disclosing behavior. It only says 'describes' which implies a read operation, but it does not explicitly state that it performs no modifications, nor does it describe the output format or any side effects. This leaves the agent guessing about safety and return value.
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 a single, concise sentence that immediately states the core purpose. It is front-loaded and efficient, containing no redundant wording. However, it is so brief that it barely covers the essentials, but conciseness itself is handled well.
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 (one parameter, no output schema, no annotations), the description is still incomplete. It does not say what the agent will receive as output, whether it returns the table's metadata, or anything about the file and sheet handling. An agent could not fully understand the tool's behavior from this description alone.
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 schema has a single required string parameter 'tabela' with zero description coverage. The tool description adds no meaning about what values are valid, what format the table name should have, or how it relates to the file/sheet context. With a 0% schema coverage, the description was expected to compensate but does not.
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 states a specific verb ('descreve' – describes) and a clear resource ('tabela' – table), plus the scope of description: file, sheet, and headers. This is distinct from siblings like listar_tabelas (list tables) and buscar_coluna (search column). However, it does not explicitly differentiate itself from those siblings, so it earns a 4 rather than a 5.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. No context is provided about when this should be preferred over listar_tabelas or buscar_tabelas.
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 the full burden. It does disclose a key behavioral trait: the tool does not execute SQL, which prevents an agent from assuming side effects. However, it says nothing about whether it validates the table exists in the catalog, what it returns (a string?), or error behavior. It's a bare minimum disclosure.
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 a single, front-loaded sentence that states the core purpose and a key caveat. There is no redundancy or preamble. However, its extreme brevity borders on under-specification, costing some points for structure, but it remains highly concise.
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 two parameters, zero schema descriptions, and no output schema, the description is incomplete. It doesn't clarify what the generated SELECT looks like, whether it includes a WHERE clause, or how colunas is used. An agent would likely need to inspect the schema or guess, which is risky.
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 two parameters. 'tabela' is required but its meaning is only implied by the tool name; 'colunas' is optional but the description never explains what it does (e.g., specify columns to select, default to *). The description fails to compensate for the schema's lack of property descriptions.
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 states a clear verb ('Gera' / generates), a specific resource ('SELECT Oracle simples de uma tabela'), and crucially adds that it does not execute SQL. This distinguishes it from siblings like gerar_sql or explicar_sql. An agent can immediately understand what this tool does and what it doesn't.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention conditions like 'use when you need a basic SELECT without running it' or exclude cases like joins or complex queries. The existence of siblings such as gerar_join and gerar_sql implies some selection criteria, but none are stated.
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?
With no annotations provided, the description must disclose all behavioral traits. It does mention one negative behavior ('sem afirmar chave estrangeira'), which is useful, but it omits other critical aspects: whether the operation is read-only, what the output format is, or any side effects. The burden of transparency is not met.
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 a single, concise sentence that front-loads the core purpose and adds a key caveat. Every word earns its place—there is no fluff or redundancy. It is appropriately sized for a tool with only two scalar parameters.
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 tool with no output schema, the description explains what the tool does but fails to state what it returns (e.g., the structure or form of the proposed JOIN). It also does not mention whether the join is based on a fuzzy match, naming convention, or something else. The lack of output schema makes the return format a significant omission, though the purpose is established.
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?
The input schema has 0% description coverage, so the description must compensate. It confirms that the tool works with two tables, matching the two parameters, but it does not explain the roles of origem and destino beyond their self-explanatory names. The names 'tabela_origem' and 'tabela_destino' are semantically clear on their own, so the added value is minimal but not absent.
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 the specific verb 'Propõe' (proposes) and identifies the resource as a direct candidate JOIN between two tables. The phrase 'sem afirmar chave estrangeira' explicitly distinguishes it from a tool that asserts foreign keys, which sets it apart from sibling tools like inferir_relacionamentos. This is clear and differentiated.
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 no guidance on when to use this tool versus alternatives. It neither names sibling tools nor states any conditions, prerequisites, or exclusions. The only implied context is that it suggests a join without foreign key confirmation, but this is not framed as actionable guidance.
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 carries the full behavioral disclosure burden. It adds a useful behavioral trait by stating the listing is 'deterministicamente' and scoped to 'tabelas lógicas', but it does not explicitly state side effects, permissions, or whether the operation is read-only, though 'Lista' implies non-mutating.
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 a single sentence with no filler. The core action, resource, and determinism guarantee are all front-loaded, making it efficient and easy to process.
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 output schema covers return values and the zero-parameter schema keeps invocation simple, so those are not gaps. However, the lack of annotations and the presence of several sibling tools mean the description does not fully establish when to choose this tool or what 'tabelas lógicas' means relative to other catalog views.
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 input schema has zero properties and 100% schema description coverage, so there are no parameter semantics for the description to clarify. This matches the baseline for no-parameter tools.
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 uses a specific verb, 'Lista', and a clear resource, 'tabelas lógicas do catálogo local', so an agent knows what the tool does. It does not explicitly differentiate this tool from the sibling 'buscar_tabelas', so it falls short of full sibling distinction.
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?
There is no guidance on when to use this tool versus the alternatives like buscar_tabelas, status_catalogo, or inferir_relacionamentos. The intended usage must be inferred solely from the tool name and the one-line description.
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 must carry the behavioral disclosure burden. It usefully reveals that matching is exact and case-insensitive, but it does not state whether the search is read-only, what happens with no or multiple matches, or how results are scoped. The output schema covers return structure, but other behavioral traits remain unstated.
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?
A single sentence with no filler: the action is front-loaded and the only qualifier included ('sem diferenciar maiúsculas/minúsculas') is directly relevant to how the tool should be invoked. 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?
For a one-parameter lookup tool, the description plus the input/output schemas cover the essential contract. It omits usage guidance and edge-case behavior, but those are less critical given the tool's simplicity and the existence of an output schema.
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 coverage is 0% and the 'coluna' property has only a type/title, so the description carries the semantic weight. It clarifies that the parameter is the target column for an exact, case-insensitive search. An example or note about whether wildcards are accepted would strengthen it, but the core meaning is conveyed.
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 states a specific action ('Busca') and a clear resource ('uma coluna'), with an 'exata' qualifier that defines exact-match behavior. It is easy to distinguish from the table-level siblings (listar_tabelas, buscar_tabelas, descrever_tabela) even though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The exact/case-insensitive wording implies a lookup use case, but there are no explicit when-to-use conditions, exclusions, or references to sibling tools.
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 carries the full burden, and it does disclose key behavioral traits: search is partial and case-insensitive on table names. It does not mention whether the operation is read-only or how results are returned, but the output schema is present and the behavior is meaningfully specified.
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?
A single, focused sentence that clearly expresses the tool's behavior without unnecessary words or repetition. It is front-loaded and easy to parse.
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 one-parameter search tool with an output schema, the description covers the core behavior. However, it lacks any sibling differentiation or usage context, which an agent would need to decide between this and listar_tabelas/buscar_coluna.
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?
The schema has no parameter descriptions (0% coverage), and the description implies that 'termo' is the partial search string used against table names. It adds some meaning beyond the schema but does not explicitly define termo or its expected format.
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 states a specific verb ('Busca') and resource ('nome das tabelas'), plus matching semantics (partial, case-insensitive). This makes the tool's purpose clear, though it does not explicitly contrast it with sibling tools like listar_tabelas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives such as listar_tabelas or buscar_coluna. The intended usage is only indirectly inferred from the name and description.
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 the behavioral burden. It usefully discloses that the tool does not execute the SQL, which signals a safe, read-only behavior, and 'conservadoramente' suggests cautious, non-overreaching explanations. However, it does not describe what kind of explanation is returned or how unsupported queries are handled.
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 a single, front-loaded sentence with no filler. Every word adds meaning: the verb, the scope ('SELECT/WITH'), the cautious behavior ('conservadoramente'), and the safety constraint ('sem executá-la').
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 tool is simple with one parameter, so the input side is adequately covered. However, there is no output schema, and the description does not explain what the explanation looks like or what information it will contain, leaving the return value somewhat underspecified for an agent.
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?
The input schema only shows a single 'sql' string parameter with no description. The tool description adds meaning by restricting valid input to SELECT/WITH queries, which is valuable. Still, it does not explain expected format, dialect, or whether multiple statements are allowed.
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 uses a specific verb ('Explica') and a specific resource ('consulta SELECT/WITH'), and adds a key constraint: 'sem executá-la'. This clearly distinguishes it from SQL-generating siblings like gerar_sql and gerar_select, though it does not explicitly contrast itself with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Explica conservadoramente uma consulta SELECT/WITH' implies the tool is for understanding a read-only query without running it, but it does not explicitly say when to prefer this tool over alternatives or when not to use it. Usage context is present but only implied.
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 the behavioral burden and it does disclose the main behaviors: rescanning, schema-change detection, and relationship recalculation. However, it does not state side effects, whether the operation is destructive, whether it persists changes, or what happens when schema changes are actually detected.
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 a single sentence with three concise action clauses and no filler. It is easy to scan and every clause adds meaningful information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is adequate but not complete: there is no output schema, yet the description does not say what the tool returns or confirms after running. It also omits prerequisites, failure modes, and any operational context about when a catalog refresh is appropriate.
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 input schema has zero parameters and schema coverage is 100%, so no parameter documentation is necessary. The zero-parameter baseline applies, and the description adds no parameter context, which is acceptable here.
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 states a clear action on a resource: rescan the XLSX, detect schema changes, and recalculate relationships. This goes beyond the generic tool name and helps distinguish it from siblings like listar_tabelas or status_catalogo, though it does not explicitly contrast itself with inferir_relacionamentos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, but the word 'Revarre' and 'detecta mudanças de schema' imply it is a refresh operation meant to be run after the XLSX source has changed. It does not name conditions, alternatives, or exclusions.
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 the full burden. It does disclose a key behavioral trait: the inference is based 'somente por metadados', not on data contents. However, it does not explicitly confirm that the operation has no side effects, nor does it mention any permissions or rate limits, leaving some behavioral 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 a single, front-loaded sentence with no filler. It states the action and the key qualifier ('somente por metadados') in the minimum necessary words.
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 zero-parameter tool with an output schema, the description is largely complete: it identifies the result and the inference basis. It could be slightly more complete by saying whether the tool also persists/publishes these relationships, but the verb 'Retorna' and the existing output schema cover the core invocation needs.
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 zero parameters, so there is no parameter semantics burden. The phrase 'somente por metadados' adds meaning by explaining why no user input is needed: the operation works on metadata already available in the catalog. This satisfies the baseline for a no-parameter tool.
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 uses a specific verb ('Retorna') and a specific resource ('relacionamentos candidatos inferidos somente por metadados'), making it clear what is returned. It does not explicitly contrast with sibling tools like encontrar_caminho or gerar_join, but the 'candidate relationships from metadata only' scope distinguishes it from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when the agent needs candidate relationships derived from metadata. However, it gives no explicit context, no exclusions, and does not mention alternative sibling tools, so an agent must infer usage from the purpose statement alone.
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?
There are no annotations to rely on, so the description must carry the behavioral burden. The verb 'Informa' implies a read-only status report rather than a mutation, which is useful, but the description does not explicitly state that no changes are made, nor does it disclose response details or potential slow operations.
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 a single, short sentence that front-loads the purpose and contains no filler. Every word contributes meaning, making it highly efficient.
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 tool is simple with no parameters, but there is no output schema and no annotations, so the description must explain the return value. It mentions statistics and timestamp at a high level but not which statistics or the exact format, leaving some ambiguity for an agent interpreting the response.
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 zero parameters, so the baseline is 4. The description correctly indicates the informational output (statistics and timestamp) without needing to document parameter meanings. No parameter-related gap exists.
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 the specific verb 'Informa' with the resource 'catálogo' and specifies what is reported: statistics and timestamp. This clearly distinguishes it from sibling tools like listar_tabelas or atualizar_catalogo, which have different operations on the catalog.
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 states what the tool does but gives no guidance on when to prefer it over alternatives, no exclusions, and no context such as 'use when you need catalog health'. With 11 sibling tools, the absence of any routing signal forces the agent to infer usage solely from the verb.
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-engineering-mcp MCP server](https://glama.ai/mcp/servers/paul-92/data-engineering-mcp/badges/card.svg)](https://glama.ai/mcp/servers/paul-92/data-engineering-mcp)

Score Badge

Copy to your README.md:

[![data-engineering-mcp MCP server](https://glama.ai/mcp/servers/paul-92/data-engineering-mcp/badges/score.svg)](https://glama.ai/mcp/servers/paul-92/data-engineering-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/paul-92/data-engineering-mcp'

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