What can you do with this server?

This server lets AI assistants access and manage your Cozi Family Organizer lists and calendar. * Family: family_members – Retrieve family members with IDs, names, and colors for use as appointment attendees. * Lists: get_lists – Get a summary of all lists, optionally filtered by type (shopping or todo), with item and completion counts; create_list – Create a new list; delete_list – Delete a list. * List Items: get_list_items – Get items in a list (optionally include completed); add_item – Add an item to a list at a specific position; update_item – Update an item's text and/or completion status; remove_items – Remove one or more items. * Calendar: get_calendar – Get appointments for a month/year; create_appointment – Create an appointment with subject, start/end times (ISO datetimes), attendees, location, notes, and all-day flag; update_appointment – Partially update an appointment (fetch-and-merge, only specified fields changed); delete_appointment – Delete an appointment. * Read-Only Mode: When COZI_READ_ONLY=true, only read tools (family_members, get_lists, get_list_items, get_calendar) are exposed; create/update/delete tools are hidden.

How do I use Cozi MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cozi MCP Server add milk to the shopping list" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Cozi MCP Server

by mjucius

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Cozi MCP Server

An unofficial Model Context Protocol server that lets AI assistants like Claude read and update your Cozi Family Organizer lists and calendar.

Each user runs their own instance against their own Cozi account. Your credentials are stored in your MCP client's secure config (Claude Desktop's OS keychain, Smithery's encrypted session config, or your local environment) and never leave your machine — the author of this server has no access to your data.

Install

1. MCPB (recommended for Claude Desktop)

Download the latest .mcpb from the Releases page and double-click to install in Claude Desktop. You'll be prompted for your Cozi username and password — they're stored securely in your OS keychain.

This path requires no Node, npm, or Python install on your machine.

2. Smithery (for other MCP clients)

For Cursor, ChatGPT-style clients, or web agents that connect to Smithery-hosted servers:

Deploy on Smithery.ai →

Configure your Cozi credentials in the Smithery UI; each session runs in isolation with its own credential set.

3. npx (for power users)

Add this to your Claude Desktop claude_desktop_config.json (or any other MCP client config file):

{
  "mcpServers": {
    "cozi": {
      "command": "npx",
      "args": ["-y", "@mjucius/cozi-mcp"],
      "env": {
        "COZI_USERNAME": "you@example.com",
        "COZI_PASSWORD": "your-password",
        "COZI_READ_ONLY": "true"
      }
    }
  }
}

Requires Node 20+. The package will be downloaded on first run.

Set COZI_READ_ONLY=true to expose only read operations. In read-only mode, the server registers family_members, get_lists, get_list_items, and get_calendar; tools that create, update, or delete Cozi data are hidden from MCP clients. Omit the variable, or set it to any value other than 1, true, yes, or on, for the default read-write tool surface.

Related MCP server: AnyList MCP Server

Troubleshooting

Tools fail with "Authentication failed" even after I corrected my password

COZI_USERNAME and COZI_PASSWORD are read once, when the server process starts. Editing them in your MCP client's settings updates the stored config but does not reach a server that is already running — it keeps presenting the old credentials until it is respawned.

Fully quit and relaunch your MCP client (on macOS, Cmd-Q rather than closing the window). Reloading, reconnecting, or toggling the extension off and on is usually not enough.

How do I tell which version is actually running?

The running server advertises its version in the MCP handshake; your client displays it (Claude Desktop: Settings > Extensions). That is independent of what is in your working tree — installing an MCPB installs whatever is inside the .mcpb file, which is only as current as the last npm run bundle:mcpb. Build the bundle immediately before installing it, or install from a GitHub release.

Five consecutive failed authentications for a username trigger an exponential backoff, capped at 15 minutes; the message states the remaining wait. The counter lives in process memory, so restarting the client clears it.

Trust and Security

Cozi has no OAuth — username/password authentication is the only way the API supports. This server handles that fact honestly:

Per-user, by architecture. Each user runs their own instance against their own Cozi account. There is no shared backend, no proxy, no multi-tenant database. The author of this server never sees anyone's credentials or data.
Credentials live only in your MCP client's secure config. Claude Desktop stores them in your OS keychain. Smithery encrypts them per-session. The npx path reads them from environment variables you set yourself. Nothing is logged, written to disk by this server, or sent anywhere except https://rest.cozi.com.
API surface is constrained. This server only contacts rest.cozi.com for the same endpoints the Cozi web app uses (auth, lists, calendar, family members). The full request/response code lives in src/cozi/ — about 500 lines of TypeScript you can audit yourself.
Open source, MIT licensed. Pin a specific version (@mjucius/cozi-mcp@2.0.0) if you want a stable target, or fork the repo and run your own build if you want zero supply-chain trust.

