Skip to main content
Glama
gabrielserrao

pyResToolbox MCP Server

oil_formation_volume_factor

Calculate oil formation volume factor (Bo) to convert reservoir oil volume to standard conditions for material balance, reserve estimation, and production forecasting.

Instructions

Calculate oil formation volume factor (Bo).

CRITICAL PVT PROPERTY - Computes ratio of oil volume at reservoir conditions to volume at standard conditions. Bo > 1.0 because oil expands due to dissolved gas and thermal expansion. Essential for material balance, reserve calculations, and production forecasting.

Parameters:

  • api (float, required): Oil API gravity in degrees. Valid: 0-100. Example: 35.0.

  • degf (float, required): Reservoir temperature in °F. Valid: -460 to 1000. Example: 180.0.

  • p (float or list, required): Pressure(s) in psia. Must be > 0. Can be scalar or array. Example: 3000.0 or [2000, 3000, 4000].

  • sg_g (float, optional, default=0.0): Gas specific gravity (air=1). Valid: 0-3. Typical: 0.6-1.2. Example: 0.75.

  • pb (float, optional, default=0.0): Bubble point pressure in psia. Required for accurate calculation. Example: 3500.0.

  • rs (float or list, optional, default=0.0): Solution GOR at pressure p in scf/stb. If 0, will be calculated from p. Must match p shape. Example: 600.0 or [400, 600, 800].

  • rsb (float, optional, default=0.0): Solution GOR at bubble point in scf/stb. Required if pb provided. Example: 800.0.

  • method (str, optional, default="MCAIN"): Correlation method. Options: "MCAIN", "STAN". MCAIN recommended.

Pressure Behavior:

  • p < pb: Bo increases with pressure (more gas dissolves)

  • p = pb: Bo reaches maximum (Bob, typically 1.2-2.0 rb/stb)

  • p > pb: Bo decreases with pressure (oil compressibility dominates)

Method Selection:

  • MCAIN (McCain et al. 1988): Recommended. More accurate, wider range.

  • STAN (Standing 1947): Classic method. Use for compatibility.

Returns: Dictionary with:

  • value (float or list): Bo in rb/stb (matches input p shape)

  • method (str): Method used

  • units (str): "rb/stb"

  • inputs (dict): Echo of input parameters

Common Mistakes:

  • Not providing rs when p < pb (will calculate incorrectly)

  • Using separator GOR instead of solution GOR at reservoir pressure

  • Pressure in barg/psig instead of psia

  • Confusing Bo (reservoir volume) with Bg (gas FVF)

Example Usage:

{
    "api": 35.0,
    "degf": 180.0,
    "p": [2000, 3000, 4000],
    "sg_g": 0.75,
    "pb": 3500.0,
    "rs": [400, 600, 800],
    "rsb": 800.0,
    "method": "MCAIN"
}

Result: Bo increases from ~1.15 rb/stb at 2000 psia to ~1.35 rb/stb at 3500 psia, then decreases to ~1.33 rb/stb at 4000 psia (above bubble point).

Note: Always provide rs for pressures below bubble point. If rs=0, tool will calculate it, but providing it explicitly improves accuracy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries full burden and excels. It explains critical behavioral aspects: pressure behavior (how Bo changes with p relative to pb), method differences (accuracy ranges), return format (dictionary structure), common mistakes (e.g., unit confusion), and accuracy implications (providing rs improves results). This goes far beyond basic parameter documentation.

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?

The description is well-structured with clear sections (Parameters, Pressure Behavior, Method Selection, Returns, Common Mistakes, Example Usage) and uses bold headings effectively. While lengthy, every sentence adds value—no fluff. It could be slightly more front-loaded by moving the example earlier, but overall it's efficiently organized for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, nuanced physics), no annotations, but with an output schema, the description is exceptionally complete. It covers purpose, usage, parameters, behavior, method selection, returns, common pitfalls, and includes a detailed example. The output schema handles return structure, allowing the description to focus on conceptual and practical aspects without redundancy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description comprehensively documents all 8 parameters. It adds essential semantics: validity ranges, examples, default values, shape matching requirements (rs must match p), and practical guidance (e.g., 'Required for accurate calculation' for pb). This fully compensates for the schema gap and provides rich context for each parameter.

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: 'Calculate oil formation volume factor (Bo)' and elaborates on its definition and importance. It distinguishes from siblings like gas_formation_volume_factor by specifying it's for oil, not gas, and from oil_density or oil_viscosity by focusing on volume ratio calculations for reservoir engineering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives. It distinguishes from gas FVF (Bg) in 'Common Mistakes', mentions method selection (MCAIN vs. STAN), and advises on providing rs for pressures below bubble point. It also implicitly positions it among sibling PVT tools by specifying its role in material balance and production forecasting.

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

Install Server

Other Tools

Latest Blog Posts

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/gabrielserrao/pyrestoolbox-mcp'

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