openclaw - 💡(How to fix) Fix Expose active model/provider metadata or support model-scoped native plugin tools [2 comments, 2 participants]

Summary

Native plugin tools need a trustworthy way to know which model/provider session invoked a tool call, or a way to register tools only for specific model/provider scopes.

This is needed for privacy-sensitive local tools where access is appropriate for approved local/private models but should remain unavailable to cloud-led or unknown-trust sessions.

Use case

A plugin may need two separate tool paths for the same private data source:

• A safe bridge tool for cloud-led or unknown sessions. It returns only a bounded answer plus policy-filtered evidence/audit.
• A local/private source-packet tool. It returns sanitized private source material to the active local model so the selected local session can reason over it directly.

The second tool should be available only when the active session is using an approved local provider/model. It should not be callable from cloud or unknown-trust sessions.

Current blocker

The current native plugin tool execution context exposes session/workspace/sender/runtime metadata, but not trustworthy active model/provider metadata.

That means a plugin cannot safely enforce logic like:

if (context.modelProvider !== "local-provider") deny();
if (!approvedModels.has(context.model)) deny();

Without runtime-owned model identity, privacy-sensitive source tools must either stay disabled by default or rely on unsafe development-only gates.

Requested capability

Please add one or both of the following.

Option A: Active model/provider metadata in tool execution context

Expose trusted active session model metadata to native plugin tools, for example:

interface OpenClawPluginToolContext {
  sessionId: string;
  sessionKey?: string;
  modelProvider?: string;
  model?: string;
  modelRef?: string;
}

The important requirement is that this metadata is supplied by the OpenClaw runtime, not by user/tool params.

Option B: Model-scoped tool registration

Allow plugins to register tools with provider/model availability constraints, for example:

api.registerTool(tool, {
  availability: {
    providers: ["local-provider"],
    models: ["local-model-a", "local-model-b"]
  }
});

OpenClaw would then only expose/call that tool in matching sessions.

Security / privacy motivation

Some tools are safe for all models because they return bounded, public, or policy-filtered data.

Other tools are safe only for local/private models because they return sanitized but still private source material. Sanitized text from a private source is still private content. It may be appropriate for a local model running in a local/private session, but not for a cloud model.

This distinction cannot be enforced reliably inside a plugin without runtime-owned model/provider identity.

Desired behavior

For an approved local model session:

• The local source-packet tool is available.
• Tool call context confirms the approved local model/provider, or OpenClaw has already scoped registration to that model/provider.
• The plugin can return sanitized source packets to the same local session.

For a cloud or unknown-trust model session:

• The local source-packet tool is unavailable, or the plugin can fail closed based on trusted context.
• The safer bounded-answer bridge remains available.

Compatibility

This should not break existing plugins. Missing model/provider metadata can remain optional at first, but privacy-sensitive plugins need a documented stable field or scoped-registration API before enabling local-only source tools by default.

Why this matters

This enables OpenClaw to support local-first/private-data workflows without forcing plugins to either expose private source tools too broadly or disable useful local-only capabilities entirely.

A downstream plugin can implement the local-only retrieval path, but must keep it fail-closed until native tools can prove the active model/provider or OpenClaw can scope tool registration by model/provider.