Security & trust model

This is a single-user server by design. The Cozi credential holder is the principal — there is no separate per-caller authentication gate, because each user runs their own instance against their own Cozi account. Concretely:

stdio (npx / MCPB) trusts the local user. Whoever can launch the process and read the configured COZI_USERNAME / COZI_PASSWORD (or the OS keychain entry) is treated as the account owner. The trust boundary is your machine and its user account.
The Smithery HTTP deployment trusts the session-config credentials as the principal. Whoever supplies valid Cozi credentials in the session config is the authenticated user for that session. There is no additional login layer.
No multi-tenancy. Each user configures their own instance with their own Cozi account. There is no shared backend, no tenant isolation to breach, and no per-caller authentication beyond possession of valid Cozi credentials — which is the same access model as the Cozi web app itself.

Two defensive measures narrow the blast radius of that model:

Time-bounded credential cache. Authenticated clients are cached only for a bounded lifetime, so a rotated or revoked Cozi password stops working rather than being honored indefinitely from a stale cached session.
Failed-login rate limiting. Repeated failed authentication attempts are rate-limited to blunt credential-guessing against the Cozi endpoint.

Tools

The server exposes 12 tools by default, or 4 read-only tools when COZI_READ_ONLY=true (or Smithery/MCPB read-only config) is enabled. Returns are slim dicts with null/empty fields omitted.

Family

family_members() → [{id, name, color?}] — call this first to get attendee IDs for appointments.

Lists

get_lists(list_type?) → [{id, title, type, item_count, completed_count}] — list_type is optional, 'shopping' or 'todo'.
get_list_items(list_id, include_completed=false) → [{id, text, status, position?}].
create_list(name, list_type) → {id, title, type}.
delete_list(list_id) → boolean.

create_list and delete_list are hidden in read-only mode.

Items

add_item(list_id, text, position=0) → {id, text}.
update_item(list_id, item_id, text?, completed?) → {id, text, status} — pass either or both. Non-atomic when both are passed: the text is updated first, then the status.
remove_items(list_id, item_ids) → boolean.

All item tools are hidden in read-only mode.

Calendar

get_calendar(year, month) → [{id, subject, day, all_day, start?, end?, attendees?, location?, notes?}].
create_appointment(subject, start, end, attendees?, all_day=false, notes='', location?) — start and end are ISO datetimes (e.g. '2026-06-15T10:00:00'). For all-day events end may equal start.
update_appointment(appointment_id, year, month, ...) — partial update via fetch-then-merge: pass (appointment_id, year, month) plus any fields to change. Omitted fields are preserved. To switch a timed appointment to all-day pass all_day=true; to switch to timed pass new start/end.
delete_appointment(appointment_id, year, month) → boolean.

create_appointment, update_appointment, and delete_appointment are hidden in read-only mode.

Workflow tip

When creating or updating appointments with specific attendees, call family_members() first and use those id values in the attendees arg. Calendar tools are scoped to a (year, month) page — pass the same year/month back when updating or deleting an appointment from that page.

Migration from v1 (Python)

v2.0 is a Node/TypeScript rewrite of the previous Python implementation, distributed as MCPB / npx / Smithery. The runtime changed AND the tool surface was consolidated — if you have prompts written against v1, update them as follows:

v1 (Python, 14 tools)	v2 (Node, 12 tools)
`get_family_members`	`family_members`
`get_lists_by_type(t)`	`get_lists(list_type=t)`
`update_item_text(...)` + `mark_item(...)`	`update_item(text?, completed?)` (merged)
`add_item(list_id, item_text, ...)`	`add_item(list_id, text, ...)` (param renamed)
`update_appointment(appointment_obj)`	`update_appointment(appointment_id, year, month, ...partial)`
`update_list` (item reordering)	removed
`delete_appointment(id)`	`delete_appointment(id, year, month)`
`get_lists` returned nested items	now summary only — fetch items via `get_list_items(list_id)`

The legacy v1 Python source is preserved at git tag v1.0.0 for reference.

Development

Requires Node 20+ (see .nvmrc).

nvm use
npm install
npm test               # vitest, 68 tests
npm run typecheck
npm run build          # tsup → dist/
npm run dev            # local stdio dev with COZI_USERNAME / COZI_PASSWORD env vars
npm run playground     # @smithery/cli local playground UI
npm run bundle:mcpb    # produces cozi-mcp.mcpb at repo root

