Skip to main content
Glama
Sign In
Gnosys

Gnosys

by proticom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

gnosys_reinforce

Record usefulness feedback for a single memory using useful, not_relevant, or outdated signals to reinforce it, flag routing misses, or mark it for review.

Instructions

Record usefulness feedback for one memory, returning a signal confirmation. useful increments reinforcement and resets decay; not_relevant records a routing miss without changing the memory; outdated marks it for review. Use gnosys_reflect instead to record an outcome memory, link evidence, and adjust confidence; repeated useful calls reinforce again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "memory_id": "<memory_id>",
      "signal": "<signal>"
    },
    "name": "gnosys_reinforce"
  }
}

Input Schema

NameRequiredDescriptionDefault
signalYesThe reinforcement signal
contextNoWhy this signal was given
memory_idYesThe memory ID (from frontmatter)
projectRootNoProject root path; routes the call to that project's store.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv7.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, destructiveHint=false and idempotentHint=false; the description adds real substance by disclosing the side effect of every signal branch: useful increments reinforcement and resets decay, not_relevant records a routing miss without mutating the memory, and outdated only marks it for review. That both explains the non-idempotency hint and reassures the agent that two of three branches are effectively non-destructive.

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 effect of the tool is front-loaded in the first clause before the branch semantics and the sibling exclusion, which is the right ordering. The semicolon-chained enumeration of signal effects is dense but every clause carries distinct information; only the trailing repeat-behaviour note could be tightened.

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?

For a 4-parameter tool with full schema coverage and no output schema, the description covers what is needed: what changes per signal, what is returned, and when to choose the sibling. Minor gaps remain around projectRoot routing and whether the signal confirmation has any payload, but nothing blocks a correct call.

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, and the description earns above that by giving behavioural meaning to the signal enum values rather than restating the field. It adds nothing about context or projectRoot, which is acceptable since the schema already describes both.

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 first clause names a specific verb and resource ("Record usefulness feedback for one memory") and states the return ("signal confirmation"). It goes further by spelling out the effect of each of the three signal values, so the agent knows exactly what operation it is selecting without opening the schema.

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?

It names the alternative sibling explicitly ("Use gnosys_reflect instead to record an outcome memory, link evidence, and adjust confidence") and gives the condition that selects it. It also clarifies repeat behaviour ("repeated useful calls reinforce again"), removing the main ambiguity about calling this tool more than once.

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

Deploy Server

Other Tools