How do I use mcp-eouve?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-eouve show my e-SIC requests" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-eouve

by igormatos

Overview Schema Related Servers Score Discussions

JavaScript

Remote

mcp-eouve

Servidor Model Context Protocol (MCP) para integração com o portal eOuve (Ouvidoria Municipal & e-SIC).

Ele permite que você:

Autentique-se com credenciais ou com um token JWT.
Liste os acompanhamentos de Ouvidoria.
Liste as solicitações de e-SIC (Pedido de Informação).
Envie/Cadastre novos pedidos de e-SIC.
Liste os órgãos (secretarias) e assuntos cadastrados para qualquer município/cidade suportada.

Pré-requisitos

Node.js (recomendado v20+)
npm

Related MCP server: Situação Eleitoral (TSE)

Instalação

Clone ou copie este repositório para o seu sistema.
Execute o comando npm install na pasta do projeto:
```
npm install
```

Ferramentas Expostas (Tools)

1. `login`

Autentica no sistema eOuve e armazena o token de acesso para a sessão ativa.

Parâmetros:
- username (string, obrigatório): E-mail ou CPF/CNPJ.
- password (string, obrigatório): Senha de login.
- cityId (string, opcional, padrão: "2355" para Olinda).

2. `list_ouvidorias`

Lista as manifestações ativas de Ouvidoria associadas ao usuário.

Parâmetros:
- token (string, opcional): Token de acesso (se omitido, utiliza o token ativo da sessão).

3. `list_sics`

Lista os Pedidos de Informação (e-SIC) ativos associados ao usuário.

Parâmetros:
- token (string, opcional): Token de acesso (se omitido, utiliza o token ativo da sessão).

4. `list_secretarias`

Obtém as secretarias e IDs de assuntos cadastrados para a cidade especificada.

Parâmetros:
- cityId (string, opcional): Padrão: cidade da sessão ou "2355".
- token (string, opcional): Token de acesso.

5. `send_sic`

Envia um novo Pedido de Informação (e-SIC).

Parâmetros:
- pergunta (string, obrigatório): O conteúdo do pedido de informação.
- idSecretaria (string, obrigatório): ID da secretaria de destino.
- idSecretariaAssunto (string, obrigatório): ID do assunto específico.
- token (string, opcional): Token de acesso.
- idUnidade (string, opcional, padrão: "").
- dadosSigilosos (string, opcional, padrão: "N").
- urgente (string, opcional, padrão: "N").

Integração com o Claude Desktop

Para configurar este servidor no Claude Desktop, edite o seu arquivo de configuração:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Adicione a configuração do servidor:

{
  "mcpServers": {
    "eouve": {
      "command": "node",
      "args": ["/caminho/absoluto/para/mcp-eouve/index.js"],
      "env": {}
    }
  }
}

Substitua /caminho/absoluto/para/mcp-eouve/index.js pelo caminho real da pasta do projeto em sua máquina.

Available Tools

5 tools

list_ouvidoriasA

Listar os acompanhamentos de manifestações de Ouvidoria associados ao usuário.

ParametersJSON Schema

Name	Required	Description	Default
`token`	No	Token de acesso (bearer). Opcional se já foi efetuado o login na sessão.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It correctly indicates a read operation ('list') and associates results with the user. However, it does not disclose authentication requirements (token is optional), result format, or potential side effects.

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 a single, concise sentence with no redundant words. It is front-loaded and directly states the tool's purpose.

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 simple input (one optional parameter) and no output schema, the description is adequate but lacks details on return format, pagination, or ordering. For a list tool, slightly more context would improve completeness.

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?

Schema coverage is 100% and the single parameter 'token' is already described in the schema. The description adds no additional semantic 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?

Description states clearly that the tool lists follow-ups of Ombudsman manifestations associated with the user. The verb 'list' and specific resource differentiate it from sibling tools like 'list_secretarias' and 'list_sics'.

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 is provided on when to use this tool versus alternatives (e.g., login, send_sic). The description implies it is for retrieving user-specific data, but no explicit usage context or prerequisites are given.

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

list_secretariasA

Obter os órgãos (secretarias) e assuntos cadastrados para a cidade, ideal para descobrir IDs necessários para registrar um e-SIC.

ParametersJSON Schema

Name	Required	Description	Default
`token`	No	Token de acesso (bearer). Opcional se já foi efetuado o login na sessão.
`cityId`	No	ID do município/cidade no eOuve (default: usar o armazenado na sessão ou '2355')

