n8n MCP Server

get_credentials

List all credential names stored in n8n to view available integrations without exposing sensitive data.

Instructions

List available credentials (names only, no sensitive data)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_credentials"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Implementation Reference

src/n8n-client.ts:160-163 (handler)
Actual implementation: calls n8n API GET /api/v1/credentials and returns the response data.
```
async getCredentials() {
  const response = await this.client.get("/api/v1/credentials");
  return response.data;
}
```
src/handlers.ts:157-159 (handler)
Handler dispatcher: routes the 'get_credentials' tool call to N8nClient.getCredentials()
```
case "get_credentials": {
  return await client.getCredentials();
}
```

src/tools.ts:307-313 (schema)

Tool schema/registration definition: name, description, and input schema (no parameters required).

{
  name: "get_credentials",
  description: "List available credentials (names only, no sensitive data)",
  inputSchema: {
    type: "object",
    properties: {},
  },

src/index.ts:23-32 (registration)

The tools array (including get_credentials) is registered via ListToolsRequestSchema handler in the MCP server.

);

// Initialize n8n client
const n8nClient = new N8nClient(
  process.env.N8N_URL || "http://localhost:5678",
  process.env.N8N_API_KEY || ""
);

// Register tool list handler
server.setRequestHandler(ListToolsRequestSchema, async () => {

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0May 4, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the key safety trait that no sensitive data is returned, which is valuable. However, it omits other behavioral aspects like authentication requirements, read-only nature, or behavior with no credentials.

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 that contains all essential information. There is no waste, and it is appropriately front-loaded with the core purpose.

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

Completeness3/5

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

For a simple tool with no parameters and no output schema, the description adequately states the purpose and a key constraint. However, it lacks hints about return format (e.g., list of strings) or potential pagination, leaving some context missing.

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?

The tool has zero parameters, so schema coverage is 100%. The description adds no parameter-specific information, which is acceptable as there are none. Baseline 4 for zero parameters is appropriate.

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 that the tool lists available credentials and explicitly states it returns only names without sensitive data. It is specific about the verb and resource, and effectively distinguishes itself from sibling tools by focusing on credentials.

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?

The description implies usage when a list of credential names is needed without sensitive data, but it does not provide explicit when-to-use or when-not-to-use guidance. Given no sibling credential tools, the lack of alternatives is less critical, but explicit context would improve clarity.

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