MCP Server

Use the Thalovant MCP server when an MCP client should discover hubs, provision hubs and runtime groups, create client identities, ask a hub, read analytics, or work with memory through Thalovant.

MCP means Model Context Protocol. It gives local agents and remote agent gateways a standard way to call Thalovant tools.

At A Glance

Item	Value
MCP registry name	io.github.thalovant/thalovant-mcp
npm package	@thalovant/mcp-server
current version	0.5.1
container image	ghcr.io/thalovant/thalovant-mcp:0.5.1
transports	stdio and Streamable HTTP
tool count	46 by default; 48 with destructive tools enabled; 23 in read-only mode
local path	best for Claude Desktop, Codex, Cursor, and desktop agents
remote path	best for hosted agent gateways and shared agent platforms
license	MIT

GitHubSource, examples, security notes, and release metadata.

Node SDKThe MCP server uses the Thalovant Node SDK under the hood.

Hub EndpointsUnderstand WSS, HTTPS, and MQTT hub traffic used by runtime tools.

Identity FilesStore hub credentials for runtime tools.

Choose A Transport

Transport	Use it when	Start command
stdio	The MCP client runs on the same machine as the server process.	npx --yes @thalovant/[email protected] --stdio
Streamable HTTP	Remote MCP clients connect over HTTP to /mcp.	docker run ghcr.io/thalovant/thalovant-mcp:0.5.1

Start with stdio for a personal agent. Use Streamable HTTP when the server is deployed behind your own auth, logs, and network controls.

Hub Runtime Connections

Version 0.5.1 uses Node SDK 0.7.1 for hub runtime tools over WSS, HTTPS, or MQTT over TLS. These connections perform v3 Noise with XXpsk2 or pinned-peer KKpsk0, using a mutually offered ChaChaPoly or AESGCM suite. MCP stdio and Streamable HTTP describe the agent-to-MCP connection; they do not select the hub protocol.

Preserve the Node SDK’s private configuration directory between MCP process or container restarts so its static key and server pins survive. By default this is $XDG_CONFIG_HOME/thalovant when set, ~/.config/thalovant on Linux and macOS, or %APPDATA%\Thalovant on Windows. A custom identity file or configPath does not relocate Noise state. See Persistent Noise State.

Runtime calls using the same hub endpoint and access key are serialized within a single MCP process, and actual connection cleanup must finish before the next starts. Waiting for the identity lease is bounded at six seconds; a timed-out or cancelled queued call never runs later. If cleanup fails, that identity remains unavailable in the process so a new tool cannot reuse uncertain session state. Use thalovant_ask or thalovant_query when a request needs its reply: separate send and wait tool calls do not share a persistent connection, and a waiter using the same identity can hold up a later send. Identity inspection alone does not open or disconnect a hub session. Use distinct runtime identities for separate MCP processes, or coordinate their identity use externally.

MCP request cancellation is forwarded to runtime connection setup, Ask, Query, and event waits. Cancelling stops the caller’s wait. An action, code input, event emission, or inventory operation that has already started may still finish; its identity stays occupied through the operation and connection cleanup. Cancellation does not undo or automatically replay a published request.

Use a dedicated identity for each independently running MCP process or other client. In particular, do not reuse an identity already serving another app’s HTTP session. An HTTP admission response can be successful while that existing session owns the message queue, leaving the new client waiting for a handshake. Preserve pins and verify any server-key rotation before deliberately changing stored trust.

Local Agent Setup

Public hub discovery works without Thalovant credentials. Private workspace tools and runtime tools need server-side Thalovant credentials.

Since version 0.1.9, a scoped API token in THALOVANT_API_TOKEN is the recommended way to authenticate the server, so the config never contains your account password. Create the token on the dashboard’s API Tokens page with these scopes for the full tool surface:

