Skip to main content
Glama
brasil-planos-saude-mcp

brasil-planos-saude-mcp

where_to_complain

Get official ANS complaint channels and steps for denied or delayed health procedures or contract problems in Brazil.

Instructions

How to complain about a health plan in Brazil: the official ANS channels and the steps.

Use when a user's plan denied or delayed a procedure, or they have a contract problem. Each channel was checked on the ANS consumer-service page (conferido_em).

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries disclosure duty, and it does add provenance the schema cannot express: each channel was 'checked on the ANS consumer-service page (conferido_em)'. It doesn't discuss return shape or how many channels come back, but for a zero-parameter read-only guidance lookup the behavioral risk surface 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short lines: what it returns, when to call it, and how the data was verified. The trigger sentence is front-loaded right after the purpose statement and no sentence is filler.

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?

An output schema exists, so the description needn't spell out the return format, and it already covers purpose, trigger and data provenance. What is slightly missing is any hint of scope limits (e.g. whether it covers only ANS-regulated plans vs. employer self-funded plans), which matters for this domain.

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 tool takes zero parameters, so there is nothing semantic to explain and the baseline for an argument-free tool applies. The description correctly implies a no-input lookup by not suggesting any audience/state/locale scoping.

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?

Names a specific resource and scope: 'the official ANS channels and the steps' for complaining about a Brazilian health plan. The sibling tools (operator_profile, find_operators, compare_operators, rank_operators) are all operator-data tools, so this guidance tool is unambiguously distinct from every one of them.

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?

Gives an explicit trigger: 'Use when a user's plan denied or delayed a procedure, or they have a contract problem.' That is a clear invocation condition covering the two main scenarios. It does not name an alternative or exclusion, but no sibling could plausibly be confused with it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.