erp-report-engine
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool targets a distinct action: describe_model provides metadata, weekly_report generates a KPI briefing, reconcile verifies counts, aging produces a specific receivables report, check_query validates SQL, and query runs read-only queries. There is no overlap in purpose.
Naming Consistency2/5Tool names follow inconsistent patterns: describe_model and check_query use verb_noun, weekly_report and aging are nouns, while reconcile and query are bare verbs. The lack of a uniform convention makes it less predictable which names are actions versus report objects.
Tool Count5/5Six tools is well-scoped for an ERP report engine, covering schema discovery, query execution, validation, reconciliation, and two standard reports without unnecessary bloat or thinness.
Completeness4/5The server covers metadata, generic querying, SQL validation, data reconciliation, and two specific report types. While additional standard ERP reports could be included, the generic query tool provides a path to access any data, so the surface is fairly complete.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 87 commits in the last 12 weeks
- Last stable release on
- 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.
This server has been verified by its author.
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 carries full responsibility for disclosing behavioral traits. It mentions the action but does not state whether this is read-only, whether it modifies data, what it returns (e.g., a report, pass/fail), or how mismatches are handled. This is a significant gap for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the tool's function without unnecessary words or repetition. It is front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero parameters) and has no output schema, so the description could be minimal, but it omits the outcome or result format. It does not say what the reconciliation produces (e.g., a report, a status), which would be helpful for the agent to know what to expect after invocation. This makes it slightly incomplete but acceptable for a basic validation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so schema coverage is vacuously 100%. The baseline for zero parameters is 4, and the description adds no parameter-specific information because none is needed. It provides the tool's purpose without needing to describe arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Reconcile') with a defined resource ('each entity's fetched row count') and method ('against an independent COUNT(*) of the source'). This distinguishes it from sibling tools like query and check_query, which focus on data retrieval, not validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only says what it does, not the context (e.g., after running a sync) or why it should be used instead of check_query or query. The user is left to infer that reconciliation is a validation step.
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 burden of behavioral disclosure. It does disclose some behavior by mentioning a 'data-quality gate', 'source reconciliation', and 'SQL audit trail', implying that the tool validates data and tracks lineage. However, it does not state whether the operation is read-only, requires special permissions, or has side effects, leaving important safety and execution context unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core concept ('weekly KPI briefing') and then lists relevant components. There is no filler or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides a reasonably complete picture: it states the cadence, the deliverable type, and the main built-in features. It could offer more detail about the exact output shape or behavior on data-quality failure, but it is sufficient for basic invocation understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to clarify about parameter usage. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'the weekly KPI briefing' and lists its key components (findings, data-quality gate, source reconciliation, SQL audit trail), making its purpose clear. It lacks an explicit verb like 'generates' or 'retrieves', but the noun phrase is specific enough and distinguishes it from the sibling query/reconcile tools by its weekly-report scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as query or reconcile. It does not mention intended scenarios, prerequisites, or exclusions, so the agent is left to infer usage from the name and brief 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 provided, the description carries the burden of behavioral disclosure. It does disclose the output contents and the empty condition, which is useful. However, it does not state whether the tool is read-only or any other operational characteristics beyond the result details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and provides a compact list of what the tool returns. There is no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless report with no output schema, the description adequately covers what the tool returns and the key empty condition. It could optionally specify the aging buckets or time range, but the current description is sufficient for basic understanding and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. Per guidelines, the baseline for 0-parameter tools is 4, and there is no need for the description to explain parameters. The description adds no param details but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Receivables aging' and specifies exactly what it provides: open balances by days past due, overdue share, and top overdue customers. This verb+resource structure is specific and distinguishes it from siblings like 'query' or 'reconcile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions the output is empty if the profile has no receivables, but that is a conditional outcome, not usage direction. There are no explicit exclusions or alternative references.
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 explicitly discloses 'read-only', which is a key safety trait. It also scopes queries to 'canonical entities', setting expectations about the data model. However, it omits potential side effects, permission requirements, or query constraints beyond the schema defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and purpose. It avoids unnecessary detail and is highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and read-only nature, but lacks usage alternatives, parameter details, and differentiation from sibling check_query. With no output schema or annotations, it leaves the agent to infer important context like what 'canonical entities' are and whether any query limitations apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no additional meaning for the 'sql' or 'max_rows' parameters. While the parameter names are self-explanatory, the description does not clarify the SQL dialect, the nature of canonical entities, or how max_rows behaves, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a read-only SELECT/WITH query over canonical entities and returns rows. The verb 'Run' paired with a specific query type and target resource thoroughly distinguishes it from report-oriented siblings like weekly_report and describe_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for ad-hoc data retrieval with read-only SQL, but it does not explicitly state when to use this tool over alternatives like check_query, nor does it provide exclusions. The role of 'canonical entities' is left undefined, weakening contextual guidance.
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 must carry the burden of behavioral disclosure. It explicitly states the tool does not run the SQL, which is a key safety trait. However, it does not explain what the tool returns or what happens on failure, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers the essential purpose and key constraint ('without running it') with zero wasted words. It is an ideal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core purpose and non-execution behavior. However, it omits what the check returns (e.g., boolean, pass/fail message), which is important for an agent to interpret results. This leaves a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only mentions 'a SQL statement', which simply restates the parameter name 'sql' and adds no detail about expected format, examples, or constraints. This fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a SQL statement against a read-only guard without executing it. This specific verb-resource pairing distinguishes it from sibling tools like 'query', which presumably runs the SQL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without running it' clearly contrasts with the sibling 'query' tool, implying this is a safe pre-check before executing. However, it does not explicitly state when to use this over alternatives or provide exclusions, so it stops short of a full 5.
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 full burden. It indicates a read-only listing operation, but it does not disclose any limitations or context about the active profile beyond its existence. For a simple informational tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb, and no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description sufficiently communicates the return values (canonical entities, columns, active profile). It could explicitly state its role in query preparation, but it is complete for a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description adds value by explaining what the tool outputs rather than parameters. This meets the baseline for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly states the resource being described: canonical entities, columns, and active profile. This clearly distinguishes it from sibling query/report 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to discover the queriable data model before writing queries, but it does not explicitly mention when to use it versus siblings like query or check_query. Clear context, but no exclusions.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gulmezeren2-byte/erp-report-engine'
If you have feedback or need assistance with the MCP directory API, please join our Discord server