Consulta as comissões de venda, ou uma comissão pelo id interno.
Bulk support: accepts ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| ids | No | ||
| page | No | ||
| order | No | ||
| expand | No | ||
| fields | No | ||
| filter | No | ||
| params | No | ||
| account | No | ||
| page_size | No | ||
| sql_filter | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior, so the description's burden is lower. It adds a useful behavioral detail about bulk execution via ids, but does not mention pagination, filtering behavior, or what the response looks like. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: the purpose appears first, followed by a single high-value behavioral note. There is no redundant text or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite eleven parameters and no output schema, the description only explains the id/ids selection mechanism and bulk support. It omits pagination, ordering, filtering, expansion, field selection, and response shape, so an agent lacks enough context to call the tool correctly in many scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description clarifies only two of eleven parameters: 'id' and 'ids'. Several cryptic parameters such as 'expand', 'sql_filter', 'params', and 'page_size' receive no explanation, so the description does not compensate adequately for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('comissões de venda'), and clarifies that it can return a collection or a single commission by internal id. This clearly establishes the tool's core purpose, though it does not explicitly compare itself to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource name and description imply the tool is for querying commission data, and the bulk support line gives some guidance on using ids for batched requests. However, there is no explicit statement of when to prefer this tool over alternatives or any exclusions, leaving usage partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each protheus_* tool targets a distinct ERP entity or API, and descriptions explain the resource and key arguments, so an agent can usually pick the right one. The main ambiguities are the generic protheus_api, which overlaps with every dedicated reader, and the trio protheus_catalogo/protheus_diagnostico/protheus_modulos, all of which are about API/module availability.
The domain tools consistently use the protheus_ prefix in snake_case with a descriptive resource suffix, which is predictable once the pattern is recognized. There are minor deviations such as protheus_list_accounts using an English verb and the platform-level tools (authenticate, connect, marketplace, show_version, toolkit_info) not following the protheus_ prefix at all.
32 tools is above the threshold where a tool list becomes heavy for agents to scan, even though the ERP domain is broad. The set could be split into a focused Protheus reader plus a platform-management server, or several entities could be combined behind parameterized tools.
The read-only surface covers a wide range of common Protheus areas (customers, products, stock, sales, production, pricing, CRM) and protheus_api with catalogo/diagnostico allows access to additional official/custom read routes. However, there are no create/update/delete tools at all, and major ERP areas such as financial movements and HR are absent, so mutation workflows dead-end in this server.