DE EN
Back to MCP catalog

MCP Tool

nova.tools_bundle

For risk-bounded actions with visible user control, an agent uses this public tool to start or monitor the bounded flow "Surface-Explorer Bundle". It names the scope, progress signal, stopping condition, and result check that keep the run bounded.

Agent tool

Canonical reference for a public MCP tool name.

Type
MCP tool
Family
Surface Explorer (High Risk, Opt-in)
Effect
bounded run
Status
Explained
Path
28.14

Purpose

What this entry explains

What it does

nova.tools_bundle An agent uses this tool to start or monitor the bounded flow "Surface-Explorer Bundle". It belongs to risk-bounded actions with visible user control; agents should combine it with current discovery, target awareness, and the visible result.

Use when

  • Use this entry when an agent needs to start or monitor the bounded flow "Surface-Explorer Bundle" for risk-bounded actions with visible user control.
  • Use it to understand the public tool name, its expected boundary, and the response signals to check.
  • Use it before chaining follow-up tools so the next step is based on current evidence.

Reference Use

How agents should cite and apply this area

Examples are maintained at family level and use only public tool names or reference paths already present in the catalog.

Family example

An agent prepares a bounded run in risk-bounded actions with visible user control and must keep scope, progress, and stop condition visible.

The agent starts with nova.explore_surface, reads the current response or reference, and only then chooses the concrete next tool.

Scope, budget, progress, stop condition, and terminal status remain part of the run.

Contract

Inputs and important response fields

This page is a public reference. Agents and integrators should still read current MCP tool discovery before execution, because schemas can be gated by settings or version.

Inputs

bundle

Tool-bundle name. Use discovery to see available tools and gates.

includeUnavailable

Includes unavailable entries in discovery responses. Check further before execution.

includeInputSchema

Boolean switch. It changes which checks, data, or state transitions become visible.

Response fieldExplanation
unavailableToolsResponse field named by the catalog source. Treat it as current evidence for the next decision.

Safety

Boundary before execution

Effect

Starts or observes a bounded run. Scope, limits, progress, and terminal status need to stay visible.

Agent rule

Set scope and limits before starting the run, poll explicit progress or status fields, and stop instead of assuming completion.

Human control

For humans, this entry shows which bounded flow in risk-bounded actions with visible user control starts or continues, and where scope, progress, and stopping conditions belong.

High-Impact Review

Execution boundary and recheck hints

Review category: Auto-apply/mutating flows

Execution boundary

Mutating steps may run only with confirmed target, expected effect, user control, and result check.

Typical false assumption

False assumption: a guard or auto-apply signal replaces current target and result checks.

Visible user control

The user must be able to review action, target, approval, block signal, and visible result.

Agent rule

Execute only the intended step, then verify state and stop on warning, block, or target change.

Abort or recheck

Recheck if candidate budget, gate, visible state, or expected effect do not line up.

Safety Axes

How this path can affect work

Axes are stable catalog signals for humans, agents, and LLM discovery. One path can carry several axes.

Read current state read_current_state

Reads current state, response signals, or evidence without treating that alone as permission for a follow-up action.

Use the signal as current evidence and re-check target, scope, and visible state before any follow-up action.
Automation automation_run

Starts or monitors crawls, sequences, schedulers, tasks, batches, or longer runs.

Keep scope, budget, progress, stop condition, and terminal status visible before and during the run.
User confirmation user_confirmation

Requires visible confirmation, target review, approval, or deliberate user control.

Do not proceed until the required confirmation is visible or unambiguous in the current context.