Discover additional runtime controls

Use the Variable Exposer tools when a task needs a runtime control beyond the application tools. They discover registered fields, functions, and instance bindings in the running session.

Stable discovery tools

Tool	Arguments and purpose
variable_exposer_list_fields	Optional path filter; list fields and their metadata.
variable_exposer_get_field	identifier, with targetId for an instance; read the value and available options.
variable_exposer_set_field	identifier, value, and an instance targetId when needed; write a mutable field.
variable_exposer_list_functions	List callable functions and their descriptors.
variable_exposer_get_function	identifier and an instance targetId when needed; inspect function metadata.
variable_exposer_list_instances	identifier; discover target IDs and labels for that path.
variable_exposer_invoke_function	identifier, optional instance targetId, and arguments matching the discovered payload type.
variable_exposer_get_job	jobId; read a background invocation’s status and result.

Discover before changing a value

1. List fields and functions. Related controls can appear in different categories.
2. Inspect the field options or function descriptor for the required identifier and payload.
3. For an instance-bound path, call variable_exposer_list_instances and use its returned instanceId as targetId.
4. Read the current value, then request the intended change.
5. Read the resulting value or application state to confirm the outcome.

Do not guess identifiers or instance IDs. Repeat discovery after loading or deleting a model because its controls and State instances can change. A writable field is not necessarily represented by a separate named function.

Unlike application-tool string arguments, value and function arguments can be JSON scalars, arrays, or objects. Match the discovered schema; include targetId when the same path has multiple instances.

Follow a long-running function

Set background: true on variable_exposer_invoke_function to receive a jobId immediately. Keep that ID and poll variable_exposer_get_job until the status is succeeded or failed. Do not invoke the function again while its job is running.

Inspect both execution status and the returned result. A completed function can return false, and an accepted request can still have application work pending. Confirm the requested change through readback rather than treating transport success as proof.

Job IDs expire when the listener restarts, and completed jobs can be evicted from its bounded cache. Stopping MCP does not undo or cancel work already started. If an ID expires, inspect the actual application state before deciding whether to retry.