Elorus MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity (invoices, contacts, expenses, cash receipts, products) and action (list vs get). The list tools return summaries with filters, while get tools return full records by ID, so there is no overlap or ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: list_<plural> and get_<singular> (e.g., list_invoices, get_invoice). The naming is uniform, lowercase, and predictable.
Tool Count5/5
With 10 tools covering 5 core entities via list/get pairs, the tool count is well-scoped. Each tool earns its place and there is no redundancy or bloat.
Completeness2/5
The server is entirely read-only, providing only list and get operations. There are no create, update, or delete tools for any entity, which is a significant gap that prevents agents from performing common accounting workflows like creating invoices or modifying contacts.
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- 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?
Since no annotations are provided, the description must carry the burden of behavioral disclosure. It only mentions 'complete record' without explaining error behavior (e.g., if ID not found), authentication requirements, or response format. The description is too sparse to convey behavior beyond the basic read operation.
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, direct sentence that immediately states the verb and resource. It contains no unnecessary words and 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?
For a simple getter with no output schema and no annotations, the description is incomplete. It says 'complete record' but does not explain what fields are included, nor does it address error handling or the behavior when the ID does not exist. This leaves significant gaps for an agent relying solely on the description.
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 provides only a type and name for the single parameter 'expense_id' with no description. The description adds the context that it is an 'Elorus ID', clarifying the identifier type, but does not provide format constraints or further elaboration. This adds some meaning 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 the tool's function with a specific verb 'Get' and resource 'expense', specifying it retrieves a single expense by its Elorus ID. This effectively distinguishes it from sibling tools like 'list_expenses' which lists multiple records.
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 the tool should be used when a single expense record is needed given an ID, but it does not explicitly mention alternatives or exclusions. It doesn't say 'instead of list_expenses' or address when not to use it, so usage guidance is only implied rather than explicit.
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 only says 'Get the complete record', which hints at the return value but omits details like error handling, authentication, or what 'complete record' entails. This is insufficient without annotation support.
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 with a clear verb and object, front-loaded with the action. 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?
The tool is simple with one parameter and no output schema. The description states the tool's purpose and ID type, but without an output schema, it should better describe what 'complete record' returns. It covers the basics but leaves some ambiguity.
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 description for cash_receipt_id (0% coverage), but the description clarifies that the ID is the 'Elorus ID', providing meaningful context beyond the parameter name. However, it lacks format examples or further elaboration, so it only partially compensates for the schema gap.
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: retrieving a single cash receipt by its Elorus ID. It uses a specific verb ('Get') and resource ('cash receipt'), and the scope ('single') distinguishes it from list_cash_receipts.
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 phrase 'single cash receipt by its Elorus ID' implies this is for looking up one specific receipt, while list_cash_receipts would be for multiple. However, it does not explicitly name alternatives or state when-not-to-use, so it stops short of a 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?
With no annotations, the description carries the full burden. It discloses that the tool returns the 'complete record', which conveys the nature of the response. It does not address error handling, permissions, or rate limits, but for a simple read operation this is acceptable though not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It precisely states the action, the resource type, and the identifier used, earning full marks for conciseness.
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 retrieval tool, the description covers the purpose and the parameter semantics adequately. It notes the result is a 'complete record' and identifies the ID type. It does not describe output schema or error conditions, but the simplicity of the operation and existing sibling context make this sufficient.
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 provides only a generic property name 'Invoice Id' with zero description coverage. The description compensates by clarifying that 'invoice_id' is the 'Elorus ID', giving essential semantic meaning and making the parameter unambiguous.
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 'Get' and identifies the exact resource: 'complete record of a single sales invoice'. It also specifies the identifier used ('Elorus ID'), clearly distinguishing this single-record retrieval tool from the sibling 'list_invoices' tool.
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 usage when you already have an Elorus ID for an invoice and need the full record. However, it does not explicitly state when to use this tool instead of list_invoices, nor does it mention any exclusions or 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 carries the full burden and does disclose that it is a read operation returning a complete record. However, it omits details about error handling, required permissions, or pagination/return structure, which leaves behavioral uncertainty.
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, well-structured sentence with no filler. It front-loads the action and object and gives the key qualifying detail (Elorus ID) efficiently.
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 get-by-ID tool with no output schema, the description is adequately complete: it identifies the resource, the identifier type, and the result scope ('complete record'). It does not cover edge cases or return format, but the tool's simplicity makes this acceptable.
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 only parameter product_id has no schema description, but the description adds that it is an 'Elorus ID' and applies to both products and services. This provides domain-specific meaning beyond the property title 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 identifies the action ('Get'), the resource ('product or service'), and the scope ('single ... by its Elorus ID'). This distinguishes it from sibling tools like list_products, making its purpose unambiguous.
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 usage when you already have an Elorus ID and need the complete record, but it does not explicitly state when to prefer this over alternatives like list_products. There is no when-not guidance or mention of 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 of behavioral disclosure. It states the operation is a read ('Get') and promises the 'complete record', but it doesn't disclose edge cases such as not-found behavior or authentication requirements. The disclosure is adequate for a simple read but lacks depth.
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 starting with the action verb 'Get'. It contains no filler and communicates the entire purpose efficiently.
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 retrieval tool with one parameter and no output schema, the description covers the essential function. It could be enhanced by describing the response structure or error behavior, but the core purpose and invocation are clear.
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 schema offers only the parameter name 'contact_id' with no description (0% coverage). The description compensates by explaining the parameter is the Elorus ID, giving it essential semantic meaning beyond the raw 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 uses the specific verb 'Get' and identifies the resource as a contact, clarifying it retrieves a single record by its Elorus ID. This clearly differentiates it from sibling tools like list_contacts, which retrieve collections.
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 phrase 'by its Elorus ID' clearly indicates the tool is for when you have a specific contact ID, providing clear context for use. It does not explicitly name alternatives like list_contacts, but the purpose distinction is strongly implied.
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 discloses important behaviors: period_from/period_to only apply when both are given, and the return shape is {count, page, results}. It also notes that the result contains summary fields. This goes beyond simple 'list' and gives the agent actionable expectations.
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 compact and well-organized: a one-sentence purpose followed by a clear bullet list of filters and a return note. Every sentence adds value with no redundancy.
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 6-param list tool with no annotations or output schema, the description covers the essential aspects: filter behavior, output structure, and pointer to get_expense if full records are needed. It could mention pagination details or ordering, but the defaults in the schema cover some of that gap.
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%, so the description must carry the burden. It explains the date range format and conditional behavior, supplier as an Elorus contact ID, and search as free-text. It omits page/page_size semantics, but those are self-evident from their names and defaults, so the coverage is strong.
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 lists expenses (purchase documents) with summary fields, and differentiates from siblings by directing to get_expense for full records and mentioning supplier lookup via list_contacts. The verb 'List' and resource are specific and unambiguous.
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 clear context for when to use this tool (listing expenses) and gives alternative guidance: use get_expense for full record, find supplier with list_contacts. It does not explicitly state 'when not to use' but the alternative pointers serve as exclusions for related tasks.
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 provided, the description carries the full burden. It discloses the return shape ({count, page, results}), filter behavior including the both-dates rule, and the distinction from get_cash_receipt. It does not explicitly describe pagination behavior for page/page_size, but the mention of 'page' in the return structure hints at 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 is concise and well-structured: a one-line purpose, a bulleted filter list, and a note about the return format and alternative tool. Every sentence adds value; no redundancy.
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 list tool with 7 parameters and no output schema, the description covers the purpose, filters (including transaction type codes), return format, and the path to full records. It lacks explicit mention of pagination semantics, but overall it is sufficiently complete for a straightforward listing endpoint.
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%, so the description must compensate. It explains five of the seven parameters in clear detail (period_from/to, contact, invoice, transaction_type with code meanings). However, page and page_size are not described beyond their existence in the schema; they are left to inference, though they have defaults.
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: 'List cash receipts (payments received) with summary fields.' It distinguishes itself from sibling tools like get_cash_receipt by noting that it returns summary fields and full records are obtained via the sibling.
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?
It provides explicit guidance on when to use this tool versus getting full details ('use get_cash_receipt for the full record'). It also details the filter application rule ('period_from / period_to ... only applied when BOTH are given'), which is a usage prerequisite.
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 transparency burden. It discloses the return shape (count, page, results), filter behavior, and summary-field scope. Minor gaps: doesn't specify default behavior when filters are null (e.g., active=null), but overall good for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose first, then filters, then return value and alternative. Every sentence adds value, no redundant detail.
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?
Given no output schema, the description provides reasonable completeness: lists filters, return shape, and points to get_contact for full details. Could mention sorting or null-filter behavior, but for a list endpoint with optional filters, it's largely sufficient.
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?
Description adds meaningful semantics for search, contact_type, and active beyond the schema (which has no property descriptions). It also hints at pagination via return shape. Page and page_size are not explicitly explained, but their defaults and names in the schema make them self-evident.
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 lists contacts (clients and suppliers) with summary fields, using a specific verb and resource. It distinguishes itself from get_contact by noting summary fields vs full record.
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?
Provides explicit instructions on filters and their semantics (search, contact_type, active), and explicitly directs users to get_contact for full records. This clearly differentiates when to use this tool vs an alternative.
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?
Given no annotations, the description takes on the responsibility of exposing behavior. It discloses that it returns summary fields, lists filters, and specifies the return shape. However, it does not clarify behavior with null filter defaults or pagination parameters, leaving some 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 concise and well-structured, with a clear first sentence, a concise filter list, and a return-spec line. No wasted 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 list tool with 6 parameters and no annotations or output schema, the description covers the core behavior well: purpose, filters, return shape, and pointer to the full-record alternative. It lacks explicit mention of pagination semantics, but the schema covers it.
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%, so the description compensates by explaining each filter: 'search: free-text search (title, code, ...)', 'active: True = active items, False = archived', etc. It does not explicitly explain page/page_size, but these are self-explanatory from names. The return shape is mentioned.
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 products and services with summary fields.' It uses a specific verb and resource, and explicitly distinguishes from the sibling tool 'get_product' by noting 'use get_product for the full record.'
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?
It provides explicit guidance on when to use this tool versus an alternative: 'use get_product for the full record.' It also explains each filter's purpose, giving clear context for how 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses filter behavior (e.g., period range only applied when both are given), the boolean semantics, and the return shape {count, page, results}, making the tool's behavior transparent.
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 well-structured with a one-line overview followed by a neatly formatted filter list. Every sentence provides essential information and no redundancy, making it highly efficient.
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?
Given 11 parameters, no annotations, and no output schema, the description thoroughly documents all key filters, return format, and pagination-related behavior. It covers all necessary aspects for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the meaning of all filter parameters including status values, boolean logic for paid/draft/overdue, the client ID lookup, and ordering syntax. This exceeds the schema's bare names and types.
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 lists sales invoices with summary fields, and explicitly distinguishes itself from get_invoice for full details. This makes the purpose specific and differentiates it from the sibling.
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 says to use get_invoice for full details, providing a clear alternative. It also elaborates on filter semantics, giving the agent context on when to apply each parameter.
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:

[![Elorus-ERP-MCP-Server MCP server](https://glama.ai/mcp/servers/gabrielnika/Elorus-ERP-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/gabrielnika/Elorus-ERP-MCP-Server)

Score Badge

Copy to your README.md:

[![Elorus-ERP-MCP-Server MCP server](https://glama.ai/mcp/servers/gabrielnika/Elorus-ERP-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/gabrielnika/Elorus-ERP-MCP-Server)

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/gabrielnika/Elorus-ERP-MCP-Server'

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