Methodological Limitations and Reproducibility Boundaries

This model-only track does not attempt historical calibration, contract roll construction, or reconstruction of the paper’s full empirical environment. Consequently, the report supports qualitative validation of curve families and equation-consistent comparative statics, but not quantitative claims about realized market pricing errors or period-specific dynamics.

The boundary checks embedded in the pipeline enforce structural consistency, including , long-horizon convergence to , monotonicity in baseline contango/backwardation scenarios, and deterministic section completeness for this report. These gates improve reproducibility and protect against silent drift in the analytical implementation.

Conclusion on Parsimonious Parameterization

The results show that a compact parameter set is sufficient to reproduce key geometric families of term structures discussed in Gabillon (1991). Without data calibration, the model already captures the principal directional and curvature regimes: baseline contango/backwardation patterns, short-end deformation from non-zero short-term effects, and volatility-shape sensitivity to correlation. This confirms the explanatory value of parsimonious structural parameterization for qualitative futures-curve analysis.

Information Flow with MCP

sequenceDiagram
    participant User
    participant AppServer as App Server
    participant MCPClient as MCP Client
    participant MCPServer as MCP Server
    participant LLM
    participant DataSystem as Data System

    Note over User,DataSystem: Context should be delivered only when needed
    User->>AppServer: "What repositories do I have?"
    AppServer->>MCPClient: Request available tools
    MCPClient->>MCPServer: ListToolsRequest
    MCPServer->>MCPClient: ListToolsResult
    MCPClient->>AppServer: Tool list
    AppServer->>LLM: Query + tool schemas
    LLM->>AppServer: ToolUse request
    AppServer->>MCPClient: Execute selected tool
    MCPClient->>MCPServer: CallToolRequest
    MCPServer->>DataSystem: Fetch data
    DataSystem->>MCPServer: Response
    MCPServer->>MCPClient: CallToolResult
    MCPClient->>AppServer: Tool result
    AppServer->>LLM: toolResult
    LLM->>User: Final answer

Why This Matters

MCP improves reliability because the model does not need every document upfront. It can ask for exactly what it needs at the moment it needs it.

Key idea: context should be staged, not dumped.

• Stage 1: user intent and minimal prompt instructions.
• Stage 2: tool discovery and capability selection.
• Stage 3: focused tool execution with scoped inputs.
• Stage 4: response synthesis from verified outputs.

This is often more controllable than building a broad retrieval layer that pushes large context windows into every request.

Step-by-Step Reading of the Diagram

1. A user asks a question through an application server.
2. The server asks the MCP layer what tools are available.
3. The model receives the user query and tool schemas, then decides whether to call a tool.
4. The selected tool is executed through MCP against an external data system.
5. The tool result returns to the model.
6. The model produces a grounded final answer for the user.

Link to a Concrete Example

For a production-style implementation of this workflow, see my post on Excel model analysis with MCP:

Turning Excel Workbooks into AI-Readable Data with an MCP Server

That article shows how MCP tools can expose formula structure, dependencies, and named ranges so an LLM can migrate legacy spreadsheet logic into maintainable Python code.

Practical Takeaway

If you are building LLM applications, treat MCP as your context routing layer:

• keep tool inputs narrow,
• return structured outputs,
• and only provide supplemental information when a tool call proves it is necessary.

This approach yields better answers, lower token waste, and more predictable behavior.

The Problem with Excel Migration

A typical legacy workbook has:

• Hundreds of formula cells spread across dozens of columns
• Named ranges encoding business constants that are never documented
• Cross-sheet references that create hidden dependencies
• Formulas that vary row-to-row in subtle ways

You can open the file in Excel and read the formulas. But reading is not understanding. To migrate faithfully to Python, you need to know:

1. Which columns are inputs (constants entered by a user) versus derived (computed from other columns)?
2. In what order must derived columns be computed?
3. What do the named ranges mean, and which formulas use them?

Answering those questions manually for a 50-column workbook takes hours. With excel-formula-mcp and GitHub Copilot in agent mode, it takes minutes.

What Is MCP?

The Model Context Protocol is an open standard that lets language models call external tools in a structured, discoverable way. An MCP server declares tool schemas (name, description, input parameters). An MCP client (GitHub Copilot, Claude Desktop, or any compatible agent) can discover and call those tools dynamically during a conversation.

The key insight is that MCP decouples capability from model. The server knows how to read Excel files; the model knows how to reason about the results. Neither needs to know the internals of the other.

Architecture

┌──────────────────────────────────────────────────────┐
│                    MCP Client                        │
│         (GitHub Copilot / Claude Desktop)            │
└─────────────────────┬────────────────────────────────┘
                      │ stdio (JSON-RPC)
┌─────────────────────▼────────────────────────────────┐
│              excel-formula-mcp server                │
│                  (FastMCP / Python)                  │
│                                                      │
│  ┌─────────────────┐   ┌───────────────────────────┐ │
│  │   excel_loader  │   │     formula_parser        │ │
│  │  (openpyxl +    │   │  (regex tokeniser for     │ │
│  │   LRU cache)    │   │   same-sheet, cross-sheet │ │
│  └────────┬────────┘   │   named range, external   │ │
│           │            │   refs)                   │ │
│           │            └──────────────┬────────────┘ │
│  ┌────────▼────────────────────────────▼───────────┐ │
│  │            dependency_builder                   │ │
│  │  (column-level adjacency map + flat graph)      │ │
│  └─────────────────────────────────────────────────┘ │
│                                                      │
│  Tools:                                              │
│  · excel_analyze_range                               │
│  · excel_get_column_formulas                         │
│  · excel_get_dependencies                            │
│  · excel_get_sheet_dependencies                      │
│  · excel_get_named_ranges                            │
└──────────────────────────────────────────────────────┘

