Skip to main content
Glama
Sign In
Connapse

Connapse

by Destrayon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

memory_space_create

Create a personal or team space to store facts, keeping user-specific details private or sharing useful knowledge with everyone in Connapse.

Instructions

Make a memory space to save facts in. Kind "personal" is yours alone: only you see its facts. Kind "team" is seen by everyone in this Connapse. Save to a personal space if it is about the user, their preferences or their own work; to a team space if it would be true and useful for others. If unsure, ask. Check memory_spaces first: no space is made for you, so make one only when none fits. Names are lowercase letters, numbers and hyphens.

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": {
      "name": "<name>",
      "kind": "<kind>"
    },
    "name": "memory_space_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes"personal" (only you see it) or "team" (everyone in this Connapse sees it)
nameYesName for the space, e.g. "halcyon-notes"
descriptionNoWhat belongs in this space, so you and others pick it for the right facts

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false, and the description adds genuinely new behavioral context: visibility scope for each kind (personal is private, team is shared across the Connapse) and the fact that no default space exists. It stops short of covering collision behavior — what happens if the requested name already exists — which matters for a create operation.

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?

Purpose is front-loaded in the first clause, followed by kind semantics, selection rules, the check-first prerequisite, and naming constraints — a logical order with little waste. Density is high but each sentence carries distinct information.

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 simple three-parameter creation tool with no output schema, the description covers what the agent must decide before calling: whether to create at all, which kind, and what name format is legal. Only the post-creation outcome (e.g., an identifier or how the new space is referenced later) goes unmentioned, a minor gap given no output schema exists.

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 baseline is 3, but the description adds constraints the schema lacks: names must use lowercase letters, numbers and hyphens. It also reinforces the semantic distinction between the two `kind` values with decision rules rather than just restating the enum meanings.

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 opening sentence gives a specific verb and resource: create a memory space for storing facts. It also names the sibling `memory_spaces` and explains the create-vs-check relationship, so an agent can distinguish the two without inspecting either 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?

Guidance is explicit and actionable: personal space for facts about the user or their own work, team space when the fact is useful to others, and 'If unsure, ask.' It also states the precondition clearly — no space is created automatically, so calling `memory_spaces` first is required before creating.

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