Scope	Tools that need it
hubs:read	Hub discovery, hub detail, the marketplace catalog, and runtime group reads.
hubs:inspect	Runtime group inventory, the group marketplace view, hub runtime capabilities, thalovant_list_hub_skills, and thalovant_list_hub_skill_history. Granted automatically by hubs:read.
hubs:write	Hub and runtime group provisioning tools, plus thalovant_install_hub_skill, thalovant_update_hub_skill, and thalovant_remove_hub_skill. Paid plans.
clients:write	thalovant_create_client_identity.
memory:read	Memory list, summary, and item reads. Paid plans.
memory:write	Memory create, update, and delete. Paid plans.

A read-only assistant needs only hubs:read and memory:read. Tokens are scoped, revocable, and show their last use on the API Tokens page.

The hub scopes imply one another. hubs:write grants hubs:read, which grants hubs:inspect, so a token minted with hubs:read already covers every discovery tool.

Your plan decides which of these scopes you can grant. The Free plan covers the hub read and client scopes, so an agent on it can run the Discovery tools, browse the marketplace catalog, and call thalovant_create_client_identity. The memory scopes need a paid plan, so the Memory tools stay unavailable on the Free plan and fail with a scope error if the agent calls them. The Free plan also allows one active token at a time.

A Free-plan API token cannot carry hubs:write at all, so the Provisioning tools fail with a scope error rather than a plan error on that plan. See Provision Hubs.

The server’s Thalovant API calls count against your plan’s token rate limit and call quotas, so a busy agent can reach them. Over the limit, calls return HTTP 429 with a Retry-After header. The API Tokens page has the per-plan table and the matching error codes.

For stdio MCP hosts that use JSON server configuration, such as Claude Desktop or Cursor:

{
  "mcpServers": {
    "thalovant": {
      "command": "npx",
      "args": ["--yes", "@thalovant/[email protected]", "--stdio"],
      "env": {
        "THALOVANT_API_TOKEN": "tvpat_...",
        "THALOVANT_PROFILE": "prod",
        "THALOVANT_API_URL": "https://api.thalovant.com"
      }
    }
  }
}

For control-plane authentication, the server tries THALOVANT_API_TOKEN first, then THALOVANT_ACCESS_TOKEN, then a THALOVANT_EMAIL and THALOVANT_PASSWORD login. With a token set, the server never calls the login endpoint. A matching per-principal control token takes precedence over these shared credentials.

The thalovant_config_status tool reports which mode the environment declares in its controlPlaneAuthMode field: api-token, access-token, email-password, or none. Token values never appear in its output.

Caution

Do not paste Thalovant tokens, passwords, identity files, or setup links into chat. Configure them in the MCP server environment or in protected files.

Configure A Hub Identity

An API token lets MCP call the Thalovant API. Runtime tools also need a client identity containing that hub’s access key, password, and endpoints. For local stdio, use one of these sources:

Source	Runtime tool arguments
Downloaded, protected JSON identity	identityFile with the path on the MCP server’s machine
SDK YAML profile	configPath and/or profile; otherwise the default config and THALOVANT_PROFILE apply
SDK environment identity	fromEnv: true, with the SDK’s identity variables configured in the server environment

The server can also create an identity with thalovant_create_client_identity: provide the hub UUID and a filename such as agent.json in savePath, then use its savedIdentityPath in runtime calls. The server writes the full identity to the protected directory and returns a redacted summary.

For example, call thalovant_ask with tool arguments like these after placing the identity at that path:

{
  "identityFile": "/path/to/private/agent.json",
  "protocol": "https",
  "text": "What time is it?",
  "timeoutMs": 30000
}

The default protocol is wss. Explicit https and mqtt require that transport to be enabled in the identity and on the hub. thalovant_identity_status checks the loaded identity without connecting; thalovant_healthcheck connects and completes Noise before reporting runtime health.

API Destination Restrictions

