Skip to main content
Glama
proticom

Gnosys

by proticom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

gnosys_add_structured

Save a structured memory directly without an LLM call, using title, category, tags, and Markdown content; returns the memory ID, store label, and up to three active overlaps.

Instructions

Save a structured memory without an LLM call, returning its ID, store label, and up to three active overlaps. Supply title, category, tags, and Markdown content; store defaults to project, author to ai, authority to observed, and confidence to 0.8 (also used for an explicit zero). supersedes links comma-separated predecessor IDs; cross-scope or cross-project links require allowCrossScope=true. Use gnosys_update instead to change an existing memory or unlink a predecessor with superseded_by="".

Input Schema

NameRequiredDescriptionDefault
tagsYesTags object, e.g. { domain: ['auth'], type: ['decision'] }
storeNoTarget store (default: project)
titleYesMemory title
authorNoAuthor: human, ai (default), or human+ai
contentYesMemory content as markdown
categoryYesOpen category name, e.g. decisions, architecture, requirements, concepts, roadmap, landscape, open-questions, or how
authorityNoAuthority: declared, observed (default), imported, or inferred
relevanceNoSpace-separated keyword cloud for discovery search
confidenceNoConfidence from 0 to 1 (omitted or zero uses 0.8), e.g. 0.9 for verified evidence
supersedesNoComma-separated IDs of memories this replaces
projectRootNoProject root path; routes the call to that project's store.
allowCrossScopeNoAllow supersession across scopes or projects (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / author / description
      Added value: +"Author: human, ai (default), or human+ai"
    • addedInput schema / properties / authority / description
      Added value: +"Authority: declared, observed (default), imported, or inferred"
    • changedInput schema / properties / category / description
      Previous value: -"Category name"New value: +"Open category name, e.g. decisions, architecture, requirements, concepts, roadmap, landscape, open-questions, or how"
    • addedInput schema / properties / confidence / description
      Added value: +"Confidence from 0 to 1 (omitted or zero uses 0.8), e.g. 0.9 for verified evidence"
  2. 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 cover the safety profile (not read-only, not destructive, open-world, not idempotent). The description adds real context beyond that: the return payload (ID, store label, up to three active overlaps), the defaulting behavior for store/author/authority/confidence, and the notable quirk that an explicit zero confidence is treated as 0.8.

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?

Three dense sentences with the primary action and return shape front-loaded; no filler. The middle sentence packs defaults and link rules tightly enough that it reads slightly as a spec dump, but every clause carries information an agent needs.

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 12-parameter mutation tool with no output schema, the description covers return values, defaults, and the supersession constraint well. Minor gap: relevance and projectRoot routing are left entirely to the schema, so the picture is near-complete rather than complete.

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 parameters are already documented, but the description still adds value by restating the defaults and the non-obvious confidence-zero behavior, and by clarifying that supersedes is comma-separated and gated by allowCrossScope. It doesn't cover relevance or projectRoot routing, so it is not a full supplement.

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?

Opens with a specific verb + resource plus a distinguishing trait ('without an LLM call') and immediately states what is returned. It explicitly separates itself from gnosys_update, so an agent can route between the two without opening a 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?

Gives an explicit exclusion: use gnosys_update to change an existing memory or to unlink a predecessor via superseded_by="". It also states the precondition for cross-scope/cross-project supersession (allowCrossScope=true), so the branch conditions are spelled out rather than implied.

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