How do I use bexio-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bexio-mcp list my last 10 contacts" 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.

bexio-mcp

by valmiremini

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

bexio MCP Server

English · Deutsch

A standalone Model Context Protocol (MCP) server for the bexio REST API. Usable from any MCP client — Claude Desktop, Claude Code, n8n and others.

The server depends on nothing but a bexio API token. No database, no framework, no host application.

Transports

Transport	For	Enable
stdio (default)	Claude Desktop, Claude Code, CLI clients	`MCP_TRANSPORT=stdio` (default)
HTTP (Streamable HTTP)	n8n, remote clients, Docker	`MCP_TRANSPORT=http` or arg `http`

Related MCP server: Moxie CRM MCP Server

Available tools (21)

Tool	Description
`bexio_list_contacts` / `_invoices` / `_quotes` / `_orders` / `_items` / `_projects`	List with pagination (`limit`, `offset`, `order_by`)
`bexio_get_contact` / `_invoice` / `_quote` / `_order` / `_item` / `_project`	Single record by `id`
`bexio_search_contacts` / `_invoices` / `_quotes` / `_orders` / `_items` / `_projects`	Search with field criteria (POST `/search`)
`bexio_get_company_profile`	Company profile of the account
`bexio_create_contact`	Create a contact (company or person)
`bexio_request`	Generic call for any bexio endpoint

bexio_request reaches every endpoint of the API (e.g. /3.0/banking/accounts, /2.0/taxes, /2.0/kb_invoice/{id}/payment) and thus covers the entire API surface.

Example: search

{
  "criteria": [{ "field": "name_1", "value": "Muster", "criteria": "like" }],
  "limit": 50
}

Operators: =, !=, >, <, >=, <=, like, not_like, is_null, not_null, in, not_in.

Installation

cd bexio-mcp
npm install
npm run build
cp .env.example .env   # set BEXIO_API_TOKEN

Create a token: bexio → Settings → API & Webhooks → API tokens. The token's scope determines which resources are readable/writable (e.g. contact_show, kb_invoice_show).

Claude Desktop (stdio)

claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "bexio": {
      "command": "node",
      "args": ["/absolute/path/bexio-mcp/dist/index.js"],
      "env": { "BEXIO_API_TOKEN": "your-token-here" }
    }
  }
}

Claude Code (stdio)

claude mcp add bexio --env BEXIO_API_TOKEN=your-token -- node /absolute/path/bexio-mcp/dist/index.js

n8n (HTTP)

n8n speaks MCP over HTTP. Start the server in HTTP mode — easiest via Docker:

# fill .env with BEXIO_API_TOKEN and MCP_HTTP_TOKEN, then:
docker compose up -d --build

Or without Docker:

MCP_TRANSPORT=http MCP_HTTP_TOKEN=secret BEXIO_API_TOKEN=... node dist/index.js

In the n8n workflow, add the "MCP Client Tool" node:

Endpoint / SSE URL: http://<host>:3000/mcp (when n8n is on the same Docker network, e.g. http://bexio-mcp:3000/mcp)
Transport: HTTP Streamable
Authentication / Header: Authorization: Bearer secret (value of MCP_HTTP_TOKEN)

Liveness check: GET http://<host>:3000/health → {"status":"ok"}.

Manual test of the HTTP endpoint

curl -X POST http://localhost:3000/mcp \
  -H 'Authorization: Bearer secret' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Environment variables

Variable	Default	Purpose
`BEXIO_API_TOKEN`	— (required)	bexio PAT or OAuth2 access token
`BEXIO_API_BASE_URL`	`https://api.bexio.com`	API base URL
`MCP_TRANSPORT`	`stdio`	`stdio` or `http`
`MCP_HTTP_PORT` / `PORT`	`3000`	Port in HTTP mode
`MCP_HTTP_HOST`	`0.0.0.0`	Bind host in HTTP mode
`MCP_HTTP_TOKEN`	—	If set: required bearer token for `/mcp`

Development

npm run watch     # TypeScript watch mode
npm run inspect   # MCP Inspector (interactive tool testing)

Security

The bexio token grants full API access within its scopes — never commit it (.env and dist/ are in .gitignore).
In HTTP mode always set MCP_HTTP_TOKEN when the port is reachable. Without it, /mcp is open — and so is your bexio account.

Privacy