Configured API tokens and password credentials are bound to their configured API origin. An authenticated tool’s apiUrl cannot select another origin; the server rejects the override before contacting it. For a self-hosted API, configure its URL alongside matching credentials, either server-wide or on the authenticated principal. Equivalent normalized origins are accepted. Anonymous public discovery can use a custom URL when no API credentials are configured for that caller.

Control-plane requests refuse redirects, including redirects that would resend a login body. Authenticated requests and request bodies require HTTPS, with HTTP allowed only for explicit localhost, 127.0.0.1, or [::1] development endpoints. API URLs cannot contain embedded credentials. Set the final API URL directly when an old endpoint redirects.

Remote HTTP Setup

The container runs Streamable HTTP on port 3000 and serves MCP at /mcp.

export MCP_HTTP_AUTH_TOKEN="$(openssl rand -hex 32)"
docker run --rm \
  -p 127.0.0.1:3000:3000 \
  -e MCP_HTTP_AUTH_TOKEN \
  -e MCP_HTTP_ALLOWED_HOSTS="127.0.0.1:3000,localhost:3000" \
  ghcr.io/thalovant/thalovant-mcp:0.5.1

Clients connect to:

http://127.0.0.1:3000/mcp
Authorization: Bearer <token>

Health checks are available at /healthz and /readyz.

Configure the client with the same token stored in MCP_HTTP_AUTH_TOKEN. This example enables access to MCP; add per-principal Thalovant credentials below before using private or runtime tools. The HTTP health routes describe the MCP process, while thalovant_healthcheck verifies a hub connection.

For runtime calls in a container, mount private, persistent Noise state at /home/thalovant/.config/thalovant, or set XDG_CONFIG_HOME to a mounted configuration root. The directory must be writable by the container’s thalovant user; protect mounted identity files with owner-only permissions.

For a public endpoint, set exact public URL, host, and origin values:

export MCP_PUBLIC_URL="https://mcp.example.com"
export MCP_HTTP_ALLOWED_HOSTS="mcp.example.com"
export MCP_HTTP_ALLOWED_ORIGINS="https://agent.example.com"

Auth And Credentials

1. Keep bearer auth on. HTTP mode requires MCP_HTTP_AUTH_TOKEN or MCP_HTTP_AUTH_TOKENS by default.
2. Use OAuth validation for shared remote servers. Set MCP_HTTP_AUTH_MODE=jwt with JWKS, or use MCP_HTTP_AUTH_MODE=introspection for opaque tokens.
3. Map users to Thalovant credentials. Use THALOVANT_PRINCIPAL_CREDENTIALS_FILE or THALOVANT_PRINCIPAL_CREDENTIALS_DIR.
4. Disable shared credentials for multi-user servers. Keep THALOVANT_ALLOW_SHARED_CREDENTIALS=false.
5. Set tool policy. Use MCP_TOOL_ALLOWLIST and MCP_TOOL_DENYLIST for server-wide controls.
6. Send audit logs somewhere durable. Set MCP_AUDIT_LOG=stderr, or set MCP_AUDIT_LOG=file with MCP_AUDIT_LOG_FILE. Use MCP_AUDIT_LOG=both with a file path for both destinations. A file path alone leaves logging off.

Remote callers’ identityFile, configPath, profile, and fromEnv arguments are disabled by default. Configure the identity on the server for each authenticated principal using the credential file format. Directory-mode files are named <sha256(principal-id)>.json; a matching directory entry takes precedence over the shared credential file. MCP_HTTP_ALLOW_CLIENT_CREDENTIAL_PATHS=true permits caller-selected paths and should be limited to trusted private deployments.

The server publishes OAuth protected resource metadata at:

https://mcp.example.com/.well-known/oauth-protected-resource

Tool Groups

Discovery

thalovant_config_status, thalovant_list_public_hubs, thalovant_get_public_hub, thalovant_list_hubs, and thalovant_get_hub.

Runtime

thalovant_identity_status, thalovant_healthcheck, thalovant_intent_inventory, thalovant_ask, thalovant_query, thalovant_send_action, thalovant_send_code, thalovant_emit_event, and thalovant_wait_for_event.