The repo layout:

cozi_mcp/
├── src/
│   ├── server.ts              # MCP server factory (Smithery default export)
│   ├── bin.ts                 # npx + MCPB stdio entry point
│   ├── instructions.ts
│   ├── cozi/                  # Inlined Cozi HTTP client (no separate npm package)
│   └── tools/                 # 12 MCP tools
├── tests/                     # vitest, mocks CoziClient at the boundary
├── manifest.json              # MCPB manifest (Claude Desktop)
├── smithery.yaml              # Smithery deploy manifest
└── package.json

The Cozi HTTP client is inlined under src/cozi/ rather than published as a separate npm package — it's small, only useful for this MCP server, and avoids the supply-chain surface area of a separate dependency. If you'd prefer the Python equivalent for your own projects, see py-cozi-client.

Acknowledgments

The ?apikey=coziwc|v…_production requirement on the Cozi auth endpoint was reverse-engineered from the live my.cozi.com web bundle by Wetzel402/py-cozi PR #3. Without that discovery, every login attempt from a server environment fails with a misleading 401 regardless of credential validity.
Built on the Model Context Protocol and its TypeScript SDK by Anthropic.

Trademark and affiliation

Cozi and the Cozi logo are trademarks of Cozi Group Inc. This project is unofficial and not affiliated with, endorsed by, or sponsored by Cozi Group Inc. Use of the Cozi API is at your own risk and subject to Cozi's Terms of Service.

License

MIT — see LICENSE.

Contributing

PRs welcome. Please run npm test and npm run typecheck before submitting.

Available Tools

12 tools

add_itemAdd an item to a listBInspect

Add an item to a list. Returns: {id, text}.

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes
`text`	Yes
`position`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It states that the tool adds an item (implying mutation) and returns {id, text}. However, it does not disclose side effects, permissions required, rate limits, or error scenarios. The return shape is helpful but incomplete.

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

Conciseness5/5

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

The description is two short sentences with no extraneous information. It is front-loaded with the core purpose and immediately provides the return structure. Every word earns its place, making it highly efficient.

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?

The tool has 3 parameters, one optional, and no output schema. The description at least mentions the return format ({id, text}). However, it omits critical context such as constraints on list_id (must be valid?), behavior when position is out of bounds, and whether the operation is idempotent. Adequate for a simple tool but leaves gaps.

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 compensate for parameter meaning. It does not explain list_id, text, or the optional position parameter. For example, position's impact on insertion order or defaults is omitted. The description adds no semantic value beyond the schema's field names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (add) and the resource (item to a list). It distinguishes from sibling tools like create_list (which creates a list itself) and update_item (which modifies an existing item). The verb+resource combination is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as update_item or remove_items. The description lacks context about prerequisites, such as requiring the list to exist, or when to use optional parameters. An agent has no basis for choosing this tool over others.

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

create_appointmentCreate a calendar appointmentAInspect

Create a calendar appointment. start and end are ISO datetimes (e.g. '2026-06-15T10:00:00'). For all-day events end may equal start. For attendees, call family_members() first and pass those id values.

ParametersJSON Schema

Name	Required	Description	Default
`subject`	Yes
`start`	Yes
`end`	Yes
`attendees`	No
`all_day`	No
`notes`	No
`location`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that start and end are ISO datetimes and that all-day events can have end equal start. However, it does not mention any side effects, required permissions, or error behavior. This is adequate but not thorough.

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

Conciseness4/5

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

The description is two sentences, front-loaded with the purpose. It is efficient and avoids fluff. Could be slightly more structured by grouping explanations, but still clear.

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?

The tool has 7 parameters (3 required), no output schema. The description covers the core usage (subject, start, end, attendees) and all-day behavior, but omits explanation for location, notes, and error/return handling. Complete enough for typical use but not exhaustive.

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

Parameters3/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 compensate. It explains start/end format and the need for family_members IDs for attendees. However, it does not describe subject, all_day, notes, location, or their interplay. Only partial value added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title 'Create a calendar appointment' and description clearly state the verb ('Create') and resource ('calendar appointment'). This directly distinguishes it from sibling tools like delete_appointment, update_appointment, and get_calendar.

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?

The description provides explicit guidance on when to use this tool: it mentions calling family_members() first to get attendee IDs. It also specifies the ISO datetime format for start and end. While it does not explicitly state when not to use it, the context of creation vs deletion/update is clear.

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

