Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@openar/mcp list initiatives about education in the current legislature"
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.
Servidor MCP para o openAR — dados abertos da Assembleia da República.
Permite a agentes de IA aceder a iniciativas legislativas, deputados, votações em plenário, petições e comissões parlamentares.
Adiciona ao ficheiro de configuração do Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"openar": {
"command": "npx",
"args": ["-y", "@openar/mcp"]
}
}
}claude mcp add --scope user openar -- npx -y @openar/mcp{
"command": "npx",
"args": ["-y", "@openar/mcp"]
}Related MCP server: Spanish Public Data MCP
Ferramenta | Descrição |
| Valores disponíveis para filtros: legislaturas, grupos parlamentares, tipos de iniciativa |
| Pesquisar iniciativas legislativas por legislatura, tipo, estado, grupo, palavra-chave |
| Detalhe completo de uma iniciativa: autores, eventos, votações, publicações e fases em comissão |
| Pesquisar deputados por legislatura, grupo parlamentar, nome ou situação |
| Perfil do deputado com todos os mandatos e iniciativas recentes |
| Actividade parlamentar completa: intervenções, comissões, requerimentos, relatorias |
| Votações em plenário filtradas por legislatura, resultado ou intervalo de datas |
| Detalhe de uma votação com resultado por grupo parlamentar |
| Petições filtradas por legislatura, situação ou palavra-chave |
| Detalhe de uma petição com comissões, relatores e documentos |
| Listar comissões parlamentares, com filtro por legislatura ou nome |
| Detalhe de uma comissão com todas as iniciativas apreciadas e respetivos relatores |
Todos os dados provêm de api.openar.pt — uma API gratuita e aberta com cobertura da I à XVII Legislatura (1976–presente). Não requer autenticação.
Especificação OpenAPI: api.openar.pt/openapi.json
MIT
Get a parliamentary committee with its paginated list of initiatives and rapporteurs per initiative
| Name | Required | Description | Default |
|---|---|---|---|
| numero | Yes | Committee identifier, e.g. 1COM | |
| legislatura | No | Filter initiatives by legislatura, e.g. XVII | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool returns a committee with initiatives and rapporteurs. It fails to disclose pagination behavior, error states, read-only nature, or any side effects, leaving the agent with minimal behavioral clues.
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, efficient sentence (12 words) that is front-loaded with the action and resource. No redundant or extra information.
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?
Given the complexity (4 parameters, no output schema, no annotations), the description is insufficient. It omits details about the response structure, committee fields, and how pagination works for initiatives and rapporteurs.
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 50% (two of four parameters have descriptions). The tool description adds 'paginated list' which hints at page/limit, but does not elaborate on formatting, usage, or constraints beyond the schema defaults.
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 clearly identifies the verb 'Get', the resource 'parliamentary committee', and specifies the scope includes a paginated list of initiatives and rapporteurs. It distinguishes itself from siblings like 'list_comissoes' (listing committees) and 'get_iniciativa' (single initiative).
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 guidelines on when to choose this tool over alternatives. It does not mention prerequisites, exclusions, or context (e.g., when to use 'get_comissao' vs 'list_comissoes' or 'get_iniciativa').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an MP with all their mandates and recent initiatives
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deputy ID (DepCadId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description clearly states that the tool returns 'mandates and recent initiatives' in addition to MP data. This informs the agent of the comprehensive nature of the response, though it omits details on error cases or authentication.
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, front-loaded sentence that efficiently conveys the tool's action and scope. It is concise without being too terse, though it could be slightly more structured.
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?
Given the lack of output schema, the description adequately explains the return content (mandates and initiatives). It is clear enough for an agent to understand what data to expect, though it could explicitly mention basic MP fields for completeness.
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 input schema already documents the single 'id' parameter with a description. The tool description does not add additional semantic value beyond what the schema provides, such as how to find the ID. Baseline score of 3 applies due to high schema 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 clearly states the tool retrieves a specific MP and includes 'all their mandates and recent initiatives'. This distinguishes it from siblings like get_comissao or get_deputado_atividade, making the purpose 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?
The description implies usage for fetching detailed MP data but provides no explicit guidance on when to use this tool versus alternatives like list_deputados or get_deputado_atividade. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full parliamentary activity for an MP: initiatives, requirements, plenary interventions, committees
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deputy ID (DepCadId) | |
| legislatura | No | e.g. XVII — omit for full history |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full burden. It mentions what is returned (activity types) but does not disclose read-only nature, response structure, pagination, or any side effects. The name implies a read operation, but explicit behavioral traits are missing.
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, front-loaded sentence with no redundant information. Every part contributes to understanding the tool's purpose, making it concise and effective.
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 no output schema and two parameters, the description adequately lists the types of activities returned. However, it lacks mention of how to obtain the deputy ID (e.g., from list_deputados) and does not describe the response format, leaving minor gaps.
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 coverage is 100% with clear descriptions for both parameters (id as Deputy ID, legislatura as optional filter). The description does not add new meaning beyond the schema, so baseline 3 is appropriate.
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 clearly states the verb (Get), resource (full parliamentary activity for an MP), and specifies included content (initiatives, requirements, plenary interventions, committees), differentiating it from sibling tools which focus on single entities or lists.
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 description implies usage for retrieving MP activity but does not explicitly state when to use this tool over alternatives (e.g., get_deputado for basic info, list_deputados for finding IDs). No exclusions or context about prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a legislative initiative with full detail: authors, events, votes, publications, and committee phases (comissoesFases) with rapporteurs, documents, and hearings
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Initiative ID (IniId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates the tool retrieves data (safe operation) but does not disclose whether authentication is required, potential errors for invalid IDs, or that it's read-only. The description is adequate but lacks explicit safety or permission context.
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 sentence that efficiently lists the returned components. It is well-structured and front-loaded. No redundant words, but could be slightly more organized with bullet points for clarity.
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 single-parameter getter with no output schema, the description covers the major components returned. However, it does not mention handling of missing IDs or error responses. The context of legislative initiatives is clear, and the detail is sufficient for most use cases.
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 input schema has 100% coverage with a description for the 'id' parameter. The tool description does not add further guidance on how to determine the ID or its format, so no added value beyond the schema. Baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'a legislative initiative' and enumerates the detailed components included (authors, events, votes, publications, committee phases). This distinguishes it from sibling tools like list_iniciativas which likely return a list without full detail.
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 description implies usage when needing full detail on a single initiative, but does not explicitly contrast with siblings like list_iniciativas for browsing or other get_ tools. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available filter values: legislaturas, grupos parlamentares, tipos de iniciativa
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | Filter grupos/tipos to a specific legislatura |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states purpose without disclosing traits like read-only behavior, rate limits, or effects. Minimal behavioral info.
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?
Single sentence with key info, no redundancy, perfectly front-loaded.
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 simple metadata tool with one optional parameter and no output schema, the description adequately conveys the return value categories. Slightly ambiguous on response format but acceptable.
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 covers parameter fully (100% coverage), but description adds value by specifying the categories of returned filter values, which informs the parameter's filtering role.
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 'Get available filter values: legislaturas, grupos parlamentares, tipos de iniciativa' clearly states the tool fetches metadata for filtering, distinguishing it from sibling tools that retrieve specific entities.
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 explicit guidance on when to use versus alternatives, but the purpose is self-evident: use to obtain filter values for other tools. Implied usage, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a petition with committees, rapporteurs, and documents
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Petition ID |
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 adds context about included components (committees, rapporteurs, documents) beyond the schema, but lacks disclosure of behavioral traits like permissions, rate limits, or error conditions.
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, front-loaded sentence with no extraneous information. Every word adds value.
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?
Given the simplicity of the tool (one parameter, no output schema), the description adequately conveys what is returned. The mention of committees, rapporteurs, and documents provides useful context, though some users might want more detail about the full response structure.
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 100% with 'Petition ID' for the single parameter. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
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 clearly states the action ('Get a petition') and the resource, and distinguishes from siblings like list_peticoes by specifying it includes committees, rapporteurs, and documents. However, it could be more precise about the uniqueness of the returned petition.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied (when a single petition with details is needed), but no when-not or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single vote with party breakdown
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vote ID | |
| iniciativa_id | Yes | Initiative ID (required — vote IDs are unique per initiative) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' implies a read-only operation, and 'with party breakdown' hints at the return format. However, it does not confirm safety, side effects, or any additional behavioral traits beyond the name.
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, well-formed sentence with no filler words. It efficiently conveys the core purpose without redundancy.
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 simple get operation with two well-described parameters and no output schema, the description covers the essential purpose. It could be slightly more detailed about the return structure (e.g., what 'party breakdown' entails), but it is still fairly complete given the tool's simplicity.
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 100%, so the schema already explains both parameters (id and iniciativa_id). The description adds no extra meaning or constraints beyond what is 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single vote with party breakdown' clearly states the action (get), resource (vote), and qualifiers (single, with party breakdown). It distinguishes from sibling tools like list_votacoes (which lists votes) and get_iniciativa (which gets initiatives).
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 on when to use this tool versus alternatives. The purpose implies it's for fetching a specific vote, but no explicit when-not or context is provided. Sibling list_votacoes exists, but the description doesn't help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List parliamentary committees. Each committee is identified by a numero and may appear across multiple initiatives and legislatures.
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | Filter by the legislatura of associated initiatives, e.g. XVII | |
| q | No | Search in committee name | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention pagination, filtering behavior, idempotency, or any side effects. The note about numero and legislatures only partially addresses the tool's behavior.
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 two sentences, front-loaded with the primary action, and contains no extraneous information. Every sentence adds value.
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?
With no output schema and no annotations, the description is insufficiently complete. It does not explain output format, pagination behavior, or how parameters like page and limit affect results, leaving significant gaps for an agent.
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 50% (two parameters lack descriptions). The description adds no parameter-specific details beyond what the schema already provides, failing to compensate for the missing parameter descriptions.
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 clearly states 'List parliamentary committees' with a specific verb and resource. It adds context about identification by numero and association across initiatives and legislatures, distinguishing it from the singular get_comissao sibling.
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 description implies use for listing committees but provides no explicit guidance on when to use this tool versus alternatives like get_comissao or other list tools. No exclusions or context-specific recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MPs with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | e.g. XVII | |
| grupo | No | Party abbreviation e.g. PS, PSD, BE | |
| q | No | Search by name | |
| situacao | No | Use 'ativo' for current MPs | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. The term 'List' implies a read operation, but there is no mention of pagination behavior (despite page/limit params), rate limits, or result ordering. The description does not disclose that the tool returns a list of deputies or any response structure.
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 extremely concise at 4 words. This is efficient but risks under-specification. For a simple list tool it may suffice, but the structure lacks any purposeful front-loading of critical information.
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?
Given 6 optional parameters, no output schema, and no annotations, the description is incomplete. It does not mention what the response format is (e.g., list of objects), how filters combine, or any default behavior (e.g., returns all MPs if no filters). The agent would need to guess or test.
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 input schema already describes the parameters (e.g., 'Party abbreviation e.g. PS'), giving 67% coverage. The description adds no extra meaning or usage context beyond what the schema provides. For parameters like page and limit, the schema provides defaults and bounds, but the description does not explain how they interact with the listing.
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 clearly states the tool lists MPs with optional filters, which matches the name and input schema. However, it does not differentiate from sibling list tools like list_comissoes or list_iniciativas, so it lacks specificity about the resource being Portuguese parliament deputies.
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 provided on when to use this tool versus alternatives like get_deputado (for a single MP) or list_votacoes. The description gives no context about typical use cases or prerequisites, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List legislative initiatives with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | e.g. XVII, XVI | |
| tipo | No | R=Resolução P=Proposta J=Projeto D=Decreto S=Outros A=Apreciação I=Europeia C=Pergunta | |
| estado | No | e.g. Aprovado, Rejeitado, Caducado | |
| grupo | No | Party abbreviation e.g. PS, PSD, CH | |
| resultado | No | ||
| q | No | Search in title | |
| deputado | No | Deputy ID or name (partial match) | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'list' implying read-only but lacks details on pagination, ordering, response format, or any side effects. The behavior is under-disclosed.
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 very short (one sentence), which is concise but lacks important structural elements. It conveys the basic purpose but does not front-load critical details like pagination or filter logic. Every word earns its place, but it omits necessary context.
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?
Given 9 parameters, no annotations, and no output schema, the description is far from complete. It fails to explain pagination, how filters combine, or what the response contains. The tool's complexity demands a richer description.
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 coverage is high (67% with descriptions), and the description does not add extra meaning beyond the schema. Baseline score of 3 is appropriate as the description does not compensate for the schema's limited doc on parameters like page and limit.
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 clearly states the tool lists legislative initiatives with optional filters. It uses a specific verb ('list') and resource, distinguishing it from siblings like 'get_iniciativa' (single item) and other list tools for different entities.
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 on when to use this tool versus alternatives. There is no mention of using 'get_iniciativa' for a single initiative or other list tools for different resources. The description provides no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List petitions with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | e.g. XVII | |
| situacao | No | e.g. Admitida, Arquivada | |
| q | No | Search in subject | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or pagination behavior. It only states the basic function, which is insufficient for safe agent usage.
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, front-loaded sentence with no wasted words. However, it could include more useful context without becoming verbose.
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?
Given the tool has 5 optional parameters and no output schema, the description lacks details on response format, ordering, pagination, or filter behavior. It is insufficient for complete understanding.
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 input schema already describes 3 out of 5 parameters (legislatura, situacao, q) with examples. The description adds no extra meaning beyond 'optional filters'. page and limit lack schema descriptions but have defaults and constraints. Overall, the description does not compensate for the missing parameter 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 clearly states the action ('List') and resource ('petitions') with optional filters, making the tool's purpose evident. However, it does not distinguish it from sibling list tools like list_comissoes, list_deputados, etc., which reduces differentiation.
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 provided on when to use this tool versus alternatives, nor any context on prerequisites or exclusions. The description is purely functional without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List plenary votes with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| legislatura | No | e.g. XVII | |
| resultado | No | ||
| unanime | No | ||
| data_inicio | No | YYYY-MM-DD | |
| data_fim | No | YYYY-MM-DD | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as pagination, default sorting, filtering behavior, or output format. For a tool with 7 optional params, this is insufficient.
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 extremely concise at one sentence. However, it could include more useful details without becoming verbose.
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?
With 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain pagination, filter semantics, or return structure.
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?
Only 43% of parameters have schema descriptions (legislatura, data_inicio, data_fim). The tool description adds no extra meaning beyond the schema hints. Parameters like resultado, unanime, page, limit remain unexplained.
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 uses a specific verb 'List' and resource 'plenary votes with optional filters', clearly distinguishing it from sibling 'get_votacao' which retrieves a single vote.
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 on when to use this tool versus alternatives like get_votacao, list_comissoes, etc. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.5get_comissaoget_deputadoget_deputado_atividadeget_iniciativaget_metaget_peticaoget_votacaolist_comissoeslist_deputadoslist_iniciativaslist_peticoeslist_votacoesScored across 12 tools
Each tool targets a distinct entity and operation (get vs list), with no overlap. For example, get_comissao retrieves a single committee with detailed information, while list_comissoes provides a list of committees.
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_deputado, list_iniciativas), with get_meta as the only exception but still adhering to the pattern.
12 tools is well-scoped for a parliamentary data API, covering all major entities (committees, MPs, initiatives, petitions, votes) without being excessive or too sparse.
The tool surface covers the core lifecycle for each entity (list and get) and includes metadata retrieval and vote details, leaving no obvious gaps for a read-only parliamentary data service.
MCP server for Brazilian Federal Senate open data (legislative, administrative, e-Cidadania).
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for structured Dutch vehicle data and license plate intelligence. Access RDW-based vehicle specifications, registration details, APK information, fuel and emissions data, weights, dimensions, ownership-related signals and other vehicle knowledge through KentekenKompas.nl. Built for AI assistants, agents and applications that need reliable, machine-readable information about vehicles registered in the Netherlands.
dados.gov.pt MCP — Portugal's national open data portal.