Memory

thalovant_list_memory_items, thalovant_get_memory_summary, thalovant_get_memory_item, thalovant_create_memory_item, thalovant_update_memory_item, and thalovant_delete_memory_item.

Workspace

thalovant_create_client_identity, thalovant_get_operation, and thalovant_get_analytics_overview.

Skill discovery

thalovant_list_marketplace_skills, thalovant_list_runtime_group_marketplace, thalovant_list_runtime_group_inventory, thalovant_list_runtime_groups, thalovant_get_runtime_group, thalovant_get_runtime_group_config, and thalovant_get_hub_runtime_capabilities.

Provisioning

thalovant_create_hub, thalovant_update_hub, thalovant_release_hub, thalovant_create_runtime_group, thalovant_update_runtime_group, thalovant_update_runtime_group_config, thalovant_release_runtime_group, thalovant_install_runtime_group_skill, and thalovant_uninstall_runtime_group_skill.

Ratings

thalovant_set_hub_rating and thalovant_clear_hub_rating. These need hubs:write but no paid plan.

Hub skills

thalovant_list_hub_skills, thalovant_list_hub_skill_history, thalovant_install_hub_skill, thalovant_update_hub_skill, and thalovant_remove_hub_skill. History is available from 0.2.0; the other tools from 0.1.23.

thalovant_create_client_identity does not return secret identity material in chat output. Use savePath when you want the full identity written to a local file with mode 0600. The path is resolved inside THALOVANT_MCP_IDENTITY_DIR (a safe config directory by default); a savePath that is absolute outside that base, or uses .. to escape it, is rejected before any credential is created.

Version 0.1.10 added the Skill discovery and Provisioning groups, plus the two opt-in delete tools below. Discovery is read-only and works on any plan. Provisioning needs hubs:write and a paid plan. For the full flow, the etag rule, and the error table, see Provision Hubs.

thalovant_update_hub requires the hub’s current etag as an input and does not accept name, namespace, or domain, because those are fixed at creation. Call thalovant_get_hub first and pass the etag field from its response body.

Version 0.1.23 adds the Hub skills group, which manages skills on the runtime group selected by a hub, affecting all hubs sharing it. Each tool takes the hub UUID as hubId; the three write tools also take the skill id as skill. thalovant_install_hub_skill accepts an optional version (default latest), thalovant_update_hub_skill requires one, and thalovant_remove_hub_skill accepts no version. The three write tools return the accepted operation; pass wait: true to poll it with thalovant_get_operation semantics every 2 seconds, with a 120,000 ms polling budget unless timeoutMs says otherwise. thalovant_list_hub_skills returns the route’s envelope with the rows under data, and it and the new history tool are visible in read-only mode. The app path, the routes, and the error table are on Add a Skill to a Hub.

Version 0.5.1 uses the published Node SDK for hub-skill requests and polling. It retains MCP cancellation checks and starts no new status read after the polling deadline. The polling deadline does not cancel an HTTP request already in flight. If a status read fails after a write was accepted, the tool error retains the operation ID; follow it with thalovant_get_operation instead of submitting the write again.

Runtime Discovery And Routed Queries

thalovant_intent_inventory reads the hub through its configured runtime identity. Supply one to 20 language tags and an optional per-query timeoutMs; its response includes fallback handlers, fallbacks_known, and a may_answer map. Connection setup is cancellable; inventory then uses per-query or batch budgets and a separate optional fallback probe of at most 1.5 seconds. There is no single total inventory deadline. Unknown discovery does not mean the hub cannot answer. See intent discovery.

