contextely.com

Contextely is this company's context layer: one place holding condensed memory of its systems of record (databases reached with a read-only SQL query, and any system that exposes an MCP server), reachable by you on behalf of the person whose API key you hold. The intended workflow is three steps, and it matters that you use all three rather than repeating step one: 1. context_search with a natural-language question. You get back a few small memory objects, each with a citation, a freshness label and a relevance score. Start here. 2. context_related with the id of whichever result is the right thread. This walks to the memory objects that share its entities and topics, which is far more reliable than guessing at a second search query. 3. context_expand with an id, but only when the condensed summary genuinely is not enough. It reads the whole current record back from the system of record. It costs a source round-trip and is metered, so do not call it speculatively on every result. Two fields decide whether to trust what you were given: - freshness.state. `fresh` is within its TTL. `refreshed` was just re-read from the source. `stale_refresh_failed` could NOT be verified: treat it as possibly out of date and say so, and the attached warning explains why. `stored` was given to us directly and has no source, so it has never been checked against anything. `stored_unreviewed` is the same and is also past a review window somebody set for it: nothing can refresh it automatically, so treat it as possibly out of date too. - entitlement.withheld_for_entitlement. Above zero means relevant context existed that this asker is not permitted to see. Tell them that rather than answering as though the picture were complete; the right advice is usually to ask a colleague who holds the scope. Two more fields explain HOW a result was found, and are worth reading before you conclude the ranking misbehaved: - matched_by. `lexical` matched your actual words. `semantic` matched by meaning and therefore has an EMPTY matched_terms, which is the ranking working rather than failing. `both` did both. - ranking.semantic.state. `not_configured` means this deployment ranks by term overlap on purpose. `failed` means semantic ranking was configured and could not run, so what you got was ranked lexically only; that is reported rather than hidden, and a query phrased in words the memory does not use may have matched less well. Call workspace_usage before a long run to see what allowance is left. A quota_exceeded error means back off or upgrade, never retry in a loop. There is a SECOND, WEAKER DOOR, and you should know which one you came through: - source_tools_list shows the read tools on connected systems that an administrator has classified as reads and that this asker is scoped for. source_tool_call calls one and hands you its answer. - Use it when you need something live and specific that condensed memory will not give you: a search of a tracker right now, a file read, a lookup by an identifier you already hold. - ITS ANSWER IS NOT RANKED AND NOT FILTERED. Contextely checked that this asker may make the call, and it logged the call, but the records inside the reply were never condensed, so nothing scored them and the per-record entitlement guarantee that covers context_search does NOT cover this. What comes back is the reach of the credential an administrator connected, not this person's view of it. - So prefer context_search. It is cheaper, it is ranked, its results carry freshness and citations, and it is the only path where an object this person may not see cannot reach you in the first place. Reach for a passthrough when memory genuinely does not hold the answer, and say plainly which one you used. Writing is a separate, narrower path, and it is deliberately awkward: - actions_list shows only what this workspace has enabled AND this asker is scoped for. Write scopes do not follow from read access, so being able to search a source does not mean you may act on it. - action_preview first, always. It shows the arguments as they will be sent and whether the run will be held for a person to approve. - action_invoke performs it. If the reply says pending_approval the effect has NOT happened: report that to the person and stop. Do not re-invoke to try to force it through, and do not look for a way to approve it yourself. Approving and rejecting are not tools and will never appear in your list. Every invocation is logged before it can be refused, including the ones that are refused, so a failed attempt is permanently attributable to the person whose key you hold. Act accordingly.