The server is intentionally layered. The three core modules handle one concern each:

• excel_loader: loads and caches workbooks with openpyxl using an LRU cache (size 5) so repeated tool calls within a session avoid redundant disk reads.
• formula_parser: tokenizes raw formula strings using four compiled regular expressions to extract same-sheet references, cross-sheet references, named ranges, and external workbook references.
• dependency_builder: aggregates parser output across formulas to produce typed dependency details per column, then flattens those into a simple adjacency map for client consumption.

The five tools are thin wrappers over these modules. They accept Pydantic v2 models for input validation, call the appropriate core functions, and return either JSON or Markdown depending on response_format.

The Five Tools

{
  "columns": {
    "D": {
      "header": "Revenue",
      "formula_count": 10,
      "unique_templates": ["=B{r}*C{r}"],
      "constant_count": 0,
      "empty_count": 0,
      "is_fully_derived": true,
      "named_ranges_used": [],
      "cross_sheet_refs": []
    }
  },
  "named_ranges_in_use": ["UnitCost"],
  "summary": {}
}

Design Decisions

The Migration Workflow

The server includes two reusable VS Code prompt templates in .github/prompts.

reports/<sheet_name>-analysis.md

Using the Server with VS Code

The repository includes .vscode/mcp.json with a stdio server entry:

{
  "servers": {
    "excel-formula-mcp": {
      "type": "stdio",
      "command": "${env:VIRTUAL_ENV}/bin/python",
      "args": ["-m", "excel_formula_mcp.server"],
      "cwd": "${workspaceFolder}",
      "env": {
        "PYTHONPATH": "${workspaceFolder}/src"
      }
    }
  }
}

With the environment activated and the server registered, Copilot can call the tools directly from chat.

Use excel_analyze_range to analyze sheet "Pricing" in data/stage/model.xlsx over range A1:H500, then generate a Python implementation plan.

Limitations

• .xls is not supported (openpyxl supports .xlsx and .xlsm)
• No formula evaluation engine is included
• No VBA analysis
• No cross-workbook resolution
• Dependency graph is column-level, not cell-level

Stack

Installation

GitHub repository: r2rahul/excel-formula-mcp

git clone https://github.com/r2rahul/excel-formula-mcp.git
cd excel-formula-mcp
uv pip install -e ".[dev]"
pytest

What Is Next

• Add optional formula evaluation support
• Add optional .xls ingestion path
• Add optional cell-level dependency mode
• Add Mermaid or DOT graph export support

Source: excel-formula-mcp

Problem Statement

Implement a Monte Carlo simulation based on Buffon’s needle problem to estimate the value of . Buffon’s needle is a classic problem in probability theory that relates the probability of a needle crossing parallel lines on a plane to the value of .

Solution

Stepwise implementation of the Problem in Julia code.

```{julia}
1using Random
2using Distributed
3Random.seed!(1275)
```

TaskLocalRNG()

```{julia}
"""
    toss_needle(d::Float64)

Generate a random point inside a semicircle with radius `d/2`.

Returns:
- A tuple `(x, θ)` where `x` is the distance from the center of the needle to the nearest line,
  and `θ` is the angle of the needle with the horizontal.
"""
function toss_needle(d::Float64)
1    x = rand() * d / 2
2    θ = rand() * π
    return x, θ
end
```

Main.Notebook.toss_needle

```{julia}
"""
    cross_line(x::Float64, θ::Float64, L::Float64)

Check if a point `(x, θ)` crosses a line parallel to the x-axis with a distance `L/2` from the center.

Returns:
- `true` if the needle crosses the line, otherwise `false`.
"""
function cross_line(x::Float64, θ::Float64, L::Float64)
1    return x <= (L / 2) * sin(θ)
end
```

Main.Notebook.cross_line

```{julia}
"""
    estimate_pi_par(nb_tosses::Int64, L::Float64, d::Float64)

Estimate π using Buffon's Needle method.

Args:
- `nb_tosses`: The number of random tosses to perform.
- `L`: The length of the needle.
- `d`: The distance between the lines.

Returns:
- An estimate of π based on the number of times the needle crosses a line.
"""
function estimate_pi_par(nb_tosses::Int64, L::Float64, d::Float64)
1    nb_crosses = @distributed (+) for _ in 1:nb_tosses
2        x, θ = toss_needle(d)
3        cross_line(x, θ, L) ? 1 : 0
    end
4    return (2 * L * nb_tosses) / (d * nb_crosses)
end
```

Main.Notebook.estimate_pi_par

```{julia}
# Parameters
L = 1.0  # Length of the needle
d = 2.0  # Distance between the lines
nb_tosses = 1_000_000  # Number of tosses

```

1000000

```{julia}
# Estimate π
π_estimate = estimate_pi_par(nb_tosses, L, d)
println("Estimated π: $π_estimate")
```

Estimated π: 3.1456828648362984