TDQS

A3.5/5.0

Behavior2/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 states it is a read operation (list) but does not disclose any behavioral aspects such as authentication requirements, rate limits, or side effects. The description adds minimal behavioral context beyond the schema.

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 a single sentence of about 20 words, front-loading the action and resource. No wasted words; it efficiently communicates the core function and use case.

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 only two optional parameters, no output schema, and no annotations, the description is adequately complete for a simple list operation. It explains the purpose and content but lacks details on output format or authentication needs. An output schema or more context would improve completeness.

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?

Schema description coverage is 100% with both parameters (token, cityId) having descriptions. The tool description does not add additional meaning to the parameters beyond what is already in the schema, so a 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 uses the verb 'Obter' (get) and specifies the resource 'órgãos (secretarias) e assuntos cadastrados para a cidade'. It also explains the purpose: discovering IDs for e-SIC registration. This clearly distinguishes it from siblings like list_ouvidorias and list_sics.

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 it is for obtaining IDs needed for e-SIC registration ('ideal para descobrir IDs necessários para registrar um e-SIC'), but does not explicitly state when to use or when to avoid this tool. No mention of alternatives among siblings.

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

list_sicsB

Listar os acompanhamentos de Pedidos de Informação (e-SIC) associados ao usuário.

ParametersJSON Schema

Name	Required	Description	Default
`token`	No	Token de acesso (bearer). Opcional se já foi efetuado o login na sessão.

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It only says 'listar...associados ao usuário' but does not clarify if the operation is read-only, whether authentication is required (despite the token parameter being optional), or any side effects. This is insufficient for safe agent invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single short sentence, which is concise but under-informative. It front-loads the main action but lacks necessary context, making it minimally adequate.

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 simplicity (1 optional param, no output schema), the description should still explain what 'acompanhamentos' are and how they relate to the user. It does not set expectations about the returned data, leaving the agent with incomplete information.

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 clear description for 'token'. The tool description adds no extra semantic value beyond the schema, meeting the baseline for high coverage but not improving understanding.

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 it lists follow-ups of Information Requests (e-SIC) associated with the user, using a specific verb and resource. It distinguishes itself from siblings like list_ouvidorias and send_sic, making its purpose unambiguous.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing to be logged in, nor does it contrast with sister tools like send_sic for sending requests.

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

loginA

Autenticar no sistema eOuve usando usuário/senha ou CPF para obter o token de acesso (bearer token). O token é armazenado na sessão do MCP para chamadas seguintes.

ParametersJSON Schema

Name	Required	Description	Default
`cityId`	No	ID do município/cidade no eOuve (default: '2355' para Olinda)	2355
`password`	Yes	Senha de login
`username`	Yes	E-mail ou CPF/CNPJ de login

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the main behavior (authentication, obtaining token, storing in session) but does not mention token expiration, error handling, or whether the token is returned directly. Side effect of storage is noted.

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, front-loaded with the core purpose, and no redundant information. It is concise and directly conveys the essential details.

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?

While the description covers the main function, it lacks details about the return value (whether the token is directly returned) and error conditions. Without an output schema, the agent needs more complete behavioral context.

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?

Schema coverage is 100% with all parameters described. The description adds little beyond the schema; it mentions 'CPF' which aligns with the username field description but does not provide new semantic value. Baseline 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 tool's purpose: authenticating in the eOuve system using username/password or CPF to obtain a bearer token. It specifies the result (token) and that it is stored for subsequent calls, distinguishing it from sibling tools that list or send data.

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 implies that the tool should be used before other calls to obtain and store an access token, but it does not explicitly say when to use it or when not to. Context is clear that authentication is the first step, but no alternatives or exclusions are provided.

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

send_sicB

Registrar um novo Pedido de Informação (e-SIC) para uma secretaria específica e assunto.

ParametersJSON Schema

