Skip to main content
Glama
sieve-mcp-server

sieve-mcp-server

Official

sieve_deactivate_scripts

Deactivate the active Sieve script to stop all mail filtering for an account while keeping scripts stored. Use when filtering must be switched off entirely.

Instructions

Deactivate the active script, so no Sieve filtering is applied to incoming mail at all. Scripts stay stored. Only when the user explicitly wants filtering switched off.

Input Schema

NameRequiredDescriptionDefault
accountIdNoAccount id, as an alternative to accountName.
accountNameNoAccount name (from sieve_list_accounts). Optional when only one account is configured.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden well by stating that the active script is deactivated, all filtering stops, and scripts remain stored rather than deleted. It omits details such as idempotency or behavior when no active script exists, but the key side effect and data-retention behavior are disclosed.

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 concise sentences with the effect front-loaded and no wasted language. The caveat about explicit user intent follows immediately and earns its place.

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?

For a simple two-optional-parameter tool with no output schema and no annotations, the description provides enough context to select and invoke it correctly: what it does, what happens to stored scripts, and when to use it. The account selection details are already handled by the fully described schema.

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 100%, so both accountId and accountName are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, which is the baseline when schema coverage is complete.

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 uses a specific verb ("Deactivate") and resource ("active script") and states the concrete effect: no Sieve filtering is applied to incoming mail. This clearly distinguishes the tool from its sibling sieve_activate_script and other script-management tools.

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?

It gives an explicit usage condition: "Only when the user explicitly wants filtering switched off." That is clear guidance on when to use it, though it does not name the alternative tool (sieve_activate_script) for re-enabling filtering.

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