thalovant_query sends a routed HiveMind query and collects matching cascade replies until completion or its deadline. It returns the same normalized reply fields as Ask and ignores another query’s replies. Like Ask, it can trigger hub actions and is hidden in read-only mode. Reuse a sessionId across calls for conversation context; each tool call still owns a separate connection and cleanup. Leave requestId and queryId to the generated defaults or supply fresh values for every logical operation, including after cancellation. These IDs correlate replies and do not make repeated actions idempotent. thalovant_wait_for_event supplies a bounded event wait, rather than a persistent SDK event stream.

thalovant_get_operation reads an operation returned by provisioning. Check its typed status before treating the resource as ready; requested, committed, and applied are intermediate states. failed and timed_out report unsuccessful completion.

Destructive Tools

thalovant_delete_hub and thalovant_delete_runtime_group are disabled by default. They are not merely blocked when called: they are never registered, so they never appear in the tool list and a model cannot see or attempt them.

Deleting a hub also deletes its dependent clients and ACLs, and none of it is reversible. A long-lived control-plane token paired with an always-visible delete tool is a different class of risk from a read or update tool, so these two are opt-in.

To turn them on, set the environment variable before the server starts:

export THALOVANT_ENABLE_DESTRUCTIVE_TOOLS="true"

Rule	Value
Accepted true values	1, true, yes, and on, in any letter case.
Anything else	Leaves the tools off, including unset, empty, 0, and false.
When it is read	At server construction. Restart the server process with the updated environment after changing it.
How to confirm	thalovant_config_status reports destructiveToolsEnabled and lists the tools the flag controls.

This is deliberately separate from MCP_TOOL_ALLOWLIST and MCP_TOOL_DENYLIST. Those are call-time filters where an empty allowlist means “allow everything”, so they cannot express a tool that stays off until someone turns it on, and they cannot hide a tool from the tool list. Once the flag is set, the delete tools become ordinary tools again and the policy still applies, so the two layers compose:

# Register delete tools, then deny their use to every principal.
export THALOVANT_ENABLE_DESTRUCTIVE_TOOLS="true"
export MCP_TOOL_DENYLIST="thalovant_delete_hub,thalovant_delete_runtime_group"

A global deny applies to every principal; a principal’s allowedTools cannot override it. To deny a tool only to selected principals, use their deniedTools entries and omit that tool from the global denylist.

Deleting a hub needs a nonempty current etag; a stale value fails with HTTP 412. Deleting a runtime group fails with HTTP 409 while it is the workspace default or still has hubs attached.

Caution

Leave these tools off unless an agent has a real reason to delete Thalovant resources. Deleting a hub cannot be undone.

Restricting Sources And Tools

Since version 0.1.11, three more environment variables narrow what the server will do, on top of the destructive-tool gate above. Like that gate, each is read at server start and reported by thalovant_config_status.

Non-catalog skill sources are off by default. thalovant_install_runtime_group_skill installs from the reviewed marketplace catalog. A git or URL source runs code the catalog never reviewed, so those sources are rejected unless you opt in:

export THALOVANT_ENABLE_GIT_SKILL_SOURCES="true"

With the flag unset, a non-catalog sourceType fails with a clear client-side error that names the variable, and no control-plane call is made. thalovant_config_status reports gitSkillSourcesEnabled.

Identity files stay inside one directory. When thalovant_create_client_identity writes to savePath, the path is confined to THALOVANT_MCP_IDENTITY_DIR, so an agent cannot drop a credential file into an arbitrary location such as a synced folder or a git working tree. thalovant_config_status reports identityDir.

Read-only mode hides every write tool. Set THALOVANT_MCP_READONLY="true" to register only the tools marked read-only, including discovery, memory reads, analytics, identity status, health checks, and event waits. It also hides thalovant_ask, thalovant_query, action, code, and event-emission tools because a hub request can trigger actions. thalovant_config_status reports readOnly.

Tool Input Rules

Since version 0.1.8, the server validates tool inputs against the same bounds the Thalovant API enforces, so bad values fail with a clear client-side error instead of an opaque API 422.