create_listCreate a listAInspect

Create a list ('shopping' or 'todo'). Returns: {id, title, type}.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`list_type`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so the description carries the full burden. It discloses the return structure ({id, title, type}), but does not mention side effects, validation, authorization needs, or behavior on duplicate names.

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

Conciseness5/5

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

The description is extremely concise with two front-loaded sentences and zero wasted words. Every part adds value.

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

Completeness4/5

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

Given the tool's simplicity (2 required params, no nested objects, no output schema), the description provides the essential purpose and return format. It is adequate for an AI agent to use correctly, though it could mention that 'name' is a required string.

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

Parameters3/5

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

Schema coverage is 0% (no descriptions in schema). The description adds context for the 'list_type' parameter by specifying allowed values ('shopping' or 'todo'), but the 'name' parameter is not described at all, leaving its purpose and constraints unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'create' and the resource 'list', and specifies the two valid types ('shopping' or 'todo'). This distinguishes it from sibling tools like 'create_appointment' or 'get_lists'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. It does not mention when not to use it or provide context for choosing between this and sibling tools like 'add_item' or 'get_lists'.

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

delete_appointmentDelete an appointmentCInspect

Delete an appointment. Returns true on success.

ParametersJSON Schema

Name	Required	Description	Default
`appointment_id`	Yes
`year`	Yes
`month`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, and the description only adds 'Returns true on success', omitting whether deletion is irreversible, permissions required, or error behavior. Lacks critical behavioral context.

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

Conciseness4/5

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

Two short, direct sentences with no wasted words, though it sacrifices completeness for brevity.

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

Completeness1/5

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

With no annotations, no output schema, and three required parameters, the description is far too minimal to fully guide correct usage, especially given sibling tools.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the three parameters (appointment_id, year, month), leaving the agent to infer meaning from names alone.

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 description clearly states 'Delete an appointment', which is a specific verb+resource combination, distinguishing it from sibling tools like create_appointment and update_appointment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided.

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

delete_listDelete a listCInspect

Delete a list. Returns true on success.

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavior. It only states the action and return value, omitting details like permanence of deletion, required permissions, or error scenarios.

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

Conciseness5/5

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

The description is extremely concise with two sentences, containing no extraneous information. Every word serves a purpose.

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

Completeness2/5

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

Given the tool's simplicity, the description is barely adequate. It lacks parameter documentation and does not mention return format or failure modes, which would be expected for a destructive operation.

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

Parameters1/5

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

The input schema has 0% description coverage and the tool description adds no meaning to the 'list_id' parameter. The agent is left to infer what 'list_id' is and how to obtain it.

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 description clearly states that the tool deletes a list and returns true on success. It distinguishes itself from sibling tools like 'delete_appointment' through the resource name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or alternative tools for similar operations.

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

family_membersList family membersAInspect

List family members. Use the id for appointment attendees. Returns: [{id, name, color?}].

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations exist, so description must disclose behavior. It correctly states it returns a list of family members with fields {id, name, color?}, but does not specify ordering, caching, or potential empty results. Adequate for a read-only list tool.

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

Conciseness5/5

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

Two tightly crafted sentences: first states purpose, second provides usage guidance and return structure. No redundant words.

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

Completeness5/5

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

Fully sufficient for a simple parameterless tool: describes return format and actionable usage (id for attendees). No output schema exists, so the description compensates well.

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

Parameters4/5

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

No parameters in input schema, so schema coverage is 100%. Description adds no parameter info (none needed), baseline 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'List' and resource 'family members' is specific and unambiguous. It distinguishes itself from sibling list tools (e.g., get_calendar, get_lists) by naming a distinct entity.

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?

Explicitly tells the agent to use the returned `id` for appointment attendees, providing a clear use case. Lacks explicit when-not-to-use or alternative comparisons, but sufficient for this simple tool.

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

get_calendarGet appointments for a monthBInspect

Appointments for one month. Returns: [{id, subject, day, all_day, start?, end?, attendees?, location?, notes?}].

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes
`month`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided. The description indicates the return format with optional fields, but lacks details on side effects, permissions, or error handling.

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

Conciseness5/5

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

Two sentences front-load the purpose and output structure with no redundant text.

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

Completeness2/5

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

Given no annotations or output schema, the description omits important context like handling of invalid inputs, pagination, or time zones.

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 coverage is 0%. The description does not explain the year and month parameters beyond the title, missing details like range or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state the tool retrieves appointments for a specific month. It distinguishes from sibling tools like create_appointment and delete_appointment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. The description does not mention exclusions or when not to use it.

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

