Local MCP

Disconnect Todoist

disconnect_todoist

Destructive

Disconnects Todoist: removes the API token stored on this computer. Reconnecting requires the user to enter a new API token in LMCP's icon → My apps → Connect, in Todoist's row (with no row: LMCP's icon → My apps → Add apps…).

Input Schema

Name	Required	Description	Default
`account`	No	Optional: Todoist has one account.
`confirm`	No	Ignored; kept for older clients.

Output Schema

Name	Required	Description
`effect`	No	removes_credential: the stored sign-in is removed. turns_off: the account stops being read in Local MCP and stays signed in to its app.
`status`	Yes	disconnected or not_connected.
`account`	No
`message`	Yes
`account_id`	No
`remaining_accounts`	No	Other accounts of this service that stay connected.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedOutput schema / properties / status / description

Previous value: -"preview, disconnected or not_connected."New value: +"disconnected or not_connected."

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / confirm / description

Previous value: -"Must be true to disconnect. Without it the call returns a preview and changes nothing."New value: +"Ignored; kept for older clients."

Changed10 schema fields changedOct 22, 2026

addedInput schema / properties / account

Added value: +{
+  "description": "Optional: Todoist has one account.",
+  "type": "string"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "Must be true to disconnect. Without it the call returns a preview and changes nothing.",
+  "type": "boolean"
+}

addedOutput schema / additionalProperties
```
Added value: +true
```
addedOutput schema / properties / account
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / account_id
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / effect

Added value: +{
+  "description": "removes_credential: the stored sign-in is removed. turns_off: the account stops being read in Local MCP and stays signed in to its app.",
+  "type": "string"
+}

removedOutput schema / properties / ok

Removed value: -{
-  "type": "boolean"
-}

addedOutput schema / properties / remaining_accounts

Added value: +{
+  "description": "Other accounts of this service that stay connected.",
+  "type": "integer"
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "preview, disconnected or not_connected.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "ok",
-  "message"
-]New value: +[
+  "status",
+  "message"
+]

AddedAug 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description adds real value by specifying the blast radius (only the token on this computer) and confirming reconnection needs a fresh token. It does not explicitly say whether remote Todoist data or tasks are untouched, which is the one lingering ambiguity for a destructive tool.

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?

Front-loaded with the core action and effect in the first clause; the reconnect instructions are useful but the nested parenthetical UI path is slightly dense. No wasted framing.

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?

An output schema exists so return values need no explanation, and the description covers effect, reversibility, and recovery. Complete enough to call correctly, missing only an explicit note that Todoist tasks/data are unaffected.

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 100% - the schema already documents 'account' as optional (Todoist has one account) and 'confirm' as ignored. The description adds no parameter-level information, so the baseline 3 applies.

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?

States a specific verb (Disconnects) and resource (Todoist) plus the actual effect: removing the locally stored API token. That effect statement cleanly separates it from connect_todoist and from the many other disconnect_* siblings.

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?

Implies the appropriate moment to call it (user wants to unlink Todoist) and goes further by spelling out the recovery path via LMCP's icon → My apps → Connect. No explicit 'do not use when...' or pointer to a sibling alternative, so it stops short of a 5.

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

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.