Skip to main content
Glama

Energetica — Argentine Oil & Gas Data

Hydrocarbon reserves

query_reserves
Read-onlyIdempotent

P1/P2/P3 oil and gas reserves at Dec 31 by year, basin, company and resource type (end of useful life); oil and gas in separate columns. Default: latest year. Example: {anio: [2024], agrupar_por: ['cuenca'], categorias: ['P1']}.

Input Schema

NameRequiredDescriptionDefault
anioNoYears; default the latest
cuencaNo
empresaNo
max_rowsNo
categoriasNoDefault P1, P2, P3
agrupar_porNoDefault anio
tipo_recursoNo

Output Schema

NameRequiredDescriptionDefault
metaYes
rowsYes
columnsYes
sectionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false. The description adds domain-specific context: reserves are measured at Dec 31, end of useful life, oil and gas are returned in separate columns, and the default year is the latest. It doesn't discuss auth, rate limits, or result size, but with annotations covering the safety profile this is adequate.

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

Conciseness4/5

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

Two sentences with a front-loaded summary of the data and dimensions, followed by default behavior and a compact example. No unnecessary text.

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?

The output schema documents return values and annotations cover the safety profile, so the description needn't repeat those. It provides the domain scope, default year, and a sample query, leaving only minor gaps like max_rows and explicit sibling routing.

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 43%, so the description must compensate. It illustrates anio, agrupar_por, and categorias in the example and mentions year, basin, company, and resource type, but leaves max_rows undocumented and doesn't explain the enum values for tipo_recurso beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (P1/P2/P3 oil and gas reserves) and the dimensions (year, basin, company, resource type) plus output shape (oil and gas in separate columns). It doesn't explicitly contrast with sibling query tools like query_production, but the domain is distinct enough for an agent to select it.

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?

It states the default behavior ('Default: latest year') and provides a sample request object, which helps parameter usage. However, it gives no explicit when-to-use guidance or comparison to alternatives such as query_production or query_trade.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources