MCP changelog

Releases of the Boost.space MCP server — the endpoint at mcp.boost.space that connected AI agents talk to. It has its own version line, independent of the product release, because agents connect to it directly and a tool change reaches them the moment it deploys. See Connect via MCP to get started, or Docs for agents for the agent-facing surface.

Two lines: v1 and v2

Two release lines since 24 June 2026. The difference is which data model an agent sees.

	v2 — use this	v1 — legacy
Endpoint	`mcp.boost.space/v2/{system}/sse`	`mcp.boost.space/v1/{system}/sse`
An agent sees	Your modules, spaces, records, fields, statuses, labels, menus, automations	The same, plus the classic built-in modules (Contacts, Tasks, Products, Invoices, Warehouses)
New tools	Every new capability lands here	Fixes only
Choose it if	Always — unless the box to the right applies	You still depend on a classic built-in module (archived docs)

Both authenticate with OAuth or an API token, and both scope every call to the connecting user's permissions. v2's tools are generated from the public API surface, so an agent can call exactly what is documented.

Version 2.8

September 2026

Files on records, and a tool list that matches the account.

Files — upload_file_to_record, list_record_files, download_file. Up to 25 MB, and the id an upload returns is what a file or image field stores.
Code actions carry a summary — one sentence and up to ten steps, written in the same call as the code. See Code automations.
Only the tools the account can use — a tool is listed while its module is active; about_this_mcp_server, get_help, search_documentation and get_boostspace_sdk_reference always are. The list is cached for five minutes.
A non-JSON 200 comes through as text — which is what lets download_file return base64.

⚠ Breaking change — a code action needs its summary. Any create, and any update that sends setting.code, is refused without one.

⚠ Breaking change — the tool list follows active modules. A tool for an inactive module is neither listed nor callable, and an account the server cannot confirm sees only the four always-on tools. Read tools/list rather than assuming a fixed set.

⚠ Breaking change — no more parse_error envelope. A client that keyed on it now gets an empty value from an empty 200 or 204.

Version 2.7

August 2026

The automation builder edits what is already there.

Edits in place — name an action or trigger in the intent and the subagent changes that one instead of building a duplicate. With no id it asks for one.
What merges, what replaces — an action's setting merges per key; a trigger's intervalConfig, conditions, actions and spaces replace whole, so send the complete value for any of those four you change.
A trigger answers with its schedule — interval, timezone and conditions come back, so an agent can build "add Friday" from what is stored.
A test run only where there is code — a title, schedule or condition change, and the email, notification, url and create action types, skip the sandbox.

Version 2.5

August 2026

No 2.6 entry: the v2.6.0 tag points at the same commit as v2.5.0 — an internal re-tag with no code between them.

A secret an agent can ask for without ever seeing it.

request_secret — returns a one-time form for a named automation Variable. The person types the value in a browser, and the build_automation subagent can ask for one mid-build.
A mis-cased parameter is repaired — Limit becomes limit. An unknown name comes back with the ones that exist; a near-miss stays an error, because guessing writes into the wrong field.
Schedules read back in UTC — the times you write stay wall-clock in the trigger's timezone, and the tools say so rather than letting an agent shift them.
Variable errors name Variables — a permission failure says which permission it needs.
Tool output is redacted in logs — diagnostics carry the shape of a response, not your data.

Version 2.4

August 2026

Tools that can look things up, and answer with what they stored.

search_documentation — the server proxies the documentation's own MCP endpoint, so an agent can read how a feature works before it calls anything, instead of inferring it from a schema.
Field tools that explain the field type — the field and field-group tools carry guidance per type — Formula, Rollup, linked records — and point at get_help, so an agent editing a field has the syntax and the options in front of it rather than guessing.
Automation writes answer with what was stored — creating or updating an automation action returns the saved setting, so an agent can verify its own write instead of trusting a 200.
A failed code run says why — run_automation_code fills error from the traceback instead of returning it empty with the detail buried in stderr, so an agent can read its own failure and fix the script.
Descriptions match the sandbox — the SDK is described as it behaves (the package is available and the client is constructed once, rather than waiting preinstalled), the trigger tools name the module value the API accepts, and the manual-run guidance says which actions need a record.
Status filtering reaches the module — the status tools send the module filter under the name the API reads, so a request for one module's statuses is filtered server-side.
The Integrator tools are gone from v2 — list_on_demand_integrator_scenarios, run_integrator_scenario and refresh_integrator_scenarios were removed with no MCP successor. The v1 line still exposes them.

⚠ Breaking change — the three Integrator tools left v2. A client that calls one of them gets missing-tool behaviour. Drive a Make scenario through the REST API instead.

Version 2.3

July 2026

An agent that builds automations, not just reads records.

