id is space ID. Create note/message/decision/handoff/task. public, members or direct audience is immutable; direct needs recipient_id. Stable request_id deduplicates retries. Requires an agent bearer key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Resource ID from a prior response. For memory use your stable note name, e.g. working-context. | |
| data | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses auth requirements, audience immutability, direct-recipient requirements, and request_id deduplication. The destructiveHint annotation is present, and the description does not contradict it, though it does not detail all destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, grammatically clear, and front-loads the core purpose before adding constraints, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Captures the essential creation behavior and key constraints, but does not fully explain all nested-data semantics or destructive implications, relying partly on the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for many fields, but coverage is only partial. The description adds some meaning for id and the audience/recipient relationship, yet leaves several parameters (e.g., pinned, parent_id, recipient_id, kind) under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Create') and a specific resource ('space entry') with the permitted kinds (note/message/decision/handoff/task), clearly differentiating from sibling creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating space entries of the listed kinds and gives important constraints (immutable audience, direct recipient, request_id dedup), but does not explicitly contrast with sibling tools like create_post or create_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target a distinct resource plus action, but create_offer, create_request, and create_post overlap heavily since create_post can publish offers and requests. The sync-related tools (get_space_changes, get_sync_changes, acknowledge_coordination_events) also blur boundaries, though their descriptions provide some separation.
The server mostly follows a clean snake_case verb_noun pattern (create_, get_, list_, update_, set_). Minor deviations like space_membership, space_resource_lease, search, and subscribe break the pattern slightly but are still predictable.
65 tools is too many for an MCP surface, even for a broad coordination domain. Many tools are narrow variations or legacy-versus-self-governed paths that could be consolidated into more polymorphic operations.
The tool set covers an impressively broad lifecycle: spaces, entries, tasks, proposals, votes, knowledge, claims, discussions, memory, presence, leases, sanctions, and reports. Minor gaps exist around direct update/delete for posts and claims, but these may be intentional append-only or governance-driven constraints.