Skip to main content
Glama
RemseyMailjard

Rabobank MCP Server Training

by RemseyMailjard
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Rabobank MCP-Server Training

Welcome to the Rabobank MCP-Server Training repository. This project contains a fully functional demo Model Context Protocol (MCP) server built with TypeScript that you can use as a starting point during the training.

What is MCP?

The Model Context Protocol is an open standard that allows AI assistants (like GitHub Copilot and Claude) to call external tools and data sources in a structured, secure way. An MCP server exposes tools, resources, and prompts that any MCP-compatible client can discover and invoke.

┌──────────────┐   MCP (stdio/SSE)   ┌─────────────────────┐
│  AI Client   │ ◄──────────────────► │  Demo MCP Server    │
│ (Copilot /   │                      │  (this repository)  │
│  Claude …)   │                      └─────────────────────┘
└──────────────┘

Related MCP server: mcp-server-demo

Demo tools included

Tool

Description

get_exchange_rate

Returns a (mocked) EUR exchange rate for a given currency code

calculate_mortgage

Calculates the monthly mortgage payment given principal, annual rate and term

get_branch_info

Returns contact details for a mock Rabobank branch

Prerequisites

  • Node.js v18 or higher

  • npm (comes with Node.js)

Quick start

# 1. Clone the repository
git clone https://github.com/RemseyMailjard/rabobank-mcp-server-training.git
cd rabobank-mcp-server-training

# 2. Install dependencies
npm install

# 3. Build
npm run build

# 4. Run (stdio)
node build/index.js

Use with VS Code (GitHub Copilot)

The .vscode/mcp.json file is already configured. Open the project in VS Code and Copilot will automatically discover the server.

Use with Claude for Desktop

Add the following entry to your claude_desktop_config.json:

{
  "mcpServers": {
    "rabobank-demo": {
      "command": "node",
      "args": ["C:\\path\\to\\rabobank-mcp-server-training\\build\\index.js"]
    }
  }
}

Project structure

rabobank-mcp-server-training/
├── src/
│   └── index.ts          # MCP server implementation
├── build/                # Compiled output (after npm run build)
├── .vscode/
│   └── mcp.json          # VS Code MCP configuration
├── .github/
│   └── copilot-instructions.md
├── package.json
├── tsconfig.json
└── README.md

Exercises

During the training you will:

  1. Explore the existing tools in src/index.ts and understand how they are registered.

  2. Add a new tool – e.g. get_interest_rate that returns savings account interest rates.

  3. Add a resource – expose a static JSON file with product information.

  4. Add a prompt – create a reusable prompt template for a customer service scenario.

  5. Connect the server to GitHub Copilot Chat or Claude for Desktop and test the tools interactively.

Useful links

Available Tools

3 tools
calculate_mortgageA

Calculates the monthly mortgage (annuity) payment given a principal, an annual interest rate and a loan term in years.

ParametersJSON Schema
NameRequiredDescriptionDefault
principalYesLoan principal in euros (e.g. 300000)
termYearsYesLoan term in years (e.g. 30)
annualRatePercentYesAnnual interest rate as a percentage (e.g. 4.5 for 4.5%)

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, so the description carries full burden. It indicates this is a calculation tool with no destructive side effects. It specifies 'annuity' payment, adding context beyond the schema. However, it does not disclose the exact output format or any rounding behavior.

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 a single concise sentence that front-loads the verb 'Calculates'. It is efficient but could include more detail about the output or assumptions without becoming verbose.

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?

For a simple calculation tool with three well-described parameters and no output schema, the description is fairly complete. It covers the inputs and what the tool does, but could explicitly state the output (monthly payment) and assumptions (e.g., fixed rate, monthly compounding).

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%, so baseline is 3. The description repeats the parameter names (principal, annual interest rate, loan term) but does not add new details beyond the schema's own descriptions. No additional clarification on units or format.

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 calculates monthly mortgage payment using principal, interest rate, and term. It is distinct from sibling tools (get_branch_info, get_exchange_rate) which cover unrelated domains.

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 does not explicitly state when to use this tool versus alternatives, but the sibling tools are clearly different (branch info and exchange rates), so the usage context is implied. No exclusions or prerequisites are mentioned.

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