Rule	Value
thalovant_list_public_hubs page size	Capped at 48, matching the public hubs endpoint. Authenticated thalovant_list_hubs keeps its limit of 100.
Hub references on authenticated tools	thalovant_get_hub and thalovant_create_client_identity require the hub UUID. Slugs are only accepted by the public hub tools, such as thalovant_get_public_hub.
Memory title	160 characters or fewer.
Memory content	4096 characters or fewer.
Memory source	64 characters or fewer.
Memory consentScope	128 characters or fewer.
Memory consentVersion	64 characters or fewer.
Memory retentionPolicy	64 characters or fewer.
Memory list query	240 characters or fewer.
Runtime protocol	wss (default), https, or mqtt.
Ask text, action payload, code value	Non-empty strings, up to 20,000 characters. Action payload is one string, not a separate command and object.
Runtime timeoutMs	1,000–300,000 ms where offered; ask and event waits default to 30,000 ms, health checks to 10,000 ms.

thalovant_ask returns text, displayText, utterances, handled, ok, sessionId, requestId, displayItems, events, and any failureEvent. Action, code, and event-emission tools confirm that the event was sent; they do not wait for a hub answer.

Common Issues

Symptom	Check first
Claude or Codex cannot start the server	Confirm Node.js 20 or newer is installed and the command uses npx --yes @thalovant/[email protected] --stdio.
Public hub tools work but private API tools fail	Configure THALOVANT_API_TOKEN or a matching per-principal control token, then check thalovant_config_status.
API tools work but runtime tools fail	Configure a separate hub identity with its password and endpoints; an API token alone is insufficient.
Previous runtime session cleanup failed	This process blocks the identity. Finish and verify the previous hub session’s cleanup before reusing that identity; restarting MCP alone does not prove it is closed.
HTTP admission succeeds but Noise times out	Verify that another client is not using the same identity, and close the client that owns the existing session before retrying.
Runtime access fails after a process or container restart	Restore the original private Noise state and check identity credentials. Do not erase pins as an automatic retry step.
A tool fails with a scope error	Recreate the token on the API Tokens page with the scopes the tool group needs.
Memory tools fail on the Free plan	The memory scopes need a paid plan. Upgrade, or run the agent with the Discovery and client tools only.
Provisioning tools fail with HTTP 403 on the Free plan	Free-plan tokens cannot carry hubs:write, so the scope check fails before the plan check. Upgrade, then mint a token with hubs:write.
thalovant_install_runtime_group_skill returns HTTP 402 on a paid plan	The skill is a paid catalog entry the plan does not cover. Call thalovant_list_runtime_group_marketplace first and check installable and purchase_required.
thalovant_update_hub returns HTTP 412	The etag is missing or stale. Call thalovant_get_hub again and pass the etag from its response body.
thalovant_install_hub_skill returns HTTP 409 or 404	409 (skill_version_already_installed) means the hub already has that skill at that version; post another version to update instead. 404 with the code hub_without_runtime_group means the hub is not in a runtime group yet; a 404 without a code means hubId is unknown, often a slug rather than the UUID.
The delete tools are missing from the tool list	They are opt-in. Set THALOVANT_ENABLE_DESTRUCTIVE_TOOLS and restart the server. See Destructive Tools.
Calls return HTTP 429	The token reached its plan’s rate limit or call quota. Wait for the Retry-After interval, then retry.
HTTP returns 401	Send Authorization: Bearer <token> and confirm the token matches the server config.
HTTP returns 403 for a browser client	Add the exact origin to MCP_HTTP_ALLOWED_ORIGINS.
Remote users see the same Thalovant data	Configure per-principal credentials and keep shared credentials disabled.
A risky tool should not be available	Add it to MCP_TOOL_DENYLIST, or use a per-principal deniedTools policy.

Next

Use SDK Functions when you want the underlying Thalovant SDK method names. Use Provision Hubs when an agent should create hubs and runtime groups. Use Identity Files when runtime tools need saved hub credentials.

