Skip to main content
Glama

propose_sensor

Convert a captured gotcha into a discriminating sensor that blocks faulty code by matching the mistake pattern while ignoring correct usage via an absent regex. Validates the proposal against real examples before it becomes a reliable gate.

Instructions

Propose a discriminating sensor for a gotcha/attempt — YOU write the pattern (you understand the code), Hivelore validates it before trusting it to block. This is how a captured lesson becomes a RELIABLE block instead of an advisory note.

USE THIS right after mem_tried / mem_save on a gotcha whose mistake is detectable in code, to upgrade the auto-suggested (warn) sensor into a precise, promotable one.

Write a pattern that matches the FAULTY usage, and — crucially — an absent regex for the CORRECT-usage marker so it fires on the bug only, not every call (e.g. pattern=the API call, absent=the required option).

VALIDATION (a block proposal is accepted ONLY if): the pattern is not brittle, stays SILENT on the current (correct) anchored code, and FIRES on the bad example. A rejected proposal is NOT written — the returned reason/guidance tells you how to revise; then call propose_sensor again.

PARAMETERS: memory_id — the gotcha/attempt to protect pattern — regex matching the faulty usage absent — regex for the correct-usage marker (makes it discriminate) — strongly recommended bad_example— a snippet that SHOULD match (else examples are read from the lesson) severity — 'block' (default) | 'warn'

RETURNS: { accepted, reason?, guidance?, self_check, file_path? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoregex = pattern matched on added diff lines (default). ast = an ast-grep STRUCTURAL pattern (e.g. 'stripe.paymentIntents.create($$$)') matched on the AST of changed files — comments and strings can never false-positive; `absent` is a sub-pattern that must be missing INSIDE the match (requires the optional @ast-grep/napi engine). shell|test = a COMMAND the gate runs when the diff touches the sensor's paths — routes the team's own oracle (an existing test, an invariant script) to this lesson. Command sensors only execute where enforcement.runCommandSensors=true.regex
ruleNokind=ast: full ast-grep Rule object (kind/inside/has/not/all/any/etc.). May be used alone or combined with pattern.
flagsNoOptional regex flags (e.g. 'i' for case-insensitive).
pathsNoOverride scope paths. Defaults to the memory's anchor paths.
absentNoRegex for the CORRECT-usage marker (e.g. 'idempotencyKey'). When it appears in the window around a match, the catch is suppressed — this is what makes the sensor discriminate the faulty call from the correct one. STRONGLY recommended for 'X without Y' lessons.
commandNokind=shell|test: command to execute (e.g. 'npx vitest run tests/payments/refund.spec.ts'). Non-zero exit = the lesson fires.
messageNoLLM-facing fix message shown when it fires. Defaults to one derived from the lesson.
patternNokind=regex: regex matching the faulty usage; kind=ast: optional structural pattern (may be combined with `rule`).
red_refNokind=shell|test: prove the oracle actually catches the incident. A git ref (commit/branch) of the PRE-FIX state; validation replays it in a scratch worktree and requires the command to FAIL there (RED) in addition to passing on the current tree (GREEN). On success the sensor records red_proven: true — 'the test demonstrably catches the incident', shown in the prevention receipt.
incidentNoProvenance: the real incident this sensor guards — a ticket/prod ref ('prod #442', 'INC-1029', '2026-06 refund overcharge'). Turns 'a test failed' into 'this reproduces the incident the test exists to prevent'. Surfaced in the block message and the prevention receipt. Strongly recommended for command/test sensors routed from a post-incident test.
languageNokind=ast: explicit built-in/dynamic language name for non-standard file extensions.
severityNoblock = hard-fail the gate (accepted ONLY if it passes self-validation). warn = advisory.block
memory_idYesId of the gotcha/attempt memory this sensor protects.
timeout_msNokind=shell|test: max runtime before the executor kills the command (default 120000).
bad_exampleNoA code snippet that SHOULD match — proves the sensor catches the mistake. If omitted, examples are read from the lesson body.
Behavior5/5

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

The description is exceptionally transparent: it discloses that proposals are validated before being trusted, rejected proposals are NOT written, and the return shape includes reason, guidance, self_check, and file_path. It also clarifies validation conditions (silent on correct code, fires on bad example) and the importance of the `absent` regex for discrimination. This is strong behavioral disclosure given no annotations are provided.

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 well-structured, front-loaded with purpose and usage, and each paragraph has a distinct role. However, the PARAMETERS section redundantly repeats 5 parameters' descriptions already present in the schema, adding some unnecessary length. Overall, it remains efficient and 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 tool with 15 parameters, no output schema, and nested objects, the description is remarkably complete. It covers purpose, when to use, validation rules, rejection behavior, return shape, and key parameter semantics. The schema handles the full parameter syntax, and the description provides the essential 'why' and 'how' context.

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?

Even though the schema describes all 15 parameters with 100% coverage, the description adds significant conceptual meaning: it explains how `pattern` and `absent` work together, gives an example, and clarifies `bad_example` as proof and `severity` defaults. This goes beyond the schema's field descriptions, enriching the agent's understanding.

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 explicitly states the verb 'Propose' and the resource 'a discriminating sensor for a gotcha/attempt', and explains the user writes the pattern while Hivelore validates it. It also contrasts this with an advisory note, clearly establishing the tool's role and differentiating it from related memory operations like mem_save and mem_tried.

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?

Directly instructs when to use: 'USE THIS right after mem_tried / mem_save on a gotcha whose mistake is detectable in code'. It also explains the goal (upgrading a warn sensor to a precise, promotable one) and provides validation criteria and guidance to call propose_sensor again if rejected.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Doucs91/hivelore'

If you have feedback or need assistance with the MCP directory API, please join our Discord server