This server stores no data. It forwards requests unchanged to the bexio REST API and returns the responses to the MCP client. There is no database, no logging of payload data, and no sharing with third parties. Processing of your bexio data is governed solely by bexio's privacy policy.

License

Disclaimer & trademarks

This is an unofficial, independent open-source project. It is not affiliated with, endorsed by, sponsored by, or approved by bexio AG.

"bexio" is a trademark of bexio AG. All trademark and product names are the property of their respective owners and are used here solely for identification purposes.

The software is provided "as is", without warranty of any kind (see LICENSE). Use of the bexio API is at your own risk and subject to bexio AG's terms of use. The author accepts no liability for any damage or data loss arising from the use of this server.

Available Tools

21 tools

bexio_create_contactCreate a contactB

Create a contact in bexio (POST /2.0/contact). contact_type_id 1 = company, 2 = person. For a person, set name_1 = last name and name_2 = first name.

ParametersJSON Schema

Name	Required	Description
`city`	No
`mail`	No
`extra`	No	Any additional bexio contact fields to merge into the payload.
`name_1`	Yes	Company name, or last name for a person.
`name_2`	No	First name for a person.
`address`	No
`user_id`	No	Owner user id (required by some bexio accounts).
`postcode`	No
`country_id`	No	bexio country id (1 = Switzerland).
`phone_fixed`	No
`phone_mobile`	No
`contact_type_id`	Yes	1 = company, 2 = person.

TDQS

B3.2/5.0

Behavior2/5

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 explains the basic creation action and parameter mapping but lacks details on side effects, permissions, error behavior, or return value. The description is minimal for a create operation.

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 two sentences, front-loads the main action, and contains no fluff. Every sentence adds value.

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

Completeness2/5

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

Given 12 parameters, a nested object, and no output schema, the description fails to cover key aspects like the extra object, address fields, or return value. It is incomplete for a complex tool.

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 50%. The description adds meaning for contact_type_id (1=company, 2=person) and clarifies name_1/name_2 for person vs company, which goes beyond the schema. However, it does not cover many other parameters.

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 creates a contact in bexio, with the HTTP endpoint. It distinguishes from sibling tools (which are read/list/search), so there is 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 Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides specific parameter usage (contact_type_id mapping and name fields for person vs company), but it does not explicitly state when to use this tool vs alternatives or when not to use it. No mention of prerequisites or context.

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

bexio_get_company_profileGet company profileA

Fetch the bexio company profile(s) of the authenticated account (GET /2.0/company_profile).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It indicates a read-only 'fetch' operation and specifies the API endpoint, but does not disclose potential side effects, rate limits, or authentication details beyond being for the authenticated account.

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, concise sentence that immediately conveys the tool's purpose and the API endpoint. No unnecessary words or redundancy.

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, parameterless tool, the description provides the resource and scope. It mentions 'company profile(s)' correctly allowing for multiple profiles. No output schema exists, so return format is not required, but missing details like data format (JSON) are minor omissions.

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?

There are no parameters in the input schema, so the description cannot add meaning beyond the schema. Following the rule '0 params = baseline 4', this score 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 'Fetch the bexio company profile(s) of the authenticated account', specifying the verb (Fetch), resource (company profile), and scope (authenticated account). It distinguishes from sibling tools that operate on contacts, invoices, items, orders, projects, and quotes.

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?

No explicit guidance on when to use this tool versus alternatives. However, the purpose is self-explanatory given the tool name and description, and siblings are for different resources, so usage context is implied but not stated.

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

bexio_get_contactGet a contactB

Fetch a single contact by id (GET /2.0/contact/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The contact id.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions the HTTP method and endpoint. It does not disclose behavioral traits such as authentication requirements, rate limits, or error behavior (e.g., what if id not found).

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, front-loaded sentence that is efficient. However, it could include a bit more context without being verbose.

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 GET tool with one parameter and no output schema, the description covers the basic purpose. However, it lacks details on the return format, error handling, or any prerequisites, which could be important for a complete understanding.

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?

The input schema has 100% description coverage for the single parameter 'id', so the description adds no additional meaning beyond what the schema already provides. Baseline 3 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 'Fetch a single contact by id', with a specific verb and resource, and includes the API endpoint. It distinguishes from siblings like bexio_list_contacts and bexio_search_contacts.

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 single contact id is known, but does not explicitly state when to use this tool vs alternatives, nor when not to use it.

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

bexio_get_invoiceGet a invoiceB

Fetch a single invoice by id (GET /2.0/kb_invoice/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The invoice id.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It only mentions the API endpoint but does not disclose error handling, authentication requirements, or the read-only nature. Minimal behavioral disclosure.

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 with no extraneous information. It is appropriately concise for a simple tool.

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 fetch tool with one parameter and no output schema, the description is mostly complete. It could mention the return value (e.g., invoice details), but simplicity makes this acceptable.

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 coverage is 100% with one parameter 'id' documented. The description reinforces the parameter's role by stating 'by id', but adds no additional meaning beyond the 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?

The description clearly states the action ('Fetch'), the resource ('invoice'), and the identifier method ('by id'), which distinguishes it from sibling tools like bexio_search_invoices or bexio_list_invoices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., search_invoices, list_invoices). The description simply states what it does without context for selection.

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

bexio_get_itemGet a itemB

Fetch a single item by id (GET /2.0/article/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The item id.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description only states fetch operation with no details on authentication, rate limits, idempotency, or error conditions. The endpoint implies read-only, but not explicit.

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?

Very concise single sentence with endpoint. No unnecessary words, though could include more context.

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

Completeness2/5

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

No output schema. Description does not explain return format, error handling, or what to expect from a single item fetch. Agent lacks information to handle responses correctly.

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 coverage is 100%. Description mentions 'by id' but does not add meaning beyond the schema's parameter description. Baseline score of 3 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?

Clearly states 'Fetch a single item by id', specifying the verb, resource, and scope. Distinguishes from sibling tools like bexio_list_items and bexio_search_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like list or search. Does not mention prerequisites or limitations.

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

bexio_get_orderGet a orderB

Fetch a single order by id (GET /2.0/kb_order/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The order id.

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It mentions it's a GET request, implying safety, but does not specify what happens if the order ID does not exist, authentication requirements, or rate limits. This is 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.

Conciseness4/5

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

The description is a single sentence that front-loads the action (fetch) and resource (order). It is concise and to the point, but could potentially include a bit more detail without becoming verbose.

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?

Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is adequate for understanding its core functionality. However, it does not describe the return format or any potential error conditions, leaving some gaps in completeness.

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?

The schema already provides 100% coverage, describing the 'id' parameter as 'The order id.' The description adds no additional semantic meaning beyond the schema, so a baseline score of 3 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 'Fetch a single order by id', specifying the action and resource. It distinguishes itself from sibling tools like list_orders (multiple) and search_orders (search) by focusing on a single order retrieval.

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 for fetching a specific order by id, but it does not provide explicit guidance on when to use it versus alternatives like searching or listing orders. It assumes the user knows to use this when an order ID is known.

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

bexio_get_projectGet a projectA

Fetch a single project by id (GET /2.0/pr_project/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The project id.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It only states it's a GET request, but lacks details on authentication, rate limits, or error handling. Minimal beyond basic fetch.

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?

Single sentence, no wasted words, front-loaded with key information.

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 fetch-by-ID tool, the description is adequate. No output schema, but return value is implied. Sibling tools provide context. Could mention return format for completeness.

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 coverage is 100% with parameter 'id' already described. Description adds API endpoint but no extra parameter meaning. Baseline 3 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?

Clearly specifies verb 'Fetch', resource 'a single project', and distinguishes from sibling tools like bexio_list_projects and bexio_search_projects. Includes API endpoint for precision.

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?

Implies usage when needing a specific project by ID, but does not explicitly exclude scenarios or mention alternatives. Siblings like list and search provide contrast.

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

bexio_get_quoteGet a quoteA

Fetch a single quote by id (GET /2.0/kb_offer/{id}).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The quote id.

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the burden. It reveals that this is a read operation (GET endpoint) with no side effects, which is sufficient for a simple retrieval tool. However, it does not mention auth requirements or rate limits, but those are typical for API tools.

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?

A single, front-loaded sentence that efficiently conveys purpose and endpoint. Every word earns its place, with no unnecessary details.

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

Completeness5/5

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

For a simple retrieval tool with one parameter and no output schema, the description is complete. It covers the operation, endpoint, and parameter, leaving no ambiguity for an agent.

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% with the 'id' parameter already well-described. The description adds no additional meaning beyond what the schema provides ('by id' matches the schema). Baseline score of 3 applies.

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 fetches a single quote by ID, with the specific endpoint (GET /2.0/kb_offer/{id}). It distinguishes well from sibling tools like bexio_list_quotes (bulk retrieval) and bexio_search_quotes (filtered search).

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 you have a specific quote ID, but it does not explicitly state when to prefer this over alternatives like bexio_list_quotes or bexio_search_quotes. No when-not or alternative guidance is provided.

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

bexio_list_contactsList contactsB

List contacts from bexio (GET /2.0/contact). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided. Description mentions HTTP method GET (implies read-only) and supports pagination, but does not explicitly state that it is a safe, non-destructive operation or disclose any other behavioral traits.

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?

Single sentence with three clear clauses (list contacts, API endpoint, features). No wasted words, but could be slightly more structured. Front-loaded well.

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?

Adequate for a simple list tool. No output schema, so description doesn't specify return format. Could mention that it returns an array of contact objects. Otherwise covers key aspects.

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 the input schema already documents each parameter. The description adds no additional meaning beyond what the schema provides, achieving the baseline.

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 verb 'List' and resource 'contacts', mentions the API endpoint and key features (pagination, ordering). Distinguishes from sibling tools like bexio_search_contacts and bexio_get_contact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like bexio_search_contacts for filtering or bexio_get_contact for a single record. Context signals show many siblings but description doesn't differentiate.

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

bexio_list_invoicesList invoicesB

List invoices from bexio (GET /2.0/kb_invoice). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses pagination and ordering behavior, but fails to mention return format, read-only nature, authentication requirements, or any 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.

Conciseness5/5

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

The description is a single, front-loaded sentence with no redundant information, achieving maximum conciseness.

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

Completeness2/5

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

Given no output schema and no annotations, the description is incomplete. It does not explain the return structure, error handling, or how it differs from 'search_invoices', leaving gaps for an AI agent.

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 coverage is 100%, so the baseline is 3. The description adds 'pagination and ordering' which is already evident from schema descriptions, providing no additional semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List invoices from bexio' with the API endpoint, providing a specific verb and resource. However, it does not explicitly differentiate from the sibling 'search_invoices' tool, which also deals with invoices.

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 mentions pagination and ordering, which implies when to use parameters, but lacks explicit guidance on when to use this tool versus alternatives like 'search_invoices' or 'get_invoice'.

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

bexio_list_itemsList items / articlesA

List items / articles from bexio (GET /2.0/article). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

A3.8/5.0

Behavior3/5

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 mentions pagination and ordering, which are behavioral traits, but does not mention read-only nature, authentication, or rate limits. However, being a list operation it is inherently non-destructive.

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 with no wasted words, front-loaded with purpose and endpoint information. Highly concise and structured.

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 is sufficiently complete for this simple list operation with 3 optional parameters. No output schema exists, but the return value (list of items) is implied by the tool name and description. Adequate for the tool's complexity.

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 coverage is 100%, so the schema already documents all parameters. The description adds context that pagination and ordering are supported, but does not add new meaning beyond the schema descriptions.

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 lists items/articles from bexio, with the specific API endpoint. It implicitly differentiates from sibling tool bexio_search_items by stating it lists all items.

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?

No explicit when-to-use or alternatives provided. The description implies pagination and ordering usage but does not guide the agent on when to use this list tool versus the search tool.

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

bexio_list_ordersList ordersA

List orders from bexio (GET /2.0/kb_order). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates pagination and ordering support but lacks details about read-only nature, rate limits, or any side effects. The GET endpoint implies read-only, but not explicitly stated.

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 front-loads the core purpose and key features (pagination, ordering). No superfluous 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?

For a list tool with 3 parameters and no output schema, the description adequately conveys the primary action and features. It could mention default behavior or return format but remains sufficient given the simplicity.

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 coverage is 100%, so the description adds minimal value beyond the schema. Mention of 'pagination and ordering' relates to parameters but does not provide new or deeper semantic context beyond what the schema already documents.

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 lists orders from bexio using a specific API endpoint, which distinguishes it from sibling tools like bexio_get_order (single order retrieval) and bexio_search_orders (search functionality).

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 mentions pagination and ordering but does not explicitly guide when to use this listing tool versus other order-related tools (e.g., get, search). The absence of usage context or exclusions leaves room for ambiguity.

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

bexio_list_projectsList projectsA

List projects from bexio (GET /2.0/pr_project). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

A3.7/5.0

Behavior3/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 adds the API endpoint (GET /2.0/pr_project) and notes pagination/ordering support. This is useful but does not disclose behavior beyond the schema (e.g., no mention of rate limits, error handling, or default limit).

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 immediately states the purpose and key features. Every word is necessary; no fluff or redundancy.

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 list endpoint with 3 parameters fully described in the schema, the description is minimally adequate. It covers the core actions (list, paginate, order) but lacks details like default/behavioral traits. Given no output schema, additional context about return format would improve completeness.

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 coverage is 100% and the input schema already describes all three parameters with clear descriptions. The description reinforces pagination and ordering but does not add new semantic meaning beyond the 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?

The description clearly states 'List projects from bexio' which is a specific verb (list) and resource (projects). It differentiates from sibling tools like bexio_get_project (single project) and bexio_search_projects (search) by using 'list' rather than 'get' or 'search'.

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 mentions 'Supports pagination and ordering', which implies the tool can handle large result sets and sort results, providing some guidance on when to use this tool. However, it does not explicitly state when to prefer list over search or provide context about use cases.

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

bexio_list_quotesList quotes / offersB

List quotes / offers from bexio (GET /2.0/kb_offer). Supports pagination and ordering.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided. The description only mentions the HTTP method (GET), implying read-only behavior, but does not disclose behavioral details such as authentication requirements, rate limits, or side effects. With no annotations, the description lacks sufficient transparency.

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 sentence, front-loaded with the key purpose. It is concise and to the point, though it could include more detail without becoming verbose.

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?

The tool has low complexity (list with pagination). The description covers pagination and ordering but does not explain the response format or filtering capabilities. With no output schema, additional context about returned fields would improve completeness.

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 coverage is 100%, so parameters are already described in the schema. The description adds 'Supports pagination and ordering,' which reinforces the parameter purposes but does not provide significant additional meaning.

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 action (list) and resource (quotes/offers) and includes the API endpoint (GET /2.0/kb_offer). It distinguishes from sibling tools like bexio_search_quotes by indicating a simple listing operation.

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 mentions pagination and ordering, but does not explicitly state when to use this tool versus alternatives (e.g., search). Usage context is implied but not clearly defined.

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

bexio_requestRaw bexio API requestA

Make an arbitrary authenticated request to the bexio API. Use this for any endpoint not covered by a dedicated tool (e.g. /3.0/banking/accounts, /2.0/user, /2.0/taxes, /2.0/kb_invoice/{id}/payment). See https://docs.bexio.com/ for the full reference.

ParametersJSON Schema

Name	Required	Description
`body`	No	JSON request body for POST/PUT/PATCH.
`path`	Yes	Path including version, e.g. `/2.0/contact` or `/3.0/banking/accounts`.
`query`	No	Query string parameters.
`method`	Yes	HTTP method.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only mentions that requests are authenticated but does not disclose potential side effects (e.g., mutations via POST/PUT/DELETE), rate limits, error handling, or response format. Given the tool can perform destructive operations, more transparency is needed.

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 only two sentences, concise and front-loaded with the core purpose, then usage guidance and reference. Every sentence adds value, 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?

Given it is a raw API request tool, the description adequately covers purpose, scope, and reference. It could mention that responses are raw JSON and that caution is needed for mutation methods, but these are somewhat implied. The absence of an output schema means the description could be more explicit about return value format.

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 the baseline is 3. The description adds little beyond what the schema already provides (method, path, body, query are all documented in the schema). The description gives example paths but does not add meaning to the parameters themselves.

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 makes arbitrary authenticated requests to the bexio API for endpoints not covered by dedicated tools, with specific path examples like /3.0/banking/accounts, /2.0/user. This distinguishes it from the many sibling tools dedicated to specific resources.

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?

Explicitly instructs to use for endpoints not covered by a dedicated tool, and provides a reference to the full API documentation. However, it does not explicitly state when not to use it (e.g., when a dedicated tool exists), though this is implied.

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

bexio_search_contactsSearch contactsB

Search contacts with field criteria (POST /2.0/contact/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the HTTP method (POST) and endpoint, but does not mention that this is a read-only operation, pagination behavior, or any side effects. It lacks transparency for an agent to understand its safety profile.

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, front-loaded sentence that efficiently conveys the tool's purpose with no unnecessary words.

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

Completeness2/5

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

With no output schema and no annotations, the description is too minimal. It does not explain the return format, pagination (though schema has limit/offset), or how results differ from a simple list. An agent lacks full context for correct use.

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 coverage is 100% with detailed parameter descriptions. The description adds no additional meaning beyond the schema, so it meets the baseline for well-documented parameters.

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 'Search contacts with field criteria', specifying the verb 'search' and resource 'contacts'. It distinguishes itself from sibling tools like bexio_list_contacts (which likely lists all contacts without criteria) and bexio_get_contact (single contact retrieval).

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 does not explicitly state when to use this tool versus alternatives like bexio_list_contacts or bexio_get_contact. While the name and sibling context imply it is for filtered searches, there is no direct guidance on choosing among similar tools.

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

bexio_search_invoicesSearch invoicesC

Search invoices with field criteria (POST /2.0/kb_invoice/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or potential side effects. The POST method implies data retrieval but no further details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single sentence, which is concise but lacks structure. It does not front-load key information or add any value beyond the tool name.

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

Completeness2/5

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

The description is incomplete for effective use. It does not describe the return format, pagination behavior, or any prerequisites. Given 4 parameters and no output schema, more context is needed.

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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides (e.g., 'field criteria' is already explained in the criteria parameter description).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (search), resource (invoices), and method (with field criteria). It distinguishes from bexio_list_invoices which likely lacks filtering capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 siblings like bexio_list_invoices or bexio_get_invoice. The description does not mention prerequisites or exclusions.

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

bexio_search_itemsSearch items / articlesB

Search items / articles with field criteria (POST /2.0/article/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only states the endpoint and basic action, omitting any information about read-only nature, authentication requirements, rate limits, or side effects. This lack of detail makes it hard for an agent to anticipate tool 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 extremely concise, consisting of a single sentence that includes the action, resource, and endpoint. It is front-loaded and contains no extraneous information, though it could benefit from slightly more context without sacrificing conciseness.

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

Completeness2/5

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

Given the tool has 4 parameters with no output schema, the description is incomplete. It fails to mention the return format, pagination behavior, or provide usage examples. While the schema covers parameter details, the description itself lacks sufficient context for an agent to fully understand the tool's usage.

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?

The input schema has 100% coverage with detailed descriptions for all parameters. The description adds no additional parameter semantics beyond what the schema provides, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search') and resource ('items / articles') along with the HTTP endpoint. However, it does not differentiate from sibling tools like bexio_list_items or bexio_search_contacts, which could cause confusion about when to use this specific tool.

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 that this tool is used for searching items with field criteria, but it does not explicitly state when to use this tool versus alternatives (e.g., bexio_list_items for listing without criteria). 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.

bexio_search_ordersSearch ordersC

Search orders with field criteria (POST /2.0/kb_order/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

C2.6/5.0

Behavior1/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions the HTTP method and endpoint, omitting any details about rate limits, idempotency, pagination, or 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.

Conciseness3/5

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

The description is a single sentence, which is concise but lacks essential context for effective tool usage. It could benefit from more structured information.

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

Completeness2/5

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

Given the complexity of 4 parameters and no output schema or annotations, the description is incomplete. It does not explain return format, pagination, or behavior beyond the search action.

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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches orders with field criteria and includes the HTTP method and endpoint, making it distinguishable from list tools. However, it does not explicitly differentiate from siblings like bexio_list_orders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 bexio_list_orders or other search tools. No prerequisites or context for appropriate use are provided.

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

bexio_search_projectsSearch projectsC

Search projects with field criteria (POST /2.0/pr_project/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like idempotency, rate limits, or authorization requirements. The POST method implies it is not read-only, but the intent is search; this lack of clarity could mislead an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single sentence, which is concise but omits critical information. It front-loads the endpoint but lacks structure like usage examples or important details.

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

Completeness2/5

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

Given the complexity (4 parameters, no output schema, no annotations), the description is insufficient. It does not explain pagination behavior (limit/offset), result format, or how criteria filters combine.

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 coverage is 100% with well-described parameters. The description adds no additional context beyond the schema, so it meets the baseline but does not enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches projects using field criteria, differentiating it from siblings like bexio_list_projects which likely returns all projects without filtering. However, it could be more explicit about the filtering mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 bexio_list_projects or bexio_get_project. No mention of prerequisites or context.

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

bexio_search_quotesSearch quotes / offersC

Search quotes / offers with field criteria (POST /2.0/kb_offer/search).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max number of records (bexio default 500).
`offset`	No	Number of records to skip.
`criteria`	Yes	List of field/value/criteria filters (AND-combined).
`order_by`	No	Field to order by, e.g. `id_desc` or `name_1`.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must carry behavioral disclosure. It mentions HTTP method and endpoint but does not confirm read-only nature, pagination behavior, or any side effects. The minimal description leaves uncertainty.

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 sentence with no redundant information. It is concise, though it omits useful context; conciseness is not completeness.

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

Completeness2/5

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

No output schema exists, and the description does not hint at return type or pagination. For a search tool with 4 parameters, the description is insufficiently complete; it lacks mention of limit/offset or ordering.

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 coverage is 100%, so description adds little beyond schema. It mentions 'field criteria' which is covered in schema. Baseline of 3 is appropriate as no extra meaning is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'search' and resource 'quotes/offers', with mention of field criteria. It is specific but does not differentiate from sibling tools like bexio_list_quotes or bexio_get_quote, which limits clarity of unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., list vs search). The description only states what it does, not context or exclusions.

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.

21 tool updatesv0.1.0Jul 1, 2026
- First observedbexio_create_contact
- First observedbexio_get_company_profile
- First observedbexio_get_contact
- First observedbexio_get_invoice
- First observedbexio_get_item
- First observedbexio_get_order
- First observedbexio_get_project
- First observedbexio_get_quote
- First observedbexio_list_contacts
- First observedbexio_list_invoices
- First observedbexio_list_items
- First observedbexio_list_orders
- First observedbexio_list_projects
- First observedbexio_list_quotes
- First observedbexio_request
- First observedbexio_search_contacts
- First observedbexio_search_invoices
- First observedbexio_search_items
- First observedbexio_search_orders
- First observedbexio_search_projects
- First observedbexio_search_quotes

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct resource-action pair (e.g., list vs. search vs. get for contacts, invoices, etc.), with no overlap. The generic request tool covers any missing endpoints, further reducing ambiguity.

Naming Consistency5/5

All tools follow a consistent 'bexio_<verb>_<resource>' pattern in snake_case, with verbs like create, get, list, search, and request. Naming is predictable and uniform.

Tool Count5/5

21 tools cover the main business objects (contacts, invoices, items, orders, projects, quotes) plus a generic request endpoint. This is well-scoped for an ERP system, avoiding fragmentation or sparseness.

Completeness2/5

Only create_contact exists; there are no create, update, or delete tools for invoices, orders, projects, quotes, or items. Agents can only read and search these resources, which severely limits workflows without the generic request tool.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Relm CRM A
com.relmcrm
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
CRM AI & Machine Learning
412
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Cuéntica MCP
Finance ERP Systems
dacmail
A
license
B
quality
C
maintenance
MCP server to interact with the Cuéntica accounting API, allowing users to manage invoices, expenses, income, clients, providers, and bank accounts via natural language.
Updated 2 months ago (2026-07-16 07:39 UTC)
59
2
MIT
Moxie CRM MCP Server
CRM Project Management Customer Support
flyingwebie
A
license
B
quality
D
maintenance
An MCP server that enables LLMs to interact with Moxie CRM. Provides comprehensive tools for managing clients, contacts, projects, invoices, time tracking, and more.
Updated 7 months ago (2026-02-16 16:03 UTC)
30
15
2
MIT
invoiceninja-mcp
Finance CRM Payments & Billing
ambaloo
A
license
B
quality
F
maintenance
MCP server for Invoice Ninja v5 API. Enables AI assistants to manage clients, invoices, quotes, payments, and time tracking through natural language.
Updated 7 months ago (2026-01-23 14:26 UTC)
32
22
2
MIT
bexio-mcpofficial
ERP Systems CRM
nolen-ai
A
license
A
quality
A
maintenance
MCP server for the bexio API, enabling interaction with contacts, sales, accounting, projects, and more through 35 tools. Supports both PAT and OAuth authentication with read-only mode and tool group filtering.
Updated a month ago (2026-07-27 20:40 UTC)
35
21
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/valmiremini/bexio-mcp'

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

bexio MCP Server

Transports

Available tools (21)

Example: search

Installation

Claude Desktop (stdio)

Claude Code (stdio)

n8n (HTTP)

Manual test of the HTTP endpoint

Environment variables

Development

Security

Privacy

License

Disclaimer & trademarks

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

bexio-mcpofficial

Latest Blog Posts

MCP directory API