Skip to main content
Glama
bcharleson

Instantly MCP Server

manage_account_state

Control email account operations: pause sending, resume activity, manage warmup processes, or test connection vitals to diagnose issues.

Instructions

Manage account state: pause, resume, enable/disable warmup, or test vitals.

Actions:

  • pause: Stop all sending from this account

  • resume: Re-enable sending

  • enable_warmup: Start warmup process

  • disable_warmup: Stop warmup process

  • test_vitals: Test IMAP/SMTP connectivity

Use test_vitals to diagnose connection issues.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core handler function implementing the manage_account_state tool. It handles different actions (pause, resume, enable/disable warmup, test vitals) by making appropriate API calls to the Instantly.ai V2 API.
    async def manage_account_state(params: ManageAccountStateInput) -> str:
        """
        Manage account state: pause, resume, enable/disable warmup, or test vitals.
        
        Actions:
        - pause: Stop all sending from this account
        - resume: Re-enable sending
        - enable_warmup: Start warmup process
        - disable_warmup: Stop warmup process
        - test_vitals: Test IMAP/SMTP connectivity
        
        Use test_vitals to diagnose connection issues.
        """
        client = get_client()
        email_encoded = quote(params.email, safe="")
        
        action_endpoints = {
            "pause": f"/accounts/{email_encoded}/pause",
            "resume": f"/accounts/{email_encoded}/resume",
            "enable_warmup": "/accounts/warmup/enable",
            "disable_warmup": "/accounts/warmup/disable",
            "test_vitals": "/accounts/test/vitals",
        }
        
        endpoint = action_endpoints[params.action]
        
        # Different actions have different body requirements
        if params.action in ["pause", "resume"]:
            result = await client.post(endpoint)
        elif params.action in ["enable_warmup", "disable_warmup"]:
            # V2 API expects an array of emails for warmup enable/disable
            result = await client.post(endpoint, json={"emails": [params.email]})
        else:  # test_vitals
            # V2 API expects an array of emails for test vitals
            result = await client.post(endpoint, json={"emails": [params.email]})
        
        return json.dumps(result, indent=2)
  • Pydantic BaseModel defining the input schema for the manage_account_state tool, including required 'email' and 'action' fields.
    class ManageAccountStateInput(BaseModel):
        """Input for managing account state (pause, resume, warmup control, vitals test)."""
        
        model_config = ConfigDict(str_strip_whitespace=True, extra="ignore")
        
        email: str = Field(..., description="Account email")
        action: Literal["pause", "resume", "enable_warmup", "disable_warmup", "test_vitals"] = Field(
            ..., description="Action to perform"
        )
  • MCP tool annotation in the TOOL_ANNOTATIONS dictionary specifying that manage_account_state is non-destructive, used during dynamic registration of all tools.
    "manage_account_state": {"destructiveHint": False},
  • The ACCOUNT_TOOLS list exports the manage_account_state function for inclusion in get_all_tools(), enabling its registration in the MCP server.
    ACCOUNT_TOOLS = [
        list_accounts,
        get_account,
        create_account,
        update_account,
        manage_account_state,
        delete_account,
    ]
Behavior4/5

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

Annotations provide destructiveHint=false, indicating non-destructive operations. The description adds valuable context beyond this: it explains what each action does (e.g., 'Stop all sending from this account' for pause, 'Test IMAP/SMTP connectivity' for test_vitals). This clarifies behavioral outcomes without contradicting annotations. However, it doesn't mention rate limits, authentication needs, or error conditions.

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 well-structured and front-loaded with the core purpose, followed by a bulleted list of actions and a specific usage note. Every sentence earns its place: the first sentence summarizes, the list details actions, and the last sentence provides targeted guidance. No wasted words or redundancy.

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 moderate complexity (state management with multiple actions), annotations cover safety (non-destructive), and an output schema exists (so return values needn't be described). The description adds good context about actions but could better address the email parameter and potential side effects. It's mostly complete but has minor gaps in parameter explanation.

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?

Schema description coverage is 0%, so the description must compensate. It effectively explains the semantics of the action parameter by listing and describing each enum value (pause, resume, etc.). However, it doesn't clarify the email parameter's role or format. Since there's only 1 parameter (a nested object with 2 sub-parameters), the description covers the more complex part well but leaves the email parameter unexplained.

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's purpose with specific verbs (pause, resume, enable/disable warmup, test vitals) and the resource (account state). It distinguishes itself from siblings like pause_campaign (which targets campaigns) and update_account (which likely modifies settings rather than state transitions). The action list provides concrete examples of what 'manage' means.

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 clear context for when to use test_vitals ('to diagnose connection issues'), which helps guide selection. However, it doesn't explicitly state when to choose this tool over alternatives like update_account or pause_campaign, nor does it mention prerequisites or exclusions for other actions. The guidance is helpful but incomplete regarding sibling differentiation.

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

Install Server

Other Tools

Latest Blog Posts

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/bcharleson/instantly-mcp-python'

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