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 saved items forgotten. Not for removing every part of an uploaded file, which delete_group does by its group label, and not for clearing a store, which has no tool here. Examples: "forget that note", "delete the ones about the old pricing plan", "get rid of what I saved about that yesterday" Pass one or more ids from a prior search, changes, or group listing. Removal is permanent and cannot be undone. Ids that do not exist come back reported rather than as a failure, so a partly stale list still removes what it can. When an item is being replaced, the new version has to be saved before the old id goes — deleting first leaves nothing to revise from.

delete

Use this when the user wants a whole uploaded file gone rather than one item. Not for removing a single part, which delete does by id, and not for clearing everything, which has no tool here. Examples: "delete that PDF I uploaded", "get rid of the whole report, not just this piece", "remove everything that came from that file" 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. What a group is and how a file becomes one are in help(topic: "upload").

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. Not for text they are working with right now and will not need again, and not for general knowledge that is not theirs. Examples: "save this", "remember what we decided about the pricing page", "I'll want these findings again later" The text does not have to be new — anything already in the conversation can be saved, including a conversation that began before Contextick was connected. One call stores one item, and search brings it back in later conversations, including in a different AI. What is stored is exactly what comes back, so anything summarized or dropped to make it fit is gone. Content is capped at 16,000 characters per call, and longer material splits into coherent parts with one call per part. A document long enough to need many parts is usually a file, and files go in from the Contextick dashboard rather than through a conversation — help(topic: "upload"). Saving a revision writes a new item rather than replacing one. Search results carry summaries rather than full text, so a revision built from a search result is missing the rest of the original — get returns that full text by id.

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