get_list_itemsGet items in a listBInspect

Items in one list. Excludes completed items by default. Returns: [{id, text, status, position?}].

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes
`include_completed`	No

TDQS

B3.4/5.0

Behavior3/5

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

Discloses default exclusion of completed items and return format. But no annotations present, and description omits other behavioral traits such as read-only nature, pagination, ordering, or error handling.

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

Conciseness5/5

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

Three concise sentences with front-loaded purpose. No extraneous information, every sentence adds value.

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

Completeness4/5

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

Simple tool with only two parameters; description covers default behavior and output structure. Missing potential details on ordering or limits, but sufficient for basic usage.

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

Parameters3/5

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

Schema description coverage is 0%, but description indirectly explains include_completed via 'excludes completed items by default'. Does not elaborate on list_id format or constraints beyond implying it identifies a list.

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?

Description states 'Items in one list' and provides return format, clearly indicating it retrieves items from a specific list. Distinguishes from sibling tools like get_lists (returns lists) and mutation tools like add_item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Implied by context, but no direct mention of exclusions or comparisons to siblings like update_item or remove_items.

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

get_listsSummarize all listsAInspect

Summarize all lists (no items). Optionally filter by 'shopping' or 'todo'. Returns: [{id, title, type, item_count, completed_count}].

ParametersJSON Schema

Name	Required	Description	Default
`list_type`	No

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description clearly indicates it is a read-only summarization that returns specific fields and explicitly states it does not return items, disclosing key behavioral traits.

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

Conciseness5/5

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

Two sentences with no wasted words: main purpose first, then filter, then return format. Highly concise and well-structured.

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

Completeness4/5

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

The description covers return structure and filtering, which is adequate for a simple list summary tool. Minor omissions like case sensitivity or pagination do not significantly detract.

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

Parameters4/5

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

The schema has 0% description coverage, but the description adds meaning by explaining the parameter's purpose and suggesting valid filter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it summarizes all lists without items, and optionally filters by type. It distinguishes from siblings like 'get_list_items' which retrieves items of a specific list.

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?

The description provides filtering options ('shopping' or 'todo') but does not explicitly state when to use this tool versus alternatives like 'get_list_items' for item details.

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

remove_itemsRemove items from a listCInspect

Remove items from a list. Returns true on success.

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes
`item_ids`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist; the description only mentions return value. Does not disclose side effects, permanence, or error states despite being a mutation tool.

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?

Very short (2 sentences) and front-loaded, but under-specified. Conciseness comes at cost of missing crucial details.

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

Completeness2/5

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

Missing output schema and annotations; description lacks details on behavior with non-existent IDs, error handling, or operational context for a required 2-parameter tool.

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 coverage is 0%. Description adds no meaning beyond parameter names; does not explain expected format or constraints for list_id or item_ids.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (remove), resource (items from a list), and return value (true on success). Distinct from siblings like add_item or delete_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like update_item or delete_list. No prerequisites or exclusions provided.

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

update_appointmentPartial-update an appointmentAInspect

Partial-update an appointment. The Cozi PUT semantics replace ALL fields, so this tool first fetches the existing appointment from the (year, month) page and merges your changes — only fields you pass are altered. To switch a timed appointment to all-day pass all_day=true; to switch to timed pass new start/end.

ParametersJSON Schema

Name	Required	Description	Default
`appointment_id`	Yes
`year`	Yes
`month`	Yes
`subject`	No
`start`	No
`end`	No
`attendees`	No
`all_day`	No
`notes`	No
`location`	No

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description fully discloses the PUT semantics and fetch-and-merge behavior, preemptively warning users about Cozi's full replacement approach. It also details how to toggle all-day. It could be improved by mentioning error conditions or authorization needs, but the core behavior is transparent.

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

Conciseness5/5

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

The description is extremely concise—two sentences that are front-loaded with the purpose. Every sentence adds value; there is no fluff or repetition.

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?

Given the complexity (10 parameters, no output schema, no annotations), the description does not fully cover all necessary context. It explains the merge behavior and all-day toggle but omits details on error handling, prerequisites (like how to obtain appointment_id), and the response format. It is adequate for a simple use case but lacks completeness for a robust tool.

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 compensate. It only explains the 'all_day' parameter and related 'start'/'end', but provides no guidance on other optional parameters like 'subject', 'attendees', 'notes', 'location'. The required parameters are implicitly explained (fetch from year/month page), but many parameters remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a partial update on an appointment, distinguishing it from create_appointment and delete_appointment by explaining its unique merge behavior. The verb 'Partial-update' and resource 'appointment' are specific.

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?

