Contextick

Use this when the user asks what is new in their knowledge rather than about a topic — a catch-up rather than a lookup. Not for finding something by subject, which search does, and not for reading an item in full, which get does. Examples: "what did I add since Monday?", "catch me up on what I've saved", "anything new since we last talked?" It is a cursor-based incremental feed over insertion order. since sets the starting point on the first call, and every response carries a cursor that continues from where that page ended. Items come back with their titles and summaries; the full text comes from get. Ordering is ascending, so a page holds the oldest items after the cursor rather than the most recent ones — a period is expressed with since, not with a small limit. The feed carries additions only: an item deleted afterwards is simply absent, and an item whose status changes later does not reappear, because that is not a new item. A file uploaded from the dashboard arrives as a long run of parts rather than as one item — help(topic: "upload") covers that. The same events can also be posted to a URL the account owns rather than pulled here — help(topic: "webhooks") has that contract, to read when the user asks about being notified rather than asking.

changes

Use this when the user wants you to forget saved items — pass one or more ids from a prior search result. Permanently removes them from the user's knowledge and can't be undone, so confirm which items with the user before deleting. If you are replacing an item with a revised version, save the new version first and delete the old id only after that save succeeded — deleting first loses the original.

delete

Use this when the user wants a whole uploaded file gone rather than one item — e.g. "delete that PDF I uploaded" or "get rid of the whole report, not just this piece". It takes the group label the parts of an upload share, which search, get, changes and the opened lists return on any item that came from one, and removes every part carrying that exact label. Removal is permanent and cannot be undone, and it is all of the file at once rather than the part the user was looking at. Items saved directly, and parts of other uploads, carry different labels and are left alone.

delete_group

Use this when the full text of a saved item is needed — to quote it, or because the user wants to change something they already saved. Not for finding the item in the first place, which search does, and not for scanning many items, since each one opened is counted as used. Examples: "show me that note in full", "what exactly did I write about the pricing page?", "open the one about the coffee idea" Pass the id from a prior search, changes, or group listing. Returns that item's whole content. Search results carry summaries rather than full text, so a revision built from one is missing the rest of the original — this is the only way to read it. Opening an item is what least_opened and most_opened rank by, so opening a run of them at once changes what those lists mean.

get

Use this when the user asks about the whole uploaded file an item came from rather than about a topic — how much of it is ready, or what else is in it. Not for reading the text of a part, which get does by id, and not for finding an item in the first place, which search does. Examples: "show me the rest of that report", "how much of that upload is ready?", "what else came from that PDF?" A file uploaded to Contextick is stored as numbered parts that share one group label, and search, get, changes and the opened lists hand that label back on any item that came from an upload. This lists every part of that file, in order, with the state of each. The title is shared, so it is given once for the whole file and the parts come back as ids and states — a part's text comes from get, by its id. It is a listing rather than a read: nothing is opened by being listed here. Parts of one file can differ in state, because each is prepared on its own. Where files come from and how long preparation takes are in help(topic: "upload").

get_group

Use this when the user asks how to do something with Contextick that no tool here does — reach it from their own code, be notified when something is saved, or put a file in. Not for recalling what they saved, which search does, and not for anything already answered by the tool being used. Examples: "how do I get notified when a note is saved?", "can I add notes from a script?", "how do I put a PDF in?" Topics: - api — the HTTP API for reading and writing from their own code: endpoints, auth, request and response shapes, cursors, error codes. - webhooks — having Contextick post an event to a URL the account owns: event types, payload, signature verification, retries, idempotency. - upload — putting a file in: where that happens, which formats and what size, and how its parts appear here. A topic returns its whole contract as text — enough to write the code from, and enough to answer a follow-up when something does not work. Values that are specific to one account, such as an API key or a signing secret, are not here; each topic says which screen holds them.

help

Use this when the user wants to look over what they have saved by how much use it has had — the ones they never return to. Not for what is new or what changed, which changes covers, and not for finding something by subject, which search does. Examples: "what have I saved and never looked at?", "which notes am I not using?", "anything I saved and forgot about?" It is a ranking over everything saved, not a feed: items are ordered by how many times their full text has been opened, fewest first, and n takes the head of that ranking. Order comes only from how often each item was opened. When it was saved has no part in it, so nothing here says anything about what is recent. It sorts rather than filters, so every saved item is somewhere in the ordering, and the header states how much of the whole store is in view. There are no pages — the same call returns the same items. most_opened is the same ranking read from the other end, so the two overlap rather than divide the items between them.

least_opened

Use this when the user wants to look over what they have saved by how much use it has had — the ones they keep coming back to. Not for what is new or what changed, which changes covers, and not for finding something by subject, which search does. Examples: "what do I reference the most?", "which notes have I actually leaned on?", "what keeps coming up in my saved stuff?" It is a ranking over everything saved, not a feed: items are ordered by how many times their full text has been opened, most first, and n takes the head of that ranking. Order comes only from how often each item was opened. When it was saved has no part in it, so nothing here says anything about what is recent. It sorts rather than filters, so every saved item is somewhere in the ordering, and the header states how much of the whole store is in view. There are no pages — the same call returns the same items. least_opened is the same ranking read from the other end, so the two overlap rather than divide the items between them.

most_opened

Use this when the user wants to keep something worth coming back to — a code snippet, an idea, a design or decision, a report, or research notes ("save this", "remember these findings"). Before saving, shape it into a clear title, a self-contained note, and a short summary. Keep the content faithful — don't summarize or drop parts to make it fit. Content is capped at 16,000 characters per call; if it runs longer, split it into coherent parts and call save once per part so nothing is lost. When saving a revised version of something already stored, first call get to read the original in full, then save the entire updated note — the whole thing with the change applied, not just the changed part — because search results are summaries, not the full text, and revising from them loses the rest. Adds it to the user's knowledge so you can pull it back later with search.

save

Use this when the user refers to something they saved earlier — a past note, decision, idea, or piece of research — or when answering well depends on that context. Not for general knowledge or anything the user has not stored themselves, and not for what is new rather than what it is about, which changes covers. Examples: "what did we decide about the pricing page?", "pull up my notes on that coffee idea", "didn't I write something about this?" What comes back was saved in other conversations, and possibly through a different AI, so this conversation does not need to contain it. Whether the user has something stored on a subject is not visible in the conversation itself. It matches on meaning, so items that share no word with the request still come back, ranked by how close they are. Each item comes back as its summary rather than its full text, which get returns for one item by id.

search