Skip to main content
Glama

Nebelus

by ai.nebelus.api
OverviewDiscussionsAdmin

Set grounding trace

set_grounding_trace

Enable, tune, or disable Grounding Trace (claim-to-source verification of regulated report output) on the agent. Assistive, never a certification. Pass disable=true to turn it off.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
manualNoA reviewer can trace on demand after the fact (mode 3). Default true.
disableNoTurn Grounding Trace off entirely. Default false.
agent_idYesTarget agent's id (from list_agents / create_agent / get_catalog view=agents).
agent_invokedNoAgent self-checks its own claims before delivery (mode 1). Default true.
report_languageNoLanguage for code-written verification notes. 'match' follows the traced output.
inference_prefixNoMarker the agent prefixes to unsupported claims. Defaults to 'Unsupported inference:'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties / agent_id / description
      Added value: +"Target agent's id (from list_agents / create_agent / get_catalog view=agents)."
    • addedInput schema / properties / agent_invoked
      Added value: +{
+  "description": "Agent self-checks its own claims before delivery (mode 1). Default true.",
+  "type": "boolean"
+}
    • addedInput schema / properties / disable
      Added value: +{
+  "description": "Turn Grounding Trace off entirely. Default false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / inference_prefix
      Added value: +{
+  "description": "Marker the agent prefixes to unsupported claims. Defaults to 'Unsupported inference:'.",
+  "type": "string"
+}
    • addedInput schema / properties / manual
      Added value: +{
+  "description": "A reviewer can trace on demand after the fact (mode 3). Default true.",
+  "type": "boolean"
+}
    • addedInput schema / properties / report_language
      Added value: +{
+  "description": "Language for code-written verification notes. 'match' follows the traced output.",
+  "enum": [
+    "match",
+    "en",
+    "nl",
+    "ar",
+    "de",
+    "fr",
+    "es"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=false, but they do not capture the nuance that this is a configuration tool that can turn off a feature (potentially 'destructive' in a functional sense). The description adds valuable context: the tool is 'Assistive, never a certification,' which qualifies the feature's role, and it explicitly mentions disabling via 'disable=true', which behavioral transparency. It adds context about modes (e.g., manual reviewer trace, agent self-check) that go beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact three-sentence block with no fluff. The first sentence states the primary action and purpose, the second clarifies the nature (assistive, not certification), and the third gives a quick usage tip ('Pass disable=true'). It is front-loaded with the main purpose, and every sentence earns its place. Efficient for 6 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, one required) and the fact that the output schema is absent, the description covers the core purpose and the disable mechanism. However, it does not explain what happens when disabling (e.g., does it affect existing traces?), nor does it mention the default modes (manual, agent_invoked). The schema provides parameter details, but a richer description could contextualize the modes (e.g., mode 1 vs mode 3) to help agents make informed choices. Still, enough for basic invocation is present, so 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 6 parameters with descriptions. The description adds meaning by clarifying the purpose of the feature and the disable flag but does not delve into each parameter's semantics beyond what the schema already provides. However, the description does not repeat parameter details, which is fine, but it also doesn't add new insights about parameters like report_language or inference_prefix. Given high coverage, baseline 3, but the description gives a high-level purpose that helps interpret the parameters, so 4 is justified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: enable, tune, or disable Grounding Trace (claim-to-source verification) on an agent, with a clear qualification that it is 'Assistive, never a certification.' This is specific (verb 'set' or 'enable/tune/disable' + resource 'Grounding Trace on the agent') and distinct from siblings like set_governance_policies or attach_ai_tool. It clearly differentiates itself by focusing on the trace feature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context: it is for regulated report output that needs claim-to-source verification, and it mentions how to disable (pass disable=true). However, it does not explicitly state when to use this versus alternatives, nor does it provide exclusions (e.g., when not to use it). The guidance is clear but implicit rather than explicit about competing choices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Nebelus toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources