Múltiplos ponto-no-tempo de uma AÇÃO (P/L, P/VP, EV/EBITDA anuais; P/L TTM trimestral) — preço do 1º pregão APÓS a publicação real do balanço, sem vazamento de informação futura.
Só ações. Para o P/VP de um fundo imobiliário use fii, que o calcula
sobre o informe mensal da CVM, não sobre balanço trimestral.
WEGE3 gratuita; demais exigem chave_api.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| chave_api | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the key methodology (no look-ahead bias, price after actual publication) and the API key requirement. However, it does not describe the response format or behavior on errors, which is a minor gap given no output schema exists.
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 three sentences with no wasted words. It front-loads the core purpose and methodology, then adds usage nuance about scope and pricing. The line 'Só ações' ('only stocks') slightly repeats the initial 'de uma AÇÃO', but it reinforces the exclusion and fits naturally.
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?
The description covers the multiples provided, the pricing rule, the restriction to stocks, the alternative tool, and the API key condition. Since there is no output schema, it could be more explicit about the return format, but for an agent deciding whether and how to call the tool, the information is sufficient.
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?
The schema provides only `ticker` and `chave_api` with 0% coverage, so the description must compensate. It adds meaning by giving a concrete example (WEGE3) and explaining that `chave_api` is required for all tickers except WEGE3, which clarifies the role of both parameters beyond the bare schema fields.
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 explicitly defines the tool's function: it provides point-in-time multiples (P/L, P/VP, EV/EBITDA annual; P/L TTM quarterly) for stocks, with a precise pricing rule based on the first trading session after the actual earnings release. It also clearly distinguishes itself from the sibling `fii` tool for real estate funds, making the resource and scope unambiguous.
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?
It explicitly states 'Só ações' (only stocks) and directs users to the `fii` sibling for real estate fund P/VP, providing a clear alternative. It also gives a concrete usage condition: WEGE3 is free while all other tickers require an API key, helping an agent decide when to invoke this tool.
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.