Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fortnox Doc MCP show me the documentation for the GET /3/invoices endpoint"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for exploring Fortnox API documentation. Provides 377 Fortnox API endpoints documentation from the official OpenAPI specification.
Documentation-only server - provides API endpoint information, doesn't make API calls
377 Fortnox API endpoints from official OpenAPI 3.0 spec
7 MCP tools for exploring API documentation
No authentication required - pure documentation browsing
AI-optimized responses with structured markdown formatting
Related MCP server: Apidog MCP Server
npm install -g fortnox-doc-mcpOr use with npx:
npx fortnox-doc-mcpget_api_overview - Get API overview, statistics, and recommended workflow
list_all_endpoints - Browse all Fortnox API endpoints (with optional filters)
get_endpoint_details - Get full documentation for a specific endpoint
get_endpoints_by_resource - Get all endpoints for a resource grouped by operation
search_endpoints - Search endpoints by keyword
list_resource_groups - List all 81 API resource categories
get_schema_details - View data model schemas
Add to your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"fortnox-docs": {
"command": "npx",
"args": ["-y", "fortnox-doc-mcp"]
}
}
}Restart Claude Desktop to access the tools.
{
"servers": {
"fortnox-doc-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "fortnox-doc-mcp"]
}
}
}Once configured, you can ask AI assistants:
"Give me an overview of the Fortnox API" → Uses get_api_overview
"List all Fortnox customer endpoints" → Uses get_endpoints_by_resource
"Show me details for GET /3/customers" → Uses get_endpoint_details
"Search for invoice endpoints" → Uses search_endpoints
"What resource groups are available?" → Uses list_resource_groups
"Show me the Customer schema" → Uses get_schema_details
# Clone repository
git clone https://github.com/yourusername/fortnox-doc-mcp.git
cd fortnox-doc-mcp
# Install dependencies
npm install
# Build
npm run build
# Test
npm testfortnox-doc-mcp/
├── src/
│ ├── index.ts # MCP server with 7 tools
│ ├── openapi-parser.ts # OpenAPI spec parser
│ └── test-docs.ts # Documentation test
├── openapi (1).json # Fortnox OpenAPI specification
└── dist/ # Compiled JavaScriptOpenAPI Version: 3.0.3
Endpoints: 377 Fortnox API endpoints
Resource Groups: 81 categories
Loading: Singleton pattern (loaded once into memory)
Performance: O(1) endpoint lookups, no external API calls
Node Version: 18+
Q: Do I need a Fortnox API token?
A: No! This is a documentation server. No API credentials required.
Q: Can this make API calls to Fortnox?
A: No. It only provides documentation about endpoints from the OpenAPI spec.
Q: How do I use this with Claude Desktop?
A: Add the configuration to claude_desktop_config.json and restart Claude Desktop.
Q: Can I use this to build a Fortnox integration?
A: Yes! Use this to explore API documentation, understand endpoints, parameters, and schemas before building your integration.
MIT
Get comprehensive overview of the Fortnox API including base URL, authentication requirements, rate limits, and available resource groups. Use this FIRST to understand the API before exploring specific endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read operation by saying 'Get comprehensive overview' and lists what is returned, but could explicitly state it has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and follow with usage guidance. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is fairly complete by specifying what the overview includes. However, it might be enhanced by mentioning the format or that it is read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds meaning by specifying the content of the overview (base URL, auth, etc.), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a comprehensive overview of the Fortnox API, listing specific elements (base URL, authentication, rate limits, resource groups). This distinguishes it from siblings like get_endpoint_details and list_resource_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this FIRST to understand the API before exploring specific endpoints', providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete documentation for a specific endpoint including: description, parameters (path/query), request body schema, response schema, required vs optional fields. Essential for understanding how to use an endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The API endpoint path exactly as shown in list_all_endpoints (e.g., /3/customers, /3/invoices/{DocumentNumber}) | |
| method | Yes | The HTTP method (must match exactly) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description indicates a read-only retrieval of documentation. It does not elaborate on permissions, side effects, or limitations. Adequate for a safe, informational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and content, second emphasizes utility. No fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description sufficiently details what the response includes. The list of contents covers typical documentation needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds context by noting the path should match list_all_endpoints output, providing extra guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves documentation for a specific endpoint, listing included details (description, parameters, schemas). It distinguishes from siblings like list_all_endpoints (lists endpoints) and get_schema_details (schema-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Essential for understanding how to use an endpoint,' implying use when endpoint details are needed. It does not explicitly exclude cases or mention alternatives, so guidance is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all endpoints for a specific resource (e.g., all Customer endpoints, all Invoice endpoints). Returns grouped operations (list, create, get, update, delete) for easier understanding.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | Resource name (e.g., Customers, Invoices, Orders). Use list_resource_groups to see all available resources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are grouped by CRUD operations, but does not mention authorization, rate limits, or potential side effects. For a read-only tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with the core action and examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description covers the essential: what it does, what to expect (grouped operations), and how to find valid inputs. Sibling tools cover other endpoint queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'resource' has 100% schema description. The description adds value by pointing to 'list_resource_groups' for discovering available resources, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'endpoints', and specifies the grouping behavior. Examples (Customer, Invoice) make it immediately understandable. This differentiates it from siblings like 'list_all_endpoints' which likely does not group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific resource but does not explicitly state when not to use or mention alternatives like 'search_endpoints' or 'list_all_endpoints'. It lacks explicit context for choosing this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema information for a specific data model referenced in the API.
| Name | Required | Description | Default |
|---|---|---|---|
| schemaName | Yes | The schema name (e.g., fortnox_Customer, fortnox_Invoice) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states a read operation without disclosing idempotency, authentication needs, or what 'detailed' means. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-front-loaded sentence with zero unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter and no output schema, the description is adequate but lacks details about what the response contains or any prerequisites. It meets minimum viability but could expand on output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for schemaName. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed schema information for a specific data model, using a specific verb and resource reference. It differentiates from sibling tools like get_endpoint_details by focusing on schema data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_endpoint_details or get_api_overview. No context about prerequisites or return format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 377 Fortnox API endpoints with method, path, summary, and resource tags. Supports filtering by HTTP method or resource group. Returns a comprehensive catalog of available endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Optional: Filter by HTTP method (GET, POST, PUT, DELETE, PATCH) | |
| tag | No | Optional: Filter by resource group (e.g., fortnox_Customers, fortnox_Invoices). Use list_resource_groups to see all available tags. | |
| limit | No | Optional: Limit number of results (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only states it returns a catalog, no mention of side effects, authentication, or rate limits. Basic but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers returned fields (method, path, summary, tags) and filtering; lacks pagination details but mentions limit parameter default appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds value by hinting at list_resource_groups for tag parameter, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all 377 Fortnox API endpoints' with specific verb and resource, and distinguishes from siblings like get_endpoint_details by being a comprehensive listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage through filtering options and mention of list_resource_groups, but lacks explicit when to use vs. alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 81 resource groups in the Fortnox API with endpoint counts. Resource groups represent different business entities (Customers, Invoices, Products, etc.). Use this to discover what resources are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it lists all 81 groups and includes endpoint counts, which is sufficient behavioral information for a read-only discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the action and result, the second explains the purpose. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the output includes endpoint counts. It is complete for a simple list tool, and the sibling tool names indicate it fits well in the toolkit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. Baseline for 0 params is 4. The description does not need to add parameter semantics, and it correctly focuses on output characteristics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all 81 resource groups with endpoint counts, and gives examples of business entities (Customers, Invoices). It distinguishes itself from sibling tools that deal with specific endpoints or schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover what resources are available,' which is clear usage guidance. While it does not provide when-not or alternatives, the context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all endpoints by keyword. Searches in: path, summary, description, and tags. Returns ranked results. Use this when you know what you want to do but not the exact endpoint name.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword (e.g., "customer", "invoice", "payment", "bookkeep", "email") | |
| limit | No | Optional: Maximum number of results to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns ranked results and searches multiple fields, adding behavioral context beyond the schema. No annotations are provided, so the description carries the burden, and it does so adequately without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value: scope, fields searched, ranking, and usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema) and sibling context, the description covers purpose, scope, behavior, and usage guidance completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, but the description adds meaning by specifying which fields are searched (path, summary, description, tags), complementing the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across all endpoints by keyword, specifying the fields searched (path, summary, description, tags) and that it returns ranked results. It effectively distinguishes from siblings like list_all_endpoints and get_endpoint_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this when you know what you want to do but not the exact endpoint name,' providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3get_api_overviewget_endpoint_detailsget_endpoints_by_resourceget_schema_detailslist_all_endpointslist_resource_groupssearch_endpointsScored across 7 tools
Each tool has a distinct purpose: overview, resource groups, all endpoints, search, endpoint details, endpoints by resource, and schema details. No overlap in functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_resource_groups, get_endpoint_details), making them predictable and clear.
7 tools is perfectly scoped for a documentation exploration server, covering all necessary operations without excess or deficiency.
The set provides full coverage for API documentation discovery: overview, resource listing, endpoint cataloging, search, detailed endpoint info, resource-grouped endpoints, and schema details. No obvious gaps.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Search the Final POS REST API documentation.
Anonymous read and search over the published nowyourlink developer documentation.
Versioned documentation registry and semantic search for AI tools and coding assistants.
