protheus-mcp-server (piloto)

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 business entity or operation: customer balance, credit limit, payment conditions, various MRP entities (products, stock, warehouses, purchase requests, orders), payroll, and clients by seller. No two tools overlap in purpose; descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow the pattern 'protheus_<entity>_<specifier>' with underscores and consistent use of Portuguese nouns. The naming is predictable and uniform, making it easy to infer functionality from the name.
Tool Count5/5
With 10 tools covering financial, MRP, HR, and sales domains, the count is well-scoped for a pilot consultation server. Each tool serves a clear purpose without bloat or redundancy.
Completeness4/5
The tool set provides essential read-only consultations across multiple ERP modules (financial, MRP, HR, sales). Minor omissions exist, such as a general customer list or inventory movements, but given the pilot nature, coverage is adequate for common queries.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits 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 provided, the description must fully disclose behavioral traits. It mentions that the database might be empty, which is useful, but fails to disclose other important aspects such as auth requirements, rate limits, or potential side effects. The basic read behavior is implied but not explicitly stated.
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 very concise at two sentences, with no filler. It uses a clear structure: first sentence states the overall purpose, second sentence explains the two modes. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description should provide more context. It does not describe the return format, pagination behavior, or what fields are available. The note about an empty database is helpful, but overall the agent is left with gaps in understanding the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100% and all parameters are documented in the schema, the description does not need to add much. It does note that branchId and product are used together for a specific product, which aligns with the schema but adds no new semantics beyond what is already in the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults MRP products and specifies the two modes (list all vs. single product), making the purpose unmistakable. However, it does not differentiate from sibling tools like protheus_saldo_estoque_mrp, which also deal with MRP data.
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 explains when to use the tool with or without parameters, but it does not provide guidance on when not to use it or mention alternative tools for similar queries. This leaves the agent without exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it only states that the tool returns a list or a specific client, with no disclosure of read-only behavior, authentication requirements, rate limits, or other side effects. For a query tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential behavior. It is front-loaded with the main purpose and condition. Minor improvement could be splitting into two sentences for clarity.
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 query tool with 5 optional parameters and no output schema, the description explains the list vs specific behavior but does not cover pagination, sorting, or return format. The schema descriptions fill some gaps, but overall completeness is adequate but could be improved.
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 covers 100% of parameter descriptions (e.g., 'Número da página (opcional)'), so the description adds no additional semantic meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Consulta' (consult) and the resource 'limite de crédito dos clientes' (client credit limit). It also distinguishes the behavior based on whether internalId is provided (list vs specific client), which differentiates it from sibling tools like protheus_saldo_cliente and protheus_condicoes_pagamento.
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 for querying client credit limits, but does not explicitly state when to use this tool versus alternatives like protheus_saldo_cliente or protheus_clientes_por_vendedor. No exclusions or conditions are provided.
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. It warns that the email is the seller's, not the client's, but does not disclose other behaviors like read-only nature, authentication needs, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: the first states the core function, the second adds a crucial caveat. 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 simple query tool with one parameter and no output schema, the description is fairly complete. It covers the main function and a key clarification, though it could mention potential missing information like response structure.
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 covers 100% of parameters with a description that already identifies the email as belonging to the vendedor/gerente. The description reinforces this, adding minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retorna), the resource (clientes vinculados a um vendedor/gerente), and the identifying criterion (e-mail). It distinguishes from sibling tools that focus on saldo, limite, etc.
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 on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or comparative context with sibling 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?
With no annotations, the description carries full burden. It reveals that company/branch are fixed to '03/01', which is helpful. But it does not mention if the operation is read-only, whether authentication is needed, or what database table is accessed (SE1).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose. Every word is relevant.
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 query with one parameter and no output schema, the description is adequate. It provides enough context for an agent to use the tool correctly, though it omits the output format.
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 100% (one parameter). The description adds meaning by stating the parameter is mandatory, specifying the SAP field name (E1_CLIENTE), and noting it's the client code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the open balance (receivables) of a client, using the verb 'Retorna' and specifying the resource. It differentiates from sibling tools like 'protheus_limite_credito_cliente' but could be more explicit.
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?
It tells the user to provide the client code and notes that company/branch are fixed. However, it does not explicitly state when to use this tool versus alternatives, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the endpoint mapping, environment behavior (DFL returns SOLICITAÇÕES), and that the base may be empty. However, it lacks statements about idempotency, safety, authentication, or rate limits, which would be expected for a 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 concise (two sentences plus a note) and front-loaded with the core purpose. Every sentence adds value without redundancy. It is well-structured and easy to parse.
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 explains the purpose and basic usage adequately. It covers list vs specific retrieval and notes possible empty results. However, lacking details on return format or error handling, but the schema covers parameters well. Overall, it is mostly complete for a simple list tool.
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 100% with descriptions for all 6 parameters. The description adds integration context by stating that branchId+code together retrieve a specific record, which clarifies their relationship beyond the schema's individual descriptions. This extra meaning justifies a score above baseline 3.
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 MRP purchase requisitions (solicitações de compra) and can retrieve a specific one with branchId+code. It also mentions the endpoint name and environment behavior, distinguishing it from sibling tools like protheus_produtos_mrp or protheus_pedidos_compra_mrp.
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 provides basic guidance: 'Sem ID, lista; com branchId+code, uma específica.' This tells when to use for list vs specific retrieval, but it does not exclude when not to use or compare with alternatives among siblings. More explicit context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool is a query ('Consulta'), implying read-only behavior, but does not disclose authentication needs, rate limits, or any potential side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences that front-load the purpose and key usage. Every word contributes meaning without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description lacks details about the return format or pagination behavior. For a simple query tool with five optional parameters, it covers the core functionality but leaves some gaps in expected output.
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 description coverage is 100%, but the description adds value by explaining that the 'code' parameter changes the output from a list to a specific condition. This goes beyond the schema's simple parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Consulta' and the resource 'condições de pagamento', and distinguishes behavior based on the 'code' parameter: list all without code, specific condition with code. This differentiates it from sibling tools like 'protheus_saldo_cliente'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool without 'code' (to get a list) and with 'code' (to get a specific condition). Although it does not mention when not to use it or alternatives, the context is clear and sufficient for basic usage.
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?
Annotations are absent, so the description bears full responsibility. It indicates a read-only operation ('Consulta') and includes a caveat that the database may be empty. However, it lacks explicit safety disclosure, rate limit info, or side effects. The read-only nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a short note, with no extraneous information. The core purpose is stated first, followed by usage patterns and a caveat. Every sentence adds value.
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 the absence of an output schema and annotations, the description covers the main retrieval modes and warns about empty results. It does not detail the output format or fields, but the schema covers parameter details. Some minor gaps remain, but overall it is sufficient for a simple query tool.
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 description coverage is 100%, but the tool description adds critical usage semantics: the interaction between branchId and code for retrieving a specific warehouse versus omitting them for a list. This goes beyond individual parameter descriptions in 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 queries MRP warehouses (Consulta os armazéns do MRP) and explains two modes: without ID returns a list, with branchId+code returns a specific warehouse. This differentiates it from sibling tools, which cover different entities like products or stock balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two distinct usage patterns (list vs. specific warehouse via branchId+code), providing clear guidance on parameter combinations. However, it does not explicitly compare to sibling tools or mention when not to use it. The sibling tools are clearly separate resources, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses behavior for two scenarios (list vs. specific record) and warns that the database may be empty. This is sufficient for a read-only query 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?
The description is two sentences plus a short note, all essential. No redundancy or fluff. It is front-loaded with the core purpose.
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 6 optional parameters and no output schema, the description covers the basic usage and a possible state (empty DB). It lacks integration of pagination and field selection details, but schema covers those.
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 100% with parameter descriptions. The description adds value by explaining how parameters affect output (e.g., branchId+code returns specific record), though it does not elaborate on pagination or ordering beyond 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 'Consulta os saldos em estoque do MRP' which is a specific verb (consult/saldo) and resource (estoque MRP). It also distinguishes between list vs. specific record, and sibling tools have distinct domains (client balance, credit limits, etc.).
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?
While the description explains behavior with and without ID, it does not provide explicit guidance on when to use this tool over alternatives or when not to use it. Context from sibling names implies distinct purposes, but no direct comparison is given.
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 notes the endpoint name and a key behavioral detail: in the DFL environment it returns PEDIDOS. Also warns that the base may be empty. Adequate 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?
Extremely concise—two sentences with no fluff. The purpose is front-loaded, and critical notes are included without 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?
Given the moderate complexity, no output schema, and involved sibling tools, the description provides enough context to operate correctly. The note about empty data and the endpoint name add completeness.
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?
All 6 parameters are described in the schema (100% coverage). The description adds meaning by explaining that omitting ID returns a list, while providing branchId+code returns a specific record, which complements 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 'Pedidos de compra do MRP' and specifies the endpoint. It distinguishes between listing all (no ID) and retrieving a specific order (with branchId+code). Among sibling tools focused on MRP, this tool is unique.
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 guidance on how to list all versus get a specific record. Lacks explicit when-not or alternatives, but the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that without employeeId no personal data is returned, and with employeeId sensitive data is returned. Does not mention read-only nature or side effects, but the core behavioral trait (data sensitivity) is well communicated. Could add a note about being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, minimal words. Front-loaded: first sentence states tool, second explains behavior. No redundancy, every sentence adds value.
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 single parameter, no output schema, and no annotations, the description is complete. It fully explains both modes and data sensitivity. No missing information for selecting and invoking the tool correctly.
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 description already covers employeeId as optional sensitive data. Description adds meaning by explaining the different outputs based on presence/absence of this parameter, which goes beyond the schema. Baseline 3 due to 100% coverage, but extra context raises score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Demonstrativo de pagamento (RH)' and distinguishes two modes: without employeeId returns types of salary changes (no personal data), with employeeId returns employee statement (sensitive personal data). It is a specific verb-resource pair that differentiates from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use each mode: 'Sem employeeId, retorna os tipos de alteração salarial ... Com employeeId, retorna o demonstrativo do funcionário'. Provides clear context and warns about sensitive data.
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:

[![mcp-protheus-tdn MCP server](https://glama.ai/mcp/servers/Endrews-DFL/mcp-protheus-tdn/badges/card.svg)](https://glama.ai/mcp/servers/Endrews-DFL/mcp-protheus-tdn)

Score Badge

Copy to your README.md:

[![mcp-protheus-tdn MCP server](https://glama.ai/mcp/servers/Endrews-DFL/mcp-protheus-tdn/badges/score.svg)](https://glama.ai/mcp/servers/Endrews-DFL/mcp-protheus-tdn)

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/Endrews-DFL/mcp-protheus-tdn'

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