Skip to main content
Glama

propose_sensor

Propose a discriminating sensor that catches faulty code patterns while ignoring correct usage. Hivelore validates the pattern against good and bad examples before accepting it as a block 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.
replaceNoSet true to DELIBERATELY replace a sensor already hand-authored on this memory. Without it, a second proposal onto a memory that already carries a validated sensor is REFUSED — otherwise the second call silently destroys the first while still answering accepted:true. One memory holds one sensor; use a separate memory for a second, distinct symptom.
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.
require_presentNokind=regex: make this a REQUIRED-PRESENCE invariant instead of a forbidden-pattern one. `pattern` then names a line that must REMAIN in the anchored file; the sensor FIRES when a change REMOVES it. Use for 'do not delete this critical line' lessons a diff-of-added-lines sensor cannot see. Validated by requiring the pattern to be PRESENT in the current anchored code (there must be something to guard).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv0.57.7
    • addedInput schema / properties / replace
      Added value: +{
      +  "default": false,
      +  "description": "Set true to DELIBERATELY replace a sensor already hand-authored on this memory. Without it, a second proposal onto a memory that already carries a validated sensor is REFUSED — otherwise the second call silently destroys the first while still answering accepted:true. One memory holds one sensor; use a separate memory for a second, distinct symptom.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / require_present
      Added value: +{
      +  "default": false,
      +  "description": "kind=regex: make this a REQUIRED-PRESENCE invariant instead of a forbidden-pattern one. `pattern` then names a line that must REMAIN in the anchored file; the sensor FIRES when a change REMOVES it. Use for 'do not delete this critical line' lessons a diff-of-added-lines sensor cannot see. Validated by requiring the pattern to be PRESENT in the current anchored code (there must be something to guard).",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility and does so thoroughly. It discloses the validation process, that rejected proposals are not written, that the return object contains self_check and reason/guidance, and that a second proposal is refused unless replace=true to prevent silent destruction. It also explains the absent-parameter discrimination and the validation criteria (not brittle, silent on correct code, fires on bad example).

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 long but well-structured with labeled sections (USE THIS, VALIDATION, PARAMETERS, RETURNS). It front-loads purpose and usage before parameters. Every sentence adds necessary context for correct invocation, and the length is justified by the tool's complexity (17 parameters, multiple kinds, validation logic).

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?

The description is complete for a tool of this complexity. It covers when to use, how to construct the pattern and absent, validation criteria, return values (accepted, reason, guidance, self_check, file_path), and edge cases like replace semantics and the absence of bad_example. There is no output schema, but the description explicitly names the return fields. Nothing an agent needs to call this correctly is missing.

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 schema description coverage is 100%, the tool description adds significant semantic value beyond the schema. It explains the role of 'pattern' vs 'absent', gives an example (pattern=the API call, absent=the required option), and clarifies the meaning of bad_example and severity. It also explains the replace flag's dangerous behavior and how to avoid it, which is not in the schema.

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 and resource ('Propose a discriminating sensor for a gotcha/attempt') and clearly distinguishes this from sibling memory tools (mem_save, mem_tried) by positioning it as the follow-up step that upgrades a warning to a blocking sensor. It explicitly says 'YOU write the pattern' and explains the validation role of Hivelore, leaving no ambiguity about what the tool does.

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?

Explicit usage guidance is given: 'USE THIS right after mem_tried / mem_save on a gotcha whose mistake is detectable in code'. It also explains when a proposal is rejected and tells the agent to call again, and warns against re-proposing onto a memory with an existing sensor unless replace=true. This is clearer than most tool descriptions.

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

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