For assistants and API clients

API and assistant terms

A Cooki token lets software act for one person: read how their household eats, fill a few days of their plan, read their shopping list, and record a cook. Holding a token means agreeing to the following.

1. One person, one token. A token is scoped to the account that minted it. Everything it reads or writes is that person's own record. Tokens are not to be shared, pooled, or used to act for anyone else.
2. Health data stays health data. A household's allergens are consumer health data. They are provided so that a client excludes what the household cannot eat, and for nothing else. They may not be stored beyond a short cache, combined with other data about the person, or disclosed to anyone.
3. No training, no retrieval corpora. Nothing obtained through the API may be used to train, fine-tune, evaluate or build a retrieval index for a machine-learning model.
4. No proxies. A client may not expose Cooki's data or tools to third parties through its own API, connector or marketplace. The connection is between the person's assistant and Cooki.
5. Short cache. Responses may be cached for at most 24 hours, and a revoked token's cache is to be discarded on the next request that fails.
6. Writes ask first. The two writing tools refuse until the person has been asked. A client that bypasses that step, or records a cook the person did not confirm, loses its token.
7. Nothing is bought here. The shopping list is a list. Cooki does not place orders, hand a list to a retailer, or carry prices, and a client may not present it as doing so.
8. Revocation. A person can revoke any token in settings at any time. Cooki may revoke a token that breaks these terms, without notice.

The server is a Model Context Protocol endpoint at /api/v1/mcp, taking a Cooki token as a bearer. Tokens are minted under Settings. How the dietary filter works, and its measured number, is on the safety page.