mcp-api-proxy

Call API endpoint

call_endpoint

Destructive

Send HTTP requests to Danske Bank Premium APIs via the MCP proxy, which adds OAuth/mTLS authentication and validates endpoint URLs for sandbox and live calls.

Instructions

Execute a request against a Danske Bank API. Only Premium APIs are supported (client_credentials grant, no PSD2 consent flows). Tiers: mock = mock-api.danskebank.com (sample data, no auth). Default tier: mock. HOW TO BUILD url: in the API's OpenAPI spec, pick the servers entry of the tier you call: the entry whose host is that tier's host above, whatever its position in the list (mock is often first). Append the operation path to the path of that entry. Example: entry https://api.danskebank.com/corporate/api + operation /v1/accounts/list → url /corporate/api/v1/accounts/list. The operation path alone returns 404. A full URL also works if it is https:// on the tier's host, without port or credentials. The proxy adds the client certificate and bearer token for sandbox and live. Results include the resolved tier, status, headers and body as structuredContent and matching JSON text. Only HTTP 2xx is API success; a redirect is not success. HTTP 400 and above sets isError with error.category, error.retryable and error.nextStep. Check the expected response body before reporting business success.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "method": "<method>",
      "url": "<url>"
    },
    "name": "call_endpoint"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Request path: the path of the OpenAPI `servers` entry for the target tier, followed by the operation path. Pick the entry whose host is the tier's host in the tool description, whatever its position in the list. Example: entry `https://api.danskebank.com/corporate/api` and operation `/v1/accounts/list` give `/corporate/api/v1/accounts/list`. The operation path alone returns 404. A full URL is accepted only as https:// on the tier's host, without port or credentials.
`body`	No	Request body for POST/PUT/PATCH
`tier`	No	Target tier: live (real data), sandbox (test data) or mock (sample data). Omit it to use the default tier named in the tool description. Choose mock or sandbox only when the user asks to test.
`method`	Yes	HTTP method
`headers`	No	Optional extra headers. Authorization and Content-Type are added automatically — do NOT include them here.
`queryParams`	No	Query string parameters

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 3, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the annotations it discloses that the proxy injects the client certificate and bearer token for sandbox/live, that redirects are not success, that HTTP >=400 sets isError with error.category/retryable/nextStep, and that results carry resolved tier, status, headers and body. It never mentions that DELETE/PUT/PATCH can mutate or destroy live data, which the destructiveHint=true annotation implies but the description leaves implicit.

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?

Dense and front-loaded with the scope constraint, tier info, then url construction, then error semantics. However the url-building rule is largely duplicated between the description and the `url` schema field, and phrases like "whatever its position in the list (mock is often first)" add length without new actionable content.

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?

An output schema exists and the description still usefully summarizes return shape and error fields, and it covers the tier default and url pitfall that would otherwise cause silent 404s. The gap is the missing host values for sandbox and live tiers, which the url instruction depends on.

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% so baseline is 3, but the description adds meaning not in the schema: the concrete mock host (mock-api.danskebank.com) and the statement that the default tier is mock, which the `tier` parameter description defers to. It does not supply sandbox/live hosts, so the url construction for those tiers still relies on the spec.

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 opens with a specific verb and resource ("Execute a request against a Danske Bank API") and immediately narrows scope to Premium APIs with client_credentials, excluding PSD2 consent flows. An agent knows exactly what class of operation this is before touching the schema.

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?

Explicit routing rules: default tier is mock, use mock/sandbox "only when the user asks to test", and the url must be built from the servers entry matching the tier host because "the operation path alone returns 404". It also states the success criterion (only 2xx) and instructs the agent to verify the response body before reporting business success.

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

Deploy Server

Other Tools

call_endpointA