Skip to main content
Glama

zerodom_set_scope

Set allowed host globs, denied destructive actions, and max requests per second to keep an unattended agent inside authorized scope.

Instructions

Constrain the hunt to authorized targets — enforced in code, not on trust.

hosts: comma-separated in-scope host globs (app.example.com,*.example.com). Navigation, replay and clicks to any other host are then refused. deny: a regex of destructive URLs/labels to refuse (default covers logout/delete/ remove/deactivate/revoke) so an unattended agent can't take an irreversible action. max_rps: throttle to at most N requests/second (program rate limits).

An operator can instead lock scope before the agent starts by setting the ZERODOM_SCOPE env var to a YAML file; a locked scope can't be widened here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
denyNo
hostsYes
max_rpsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.9

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that navigation, replay, and clicks to unauthorized hosts are refused, that deny is a regex to block destructive actions, and that max_rps throttles requests. It also discloses the limitation that a locked scope cannot be widened. This is thorough and transparent.

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

Conciseness4/5

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

The description is slightly verbose but well-structured: the main purpose is front-loaded, followed by a parameter explanation block, and then an important constraint about the env var. Every sentence adds value, though a few could be tightened. It is not wasteful and is easy to scan.

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

Completeness5/5

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

For a security-sensitive configuration tool, the description covers purpose, usage, all parameters, behavioral effects, and limitations. It mentions the env var lock and that a locked scope cannot be widened. Since an output schema exists, return values are not required. An agent has all necessary information to invoke this tool correctly and understand its consequences.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully explain the parameters. It does: hosts as comma-separated globs with examples, deny as a regex with default patterns, max_rps as a throttle. This adds significant meaning beyond the raw schema, which only provides types and titles. Each parameter's semantics are precisely defined.

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 a specific verb ('constrain'), a clear resource (authorized targets), and explains the enforcement mechanism ('enforced in code, not on trust'). It clearly distinguishes from sibling tools which are about other operations like cookies, storage, or navigation. The purpose is unambiguous and immediately apparent.

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

Usage Guidelines5/5

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

The description explicitly explains when to use the tool (to constrain the hunt) and provides a critical exclusion: an operator can lock scope via ZERODOM_SCOPE env var, and once locked, the scope cannot be widened here. It also describes the effect of each parameter, giving clear context for when to set deny or max_rps. This is comprehensive guidance.

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