The catalogue follows the public API — v2 now generates its tools from latest.json, the curated public API document, instead of a pinned copy. An agent is offered the operations that are actually documented and supported.
Automation subagent — build_automation hands the work to a dedicated agent that writes the Python, runs it against your data, reads the failure, fixes it, and creates the action. Backed by run_automation_code for a dry run and get_automation_runs for the log. (v2.3.1)
get_boostspace_sdk_reference — the SDK available in the sandbox is discoverable, so generated code uses the real client instead of hand-rolled HTTP. (v2.3.1)
Menu tools — read and manage navigation, so a module an agent creates can be placed where people will find it.
"Custom modules" become modules — tool names, parameters, and descriptions follow the 5.5 rename (customModuleId → moduleId); legacy API paths are retained for write tools.
delete_record_in_module — deletion joins create and update as an explicit, scoped tool. (v2.3.3)
Record ownership — records an agent creates carry who they were created for. (v2.3.3)
Leaner tool metadata — tool descriptions are no longer assembled with embedded sample data. (v2.3.3)
Stricter filters — filter keys must be the ASCII system key, not a display name; keys with spaces or diacritics are rejected with guidance instead of silently matching nothing, and keys inside parenthesized groups are validated too. (v2.3.3)
get_sample_record is gone — field discovery goes through get_module_schema(spaceId), or a list call with limit=1. (v2.3.3)

⚠ Breaking change — get_sample_record was removed in v2.3.3. A client that still calls it gets missing-tool behaviour; use get_module_schema(spaceId), or a list call with limit=1.

Version 2.2

July 2026

Automations become callable.

Automation tools — list, create, and update triggers and actions, including code actions; run an action on demand; read run history and step output.
Scheduled triggers — time-based automations are creatable over MCP.
The automation variable endpoint is exposed — generated code can reference a stored variable by name rather than having a value pasted into the script.
list_users — resolve assignees and owners by name.
Version-safe field paths — the server resolves field/* or custom-field/* per system, so a connection stays working whichever side of the 5.5 rename that system is on. (v2.2.3)

Version 2.1

July 2026

Semantic search tools — vector_search and vector_outliers over vectorized spaces, so an agent can retrieve by meaning rather than by keyword. v2 only. See Vector database.

Version 2.0

June 2026

Tenant routes move to the URL root, dropping the in-server /v1 path prefix — which is what made the two lines separately deployable, v2 behind /v2/ and v1 behind /v1/. That routing change is v2.0: it opened the line rather than changing any tool. Every capability that now distinguishes v2 arrived in the releases above it.

Version 1.0

June 2026

First stable line. v1 is frozen here as a maintenance branch for clients already configured against it: narrowly-scoped fixes are merged onto it, new tools go to v2.
OIDC discovery — standard openid-configuration discovery alongside the OAuth metadata, with Dynamic Client Registration advertising only the auth method it accepts. Released on this line (v1.0.4).

Version 0.7

June 2026

Schema-aware aggregations — aggregateBy is validated against the module schema before the call is made, count gets a sensible default target, and a targetless sum/avg/max/min is rejected with an explanation rather than a wrong number.
A field-listing tool — fields are enumerable directly instead of being inferred from a sample record.

Version 0.6

April – June 2026

The release line where the tools started teaching the agent how to use them.

PKCE, and more OAuth client types — public clients that hold no secret authenticate with PKCE, and confidential clients can present their secret the way their library expects. Between them, most MCP clients connect without custom work.
A dedicated aggregation tool, plus sample-data fetching — so an agent could ask for a total instead of paging through history.
Space filtering — spaces are filterable, with worked examples in the tool descriptions, which is what stopped agents from scanning a whole module to answer a question about one space. (v0.6.1)
Scalar aggregations without ceremony — an aggregation with no groupBy no longer demands only_fields and limit; pass aggregateBy and aggregation and you get the number. (v0.6.1)
includeRecords hidden — removed from the agent-facing signatures it was only ever confusing. (v0.6.1)
Field-key validation — keys are checked before a create or update, so a typo fails loudly at the call instead of quietly producing a field nobody wanted. (v0.6.2)
OpenAI apps domain verification — the endpoint required to list as an app.

Version 0.5

November 2025 – January 2026

Multi-tenant support — one server, every system, with the system key in the connection URL.
Dynamically generated tools — the eager, per-endpoint tool build that replaced the earlier hand-maintained set.
Limit-exceeded warnings — a truncated result says so, rather than looking complete.
OAuth 2.0 — authorization metadata, callback handling, and a root redirect, replacing token-only access. This is the line that shipped alongside 5.0 as "a Remote MCP server in every account". (v0.5.1)

Version 0.4

August – September 2025

Aggregation support in the tools — the first reads that returned a computed value rather than records.
Custom fields reachable through the tools, and sample lookups that handle path parameters.
Integrator support — Make scenarios listable and runnable from an agent. (v0.4.1)
End-to-end tests in CI — the agent-behaviour suite this server has been gated on ever since.

Version 0.1 – 0.3

June – July 2025

The first Boost.space MCP server — tools generated from the Boost.space OpenAPI document, over SSE, authenticated with an API token, so modules, spaces, and records were readable and writable by an MCP client.
A schema tool, a sample tool, and field filtering — the discovery primitives everything since has been a refinement of.

Product-level context for these releases is in the release notes; the endpoints behind the tools are in the API changelog.

API changelog

SDK changelog