Last reviewed: September 13, 2026. Review this page when the MCP package name, registry metadata, tool list, tool input bounds, auth defaults, API token scope guidance, destructive tool gating, transport behavior, or container image changes.

Shared-runtime skill history

thalovant_list_hub_skill_history accepts hubId and an optional integer limit from 1 to 200 (default 50). It returns the newest skill events and operations, including versions, timestamps, actors and outcome fields. The tool is read-only and remains available when THALOVANT_MCP_READONLY is enabled.

The hub skill tools select the runtime group attached to the hub. Every hub sharing that group sees the same skill changes and history. A restricted token must cover all served hubs; hubs:inspect is sufficient for history. Use thalovant_get_operation to inspect an accepted write rather than repeating it when waiting fails.

Request hints, audio, and configuration updates

thalovant_ask accepts sttLang, an ordered pipeline, and location (city is required; region, country, timezone, latitude, and longitude are optional). These hints apply to that request without changing stored runtime configuration. Omit unused hints; an empty pipeline is ignored, and blank language or city strings are rejected.

Ask and Query return language, audio metadata, and droppedMedia. Embedded hexadecimal audio stays out of text output. Set includeAudio: true to receive separate MCP audio blocks for recognized formats, or embedded binary resource blocks for unknown formats. The SDK bounds clips at 4 MiB each and 16 MiB per reply before collection. The client owns playback; the server never fetches skill-supplied audio paths or URLs.

thalovant_intent_inventory accepts speakable, sentence, slots, and exampleLimit. The example limit is 1–20 per language, with a default of 2. Raw patterns stay available; rendered examples remove optional wording and retain the original complete-phrase ranking.

thalovant_update_runtime_group_config defaults to merge: true, using a revision precondition and retrying only HTTP 412 up to three total attempts. It needs the hubs:read and hubs:write scopes and a paid plan. Pass merge: false only for an intentional unconditional replacement, which requires the hubs:write scope, a paid plan, and coordination with other writers. Older APIs without revision support fail before a merge write. See configuration updates.

The underlying Node SDK rejects guarded merges containing integers outside JavaScript’s safe range before writing, including supplied personas. It also rejects non-finite values and stored numeric exponents that overflow JavaScript numbers, preventing conversion to null. Use string identifiers or a client with lossless integer support for such configuration values.

Set sentence: true to render inventory examples with locale sample slots, capitalization and punctuation. It implies speakable rendering. Explicit slots override locale samples, regional selection follows OVOS matching, and the limit counts unique nonempty rendered examples. Unknown locales retain bare text. Raw patterns remain in the inventory response.

The server handles SIGTERM and SIGINT by closing its MCP sessions and HTTP connections, including in the published container. Shutdown has a ten-second failure deadline if cleanup stalls.

Presentable inventory output

thalovant_intent_inventory adds a presentation object alongside its existing native discovery fields, examples, and answerability hints. It groups intents under readable skill titles and includes languages_present and explicit intent language order. Titles are derived from IDs; catalogue locales remain empty and hub metadata remains unknown when the runtime cannot provide them. Observed phrases do not prove catalogue locale support. Notes retain refused or unanswered queries and unknown fallback support.

The server does not share an inventory disk cache or a managed session across callers. Each tool call keeps its existing identity lease and cleanup lifecycle.

Reply claims

Runtime reply summaries include pipelineIds, skillIds and claimed, computed by Node SDK 0.7.1.

Pipeline and skill IDs are nonempty strings in first-seen order, with duplicates removed. A successful reply with only pipeline IDs containing the case-sensitive text fallback reports an unclaimed reply. Any non-fallback stage makes a successful reply claimed. Successful replies from older hubs without stage stamps remain claimed. Failed or unhandled replies are never claimed. Malformed non-string stamps are ignored.

Use this as a hint when deciding whether to continue a conversation. Fallback text and the existing success status are retained. These stamps are not verified peer identity and must not authorize actions.