Skip to main content
Glama

report_friction

Submit feedback when Hivelore tooling fails, misleads, or lacks clarity — bugs, suggestions, and docs issues are logged locally for maintainer review.

Instructions

Tell Hivelore's maintainer that HIVELORE ITSELF got in your way — a bug in a Hivelore tool, a misleading message, wrong docs, or an improvement idea.

USE THIS WHEN the friction is with Hivelore, not with the project you are working on:

  • a Hivelore tool or command errored, or did something other than what it documented

  • a message or return value misled you into a wrong action

  • the docs/description for a tool were wrong, missing, or contradictory

  • you can see a concrete improvement to how a Hivelore tool behaves

DO NOT USE for anything about the project's own code → that is mem_tried (a failed approach) or mem_save (a gotcha/convention). This tool is only for feedback ON THE TOOLING.

STAYS LOCAL. Nothing is published: the report is appended to a machine-local journal under .ai/.runtime/ and a human reviews it with hivelore report list before anything reaches a public tracker. Never put secrets or customer code in a report.

EVIDENCE BAR: kind='bug' REQUIRES a runnable repro. Without one the report is still kept, but filed as 'suggestion' — an unreproducible bug claim cannot be acted on.

DEDUPLICATED: reports are fingerprinted on kind+surface+summary. If you get back already_reported=true, the point is already made — do not rephrase and send it again. The occurrence count is what ranks it for the maintainer.

PARAMETERS: kind — bug | suggestion | docs | confusing surface — the Hivelore tool or command involved (e.g. 'mem_save', 'enforce check') summary — one specific line stating the problem (this is the dedup key) expected — what you expected Hivelore to do observed — what it actually did (exact message or output) repro — a command/tool call that reproduces it, runnable as-is (required for 'bug')

RETURNS: { ok, kind, fingerprint, occurrences, already_reported, notice? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes'bug' = Hivelore did the wrong thing (REQUIRES `repro`; without one it is filed as a suggestion); 'suggestion' = an improvement idea; 'docs' = the documentation was wrong or missing; 'confusing' = it worked but the output/naming misled you.
reproNoThe command or tool call that reproduces it, runnable as-is. Required to file a 'bug'.
summaryYesOne line stating the problem, as specifically as you can. This is the dedup key.
surfaceYesThe Hivelore surface involved — an MCP tool or CLI command, e.g. 'mem_save', 'enforce check', 'sensors propose'. Used to group reports, so name the tool, not the file.
expectedNoWhat you expected Hivelore to do.
observedNoWhat it actually did — the exact message or output.
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 and delivers richly. It discloses that reports stay local, are not published, and are reviewed manually. It explains deduplication behavior via fingerprinting and the occurrence counting mechanism, and details the evidence bar where 'bug' requires a repro.

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 with clear sections and front-loaded purpose. It is thorough but not verbose, using bullet-like formatting. A slight deduction for length; while informative, it could be tightened slightly without losing clarity (e.g., 'EVIDENCE BAR' section could be more concise).

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?

Given 6 parameters, 3 required, no output schema, no annotations, and complexity of deduplication/evidence rules, the description provides comprehensive coverage. It explains return fields, behavior, and constraints, making it complete enough for an agent to invoke correctly without gaps.

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 baseline is 3. The description adds significant value by explaining each parameter's purpose in context (e.g., 'kind' enum meanings, 'surface' grouping logic, 'summary' as dedup key, 'repro' requirement for bugs), but some details like 'expected' and 'observed' are straightforward and the schema already describes them adequately.

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 clearly states the tool is for reporting friction with Hivelore itself, using specific verbs ('Tell', 'get in your way') and explicitly distinguishes it from sibling tools like mem_tried and mem_save, which are for project-level issues. The scope is unambiguous.

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 provides explicit guidance on when to use this tool (list of Hivelore-related issues) and when NOT to use it (project code issues), naming sibling alternatives (mem_tried, mem_save). It also covers deduplication and evidence requirements.

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