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

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.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.
• get_sample_record is gone — field discovery goes through get_module_schema(spaceId), or a list call with limit=1. Breaking for anything that called get_sample_record directly.

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)

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. The capabilities that now distinguish v2 arrived in v2.1 – v2.3 above.

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.