Datacron

Overview Schema Source Related Servers Discussions Admin

Start a memory session

session_context

Read-only

Load versioned work rules, write capability, and bounded live notes to start memory-dependent tasks; optionally find ranked subject candidates with explicit coverage.

Instructions

Start memory-dependent work here. Return the versioned common discipline, effective write capability and bounded live notes. Optional subject finds ranked candidates without repairing the index. Coverage is explicit; candidates never establish a person's identity. Read next pages before relying on incomplete context. Send known_contract_hash only when that exact contract is already in context; a match returns its identity without repeating instructions.

Input Schema

Name	Required	Default
`domain`	No	all
`subject`	No
`max_tokens`	No
`note_paths`	No
`known_contract_hash`	No

Output Schema

Name	Required	Description	Default
`omitted`	No
`sources`	No
`contract`	No
`coverage`	No
`evidence`	No
`identity`	No
`truncated`	No
`unavailable`	No
`capabilities`	No
`subject_state`	No
`index_repaired`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.1.17Oct 17, 2026
- addedOutput schema / description
```
Added value: +"Bounded initialization; returned context is not a behavior attestation."
```
- removedOutput schema / properties / capabilities / default
```
Removed value: -null
```
- removedOutput schema / properties / contract / default
```
Removed value: -null
```
- removedOutput schema / properties / coverage / default
```
Removed value: -null
```
- removedOutput schema / properties / evidence / default
```
Removed value: -null
```
- removedOutput schema / properties / identity / default
```
Removed value: -null
```
- removedOutput schema / properties / index_repaired / default
```
Removed value: -null
```
- removedOutput schema / properties / omitted / default
```
Removed value: -null
```
- removedOutput schema / properties / sources / default
```
Removed value: -null
```
- removedOutput schema / properties / subject_state / default
```
Removed value: -null
```
- removedOutput schema / properties / truncated / default
```
Removed value: -null
```
- removedOutput schema / properties / unavailable / default
```
Removed value: -null
```

Changed1 schema field changedv0.1.16Oct 1, 2026

addedOutput schema / properties / subject_state

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Subject State"
+}

Changed1 schema field changedv0.1.11Sep 15, 2026

addedInput schema / properties / known_contract_hash

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Known Contract Hash"
+}

Addedv0.1.5Sep 5, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered; the description still adds real value beyond them: pagination behavior, that coverage is explicit, that candidates never establish identity, and that a matching contract hash short-circuits instruction repetition. No auth/rate-limit detail, hence not a 5.

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

Conciseness3/5

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

Front-loaded with purpose and reasonably tight at five sentences, but the phrasing is dense and cryptic ('common discipline', 'repairing the index', 'coverage is explicit'), which costs clarity without obvious economy gains.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be detailed, and the description usefully covers contract-hash and paging behavior. Against a five-parameter, zero-coverage schema, though, the omission of domain, max_tokens, and note_paths semantics leaves the definition incomplete for an agent trying to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry semantics for all five parameters. It explains subject ('finds ranked candidates without repairing the index') and known_contract_hash (when to send, what a match returns), but says nothing about domain, max_tokens, or note_paths, leaving three parameters undefined in both schema and prose.

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 opening 'Start memory-dependent work here' states a clear verb and entry point, and the returns are named (versioned common discipline, effective write capability, bounded live notes). It is distinguishable from the sibling read/patch/search tools. However the terminology ('common discipline', 'repairing the index') is idiosyncratic enough that the resource being fetched is not fully transparent.

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 gives a clear context cue ('start memory-dependent work here'), a conditional for known_contract_hash ('send only when that exact contract is already in context'), and an instruction to page ('Read next pages before relying on incomplete context'). What is missing is any explicit naming of alternative siblings or when-not-to-use guidance.

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