The description explains when to use this tool (to update an appointment) and provides guidance on switching between timed and all-day appointments. However, it does not explicitly state when not to use it or contrast it with alternatives like create_appointment for new items.

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

update_itemUpdate an item's text and/or completionAInspect

Update an item's text and/or completion status. Pass text, completed, or both. When both are provided the text is updated first then status is updated as a separate request — these are NOT atomic. Returns: {id, text, status}.

ParametersJSON Schema

Name	Required	Description	Default
`list_id`	Yes
`item_id`	Yes
`text`	No
`completed`	No

TDQS

A4.2/5.0

Behavior4/5

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

Discloses non-atomic behavior (separate requests) and return format ({id, text, status}). With no annotations, it carries the full burden, and covers the critical behavioral aspect of update ordering and atomicity.

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

Conciseness5/5

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

Two sentences, no wasted words, front-loaded with purpose. Every sentence adds value.

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

Completeness4/5

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

Provides return shape and non-atomicity warning despite no output schema. Could mention prerequisites (item must exist) or error handling, but overall covers the essential context for a simple update tool.

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

Parameters3/5

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

Schema has 0% description coverage, so the description compensates by explaining that text and completed are optional (pass one or both). However, it does not explain the required parameters list_id and item_id beyond their existence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it updates an item's text and/or completion status, specifying the resource (item) and action (update). It distinguishes from sibling tools like add_item and remove_items.

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?

Provides explicit guidance on which parameters to pass ('text, completed, or both') and warns about non-atomicity when both are provided. Lacks explicit when-not-to-use or alternatives, but covers key usage conditions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: appointments, lists, items, and family members are clearly separated. No overlapping purposes.

Naming Consistency5/5

All tools follow a verb_noun pattern in snake_case, e.g., create_appointment, get_list_items, update_item. The only slight deviation is family_members, but it is still clear.

Tool Count5/5

12 tools cover the core functionality of a family management server (calendars, lists, items) without being excessive or too sparse.

Completeness4/5

CRUD operations are present for appointments and list items. Missing update list title and individual appointment retrieval (only monthly batch), but core workflows are well-supported.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Scraps Kitchen
io.github.mitchmolstad
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Home Automation & IoT Health & Wellness App Automation
2
Superlist
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2
Kalender Sync A
de.kalender-sync
GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Calendar Management Workplace & Productivity
71
CalmLoop Task Manager
in.calmloop
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Project Management Note Taking
1

Related MCP Servers

Cozi MCP Server
App Automation Workplace & Productivity Note Taking
BrandCast-Signage
-
license
A
quality
Not graded
maintenance
Enables management of Cozi Family Organizer shopping lists and todo lists through natural language. Supports creating, editing, and organizing family lists with real-time sync to the Cozi platform.
Updated a year ago (2025-10-09 17:27 UTC)
9
AnyList MCP Server
davidashman
F
license
A
quality
D
maintenance
Enables AI assistants to interact with AnyList for managing shopping lists, recipes, and meal planning. Users can retrieve recipe details, add ingredients to lists, and schedule meals on their AnyList calendar.
Updated 6 months ago (2026-03-08 14:45 UTC)
10
Google Calendar MCP
Calendar Management Workplace & Productivity
paytience
A
license
Not graded
quality
C
maintenance
Enables AI assistants to view, create, update, search, and manage Google Calendar events, including multi-account support and availability checks.
Updated 2 months ago (2026-07-14 10:23 UTC)
15
Business Source 1.1
Calendar MCP Server
Calendar Management Workplace & Productivity
franciscpd
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Google Calendar events, including reading, searching, creating, updating, and deleting events, as well as checking availability and listing calendars.
Updated 5 months ago (2026-03-20 16:20 UTC)
25
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mjucius/cozi_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Cozi MCP Server

Install

1. MCPB (recommended for Claude Desktop)

2. Smithery (for other MCP clients)

3. npx (for power users)

Troubleshooting

Tools fail with "Authentication failed" even after I corrected my password

How do I tell which version is actually running?

Repeated failures start returning "Too many failed login attempts"

Trust and Security

Security & trust model

Tools

Family

Lists

Items

Calendar

Workflow tip

Migration from v1 (Python)

Development

Acknowledgments

Trademark and affiliation

License

Contributing

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API