Skip to main content
Glama

store

Persist structured entities, raw files, or both together with provenance, deduplication, and relationship support.

Instructions

Unified storing for structured, file-backed, or combined payloads in one request. Choose path by source: file- or resource-sourced (attachment/file to preserve) → use file_content+mime_type or file_path; conversation- or tool-sourced (chat or other MCP) → use entities. You may send both entities and file input in the same call. File bytes create a content-addressed sources row (SHA-256 dedup per user); the response includes source_id / content_hash for the unstructured leg. The server does not invent structured fields from opaque blobs without an explicit interpretation block or a separate interpretation flow. Agents should parse and extract entities first when they need structured data from a readable file, then send those entities alongside the raw file. IMPORTANT FOR STRUCTURED DATA: Include ALL fields from source data. Schema fields go to observations; non-schema fields go to raw_fragments for future schema expansion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commitNoWhen false, runs in plan/dry-run mode: resolves entities and returns planned actions ("would_create" / "would_match_existing") without persisting observations or source rows. Useful for previewing a structured store before committing.
strictNoWhen true, refuse silent merges: only match an existing entity when the entity's schema declares canonical_name_fields that the request matches, or when target_id is supplied. Prevents accidental coalescing into a pre-existing record.
user_idNo
entitiesNo
file_pathNoLocal file path (alternative to file_content). If provided, file will be read from filesystem. MIME type will be auto-detected from extension if not provided. Works in local environments (Cursor, Claude Code) where MCP server has filesystem access. Does NOT work in web-based environments (claude.ai, chatgpt.com) - use file_content for those.
mime_typeNoMIME type (e.g., 'application/pdf', 'text/csv') - required with file_content, optional with file_path (auto-detected from extension)
file_contentNoBase64-encoded file content. Use file_path for local files instead of base64 encoding.
relationshipsNoOptional. Create relationships between entities in this request. Use `source_index` or `target_index` for entities in this request, and `source_entity_id` or `target_entity_id` for existing entities. Index and id endpoints may be mixed in one relationship.
external_actorNoUpstream artifact author (e.g. GitHub user) stamped into observation provenance alongside AAuth agent attribution. Matches `ExternalActorInputSchema` in `action_schemas.ts`.
interpretationNoOptional interpretation provenance for source-derived structured extraction. Supplying this creates an interpretation row and links new observations to it. Omit for ordinary already-structured/chat-native facts, which keep observations.interpretation_id NULL.
source_peer_idNoOptional Neotoma peer id to stamp on observations for cross-instance sync loop prevention (Phase 5). Requires `observation_source: sync` in practice.
source_storageNoStorage mode for file ingestion. Default 'inline' copies bytes into the database (portable, durable). 'reference' stores only a path + metadata row without copying bytes — zero DB bloat, but host-local and depends on the file staying in place. Requires file_path (not file_content). Derivations (observations/entities) are still materialized at ingest. Use 'reference' for large local files you control; use 'inline' for anything that must be shared or portable.
idempotency_keyNoRequired for structured path, optional for unstructured-only path.
source_priorityNoTrust/priority of this observation's source. Only affects snapshot resolution for fields whose merge strategy is highest_priority (set via register_schema reducer_config); under the default last_write strategy it is stored but ignored.
original_filenameNoOriginal filename or source label (optional). For unstructured: auto-detected from file_path if not provided. For structured (entities): omit when data is agent-provided (no file origin); the source will have no filename. Pass only when mirroring a real file name or when a display label is desired.
observation_sourceNoClassifies the *kind* of write being performed, orthogonal to `source_priority`. See `Observation.observation_source` for the full semantic contract. Defaults to `llm_summary` when unspecified. Applies to every observation created by this request.
file_idempotency_keyNoOptional idempotency key for file path when sending structured + unstructured in one call.
Behavior4/5

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

With no annotations provided, the description shoulders the disclosure burden. It discloses content-addressed storage ('SHA-256 dedup per user'), response content ('source_id / content_hash'), and the no-auto-interpretation behavior ('server does not invent structured fields... without an explicit interpretation block'). It doesn't mention merge/overwrite behavior, but the disclosed details go well beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a well-structured paragraph with no fluff. Each sentence contributes new information: purpose, routing, combined-call capability, file behavior, interpretation limitation, and field-handling rule. It front-loads the most important 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 17-parameter tool with nested objects and no output schema, the description covers the core ingestion model (entities vs files, combined requests, dedup, interpretation, field routing). It does not cover relationships, commit/strict modes, or provenance fields, but those are documented in the schema with high coverage.

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 88%, so the schema already documents most parameters. The description adds value by mapping source types to parameter groups (file_content+mime_type/file_path vs entities), and by explaining field routing ('Schema fields go to observations; non-schema fields go to raw_fragments'). This supplements the schema's per-field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Unified storing for structured, file-backed, or combined payloads in one request,' clearly identifying the tool as a combined ingestion endpoint for entities and files. It doesn't explicitly name sibling alternatives, but the source-routing instructions ('file- or resource-sourced → use file_content+mime_type or file_path; conversation- or tool-sourced → use entities') clarify what it stores and how to select the right input.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers explicit decision rules: 'Choose path by source' with mapping to file vs entities parameters, and advises 'Agents should parse and extract entities first... then send those entities alongside the raw file.' It lacks a when-not-to-use statement or sibling tool references, but the routing guidance is concrete and actionable.

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/markmhendrickson/neotoma'

If you have feedback or need assistance with the MCP directory API, please join our Discord server