Name	Required	Description	Default
`token`	No	Token de acesso (bearer). Opcional se já foi efetuado o login na sessão.
`urgente`	No	Se o pedido é urgente: 'S' ou 'N'	N
`pergunta`	Yes	O texto/conteúdo da solicitação de informação
`idUnidade`	No	ID da unidade (opcional)
`idSecretaria`	Yes	ID da secretaria de destino (ex: '9956' para Mobilidade Urbana em Olinda)
`dadosSigilosos`	No	Se há dados sigilosos: 'S' ou 'N'	N
`idSecretariaAssunto`	Yes	ID do assunto específico (ex: '38642' para Diretoria de Trânsito em Olinda)

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It states the action (create), but does not disclose authentication requirements, idempotency, error behavior, or return format. The token parameter hints at login, but it's not explicit.

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 a single, efficient sentence with no redundancy. Every word contributes to the purpose.

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 absence of an output schema and lack of annotations, the description is insufficient. It does not explain return values, success/failure indicators, or process details, leaving gaps for a tool with 7 parameters.

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?

Schema coverage is 100%, so baseline is 3. The description adds minimal context (targeting specific secretariat and subject), but does not elaborate on other parameters beyond what the schema already provides.

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 ('Registrar um novo Pedido de Informação') and the resource ('e-SIC'), with scope ('para uma secretaria específica e assunto'). It effectively distinguishes from sibling tools, which are list/login actions.

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 explicit guidance on when to use this tool versus alternatives. The description implies usage for creating a request, but does not mention when not to use or compare to siblings like list_sics.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.0Jul 8, 2026
- First observedlist_ouvidorias
- First observedlist_secretarias
- First observedlist_sics
- First observedlogin
- First observedsend_sic

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: authentication (login), listing two types of requests (list_ouvidorias, list_sics), discovering metadata (list_secretarias), and submission (send_sic). No overlap.

Naming Consistency4/5

Most tools follow verb_noun snake_case pattern (list_ouvidorias, list_secretarias, list_sics, send_sic). 'login' is a single verb, deviating slightly, but still clear and commonly used.

Tool Count5/5

With 5 tools, the set is well-scoped for managing e-SIC and ouvidoria requests. It covers authentication, listing, and submission without being overly large or minimal.

Completeness3/5

Missing operations for ouvidorias (no send_ouvidoria) and no update/cancel for existing requests. The focus is on listing and creating e-SIC, leaving gaps in full lifecycle management.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Consultas A
io.github.mcp-dir
Official-source lookups on people and companies: registration status (CPF/CNPJ), Simples/MEI, SINTEG
Government Data Legal & Compliance Finance
291
EasyJur C
io.github.mcp-dir
Wrapper for the official EasyJur API (legal practice management): cases (with parties, claims, finan
Legal & Compliance Finance
471
editalmd B
com.editalmd
Brazilian public procurement (PNCP): search, deadlines, tender markdown, alerts and watches.
191
Projuris ADV B
io.github.mcp-dir
Wrapper for the official Projuris ADV REST API (legal practice management): cases, people (clients/p
Project Management Legal & Compliance Data Platforms
381

Related MCP Servers

MCP DivulgaCandContas Server
Government Data Search Open Data
karnagge
F
license
A
quality
D
maintenance
Enables querying Brazilian electoral data through TSE's official API. Supports candidate searches, election information, and campaign finance records for municipalities and states.
Updated a year ago (2025-09-19 02:43 UTC)
7
2
-
Situação Eleitoral (TSE)
Government Data Search
mcp-dir
A
license
Not graded
quality
C
maintenance
Enables querying a person's electoral situation in Brazil (TSE) using name, birth date, CPF and voter ID. Allows checking if the voter registration is regular or irregular.
Updated 22 days ago (2026-08-15 20:50 UTC)
MIT
MCP Compras.gov.br
Government Data Open Data
opedrosoares
A
license
A
quality
B
maintenance
Integrates public APIs from the Brazilian Compras.gov.br procurement ecosystem to support price research, supplier sanctions, contract analysis, and procurement planning.
Updated 5 days ago (2026-09-01 21:29 UTC)
94
2
MIT
Prefeitura RS Farroupilha: NFS
Government Data Finance Open Data
mcp-dir
A
license
Not graded
quality
C
maintenance
Enables read-only consultation of NFS-e (electronic service invoices) from the official source of the Farroupilha city hall. Works with any MCP client over HTTP.
Updated 7 days ago (2026-08-30 19:46 UTC)
MIT

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/igormatos/mcp-eouve'

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

mcp-eouve

Pré-requisitos

Instalação

Ferramentas Expostas (Tools)

1. login

2. list_ouvidorias

3. list_sics

4. list_secretarias

5. send_sic

Integração com o Claude Desktop

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `login`

2. `list_ouvidorias`

3. `list_sics`

4. `list_secretarias`

5. `send_sic`