microvix_lojas
Dados das lojas/empresas do portal (LinxLojas): CNPJ, endereço, regime tributário.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| account | No | ||
| cnpj_emp | No |
Dados das lojas/empresas do portal (LinxLojas): CNPJ, endereço, regime tributário.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| account | No | ||
| cnpj_emp | No |
Changes observed during successful MCP inspections.
Input schema / properties / limitAdded value: +{
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "type": "number"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context such as pagination behavior, ordering, or implicit filters. It only describes data content, not how the tool behaves, so it falls short of the lowered bar.
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 a single, compact sentence that front-loads the core topic and lists key return fields. It is efficient, though slightly terse, earning a 4 for structure without being overlong.
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?
For a tool with four parameters and no output schema, the description is incomplete. It does not explain the parameters (limit, offset, account, cnpj_emp) or how they filter results. While annotations confirm read-only and idempotent behavior, the agent lacks the information needed to construct valid calls, such as which account or CNPJ to pass.
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%, with four parameters (limit, offset, account, cnpj_emp) completely undocumented. The description mentions CNPJ in a return-field context but does not explain any parameter's meaning or usage. The description fails to compensate for the lack of schema documentation.
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 identifies the resource (lojas/empresas do portal) and some fields (CNPJ, endereço, regime tributário), but lacks a verb like 'list' or 'fetch', making the operation implicit. It distinguishes from siblings by focusing on store data, but the absence of an explicit action lowers clarity from a 4 to a 3.
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?
No guidance is given on when to use this tool versus alternatives like microvix_grupo_lojas or microvix_clientes_fornec. The description provides no context for selection, leaving the agent to infer based on the name alone.
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.