get_branch_infoA

Returns contact information for a Rabobank branch. Available branches: amsterdam, utrecht, rotterdam, eindhoven.

ParametersJSON Schema
NameRequiredDescriptionDefault
branchYesBranch name (lowercase)

TDQS

A3.8/5.0
Behavior3/5

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

Describes return type ('contact information') but as a simple lookup, it's likely read-only; no explicit mention of side effects, but annotations are absent, so description carries the burden.

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?

Two sentences: front-loaded with purpose, then efficiently lists options. No wasted words.

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?

Adequate for a simple one-parameter read-only tool; output format could be more explicit, but 'contact information' suffices.

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 already covers the single parameter with enum and description; the description reiterates available branches without adding beyond 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?

Clearly states the tool returns contact information for a Rabobank branch and lists the four specific branches, differentiating it from sibling tools like calculate_mortgage and get_exchange_rate.

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?

Implies use when needing branch contact info, but does not provide when-not-to-use or alternatives; no explicit guidance on context.

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

get_exchange_rateA

Returns the current EUR exchange rate for a given currency code. Supported codes: USD, GBP, JPY, CHF, AUD, CAD, SEK, NOK, DKK.

ParametersJSON Schema
NameRequiredDescriptionDefault
currencyYesISO 4217 three-letter currency code (e.g. USD, GBP)

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It clearly indicates a read-only operation ('returns'). It does not mention authentication, rate limits, or error handling for unsupported codes, but for a simple query tool 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.

Conciseness5/5

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

The description is a single sentence plus a list of supported codes. No wasted words. Information is front-loaded and easy to parse.

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 description explains what the tool does and lists valid inputs. However, it does not specify the return format (e.g., numeric rate, JSON object) or behavior for invalid codes. Given the lack of output schema, slightly more detail would improve completeness.

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

Parameters4/5

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

Schema coverage is 100% with a description for the currency parameter. The description adds value by listing all supported currency codes (USD, GBP, JPY, etc.), which goes beyond the schema's example. This helps the agent avoid invalid inputs.

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 returns the current EUR exchange rate for a given currency code. The verb 'returns' and resource 'current EUR exchange rate' are specific. The sibling tools (calculate_mortgage, get_branch_info) are unrelated, so no confusion.

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 implicitly indicates when to use (when needing EUR exchange rates for supported codes) but does not explicitly exclude alternatives. Since siblings are unrelated, explicit guidance is less critical. The list of supported codes provides constraints.

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.

  1. 3 tool updatesv1.0.0
    • First observedcalculate_mortgage
    • First observedget_branch_info
    • First observedget_exchange_rate
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct function: mortgage calculation, branch info, and exchange rate. No overlap or ambiguity.

Naming Consistency5/5

All tools use a consistent verb_noun pattern (calculate_mortgage, get_branch_info, get_exchange_rate).

Tool Count4/5

3 tools is slightly low but appropriate for a focused training server. Each tool serves a clear purpose without unnecessary complexity.

Completeness4/5

The set covers core banking demo scenarios (mortgage, branch, exchange). Minor gaps like account management exist but are not critical for the training scope.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Local Financial MCP Mock

    beprith
    A
    license
    Not graded
    quality
    D
    maintenance
    A lightweight MCP server that simulates financial data interactions with dummy authentication and static JSON datasets for testing financial applications.
    2
    MIT

  • Quick Demo MCP Server

    Haimantika
    A
    license
    Not graded
    quality
    D
    maintenance
    A simple MCP server that provides a tool to get the current server time and a resource with demo information, useful for testing MCP functionality.
    2,013
    MIT

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/RemseyMailjard/rabobank-mcp-server-training'

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