Skip to main content
Glama
bcharleson

Instantly MCP Server

update_account

Modify email account settings for email outreach campaigns, including display names, warmup configurations, daily sending limits, and tracking domains.

Instructions

Update account settings (partial update).

Common updates:

  • first_name, last_name: Display name

  • warmup: Warmup configuration (limit, advanced settings)

  • daily_limit: Max emails per day (1-100)

  • sending_gap: Minutes between emails (0-1440)

  • tracking_domain_name: Custom tracking domain

Only include fields you want to update.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Core handler function implementing the update_account tool logic. Constructs a partial update body from input parameters and sends a PATCH request to the accounts API endpoint.
    async def update_account(params: UpdateAccountInput) -> str:
        """
        Update account settings (partial update).
        
        Common updates:
        - first_name, last_name: Display name
        - warmup: Warmup configuration (limit, advanced settings)
        - daily_limit: Max emails per day (1-100)
        - sending_gap: Minutes between emails (0-1440)
        - tracking_domain_name: Custom tracking domain
        
        Only include fields you want to update.
        """
        client = get_client()
        email_encoded = quote(params.email, safe="")
        
        body = {}
        if params.first_name is not None:
            body["first_name"] = params.first_name
        if params.last_name is not None:
            body["last_name"] = params.last_name
        if params.warmup is not None:
            warmup_dict = params.warmup.model_dump(exclude_none=True)
            if warmup_dict:
                body["warmup"] = warmup_dict
        if params.daily_limit is not None:
            body["daily_limit"] = params.daily_limit
        if params.sending_gap is not None:
            body["sending_gap"] = params.sending_gap
        if params.enable_slow_ramp is not None:
            body["enable_slow_ramp"] = params.enable_slow_ramp
        if params.tracking_domain_name is not None:
            body["tracking_domain_name"] = params.tracking_domain_name
        if params.tracking_domain_status is not None:
            body["tracking_domain_status"] = params.tracking_domain_status
        if params.skip_cname_check is not None:
            body["skip_cname_check"] = params.skip_cname_check
        if params.remove_tracking_domain is not None:
            body["remove_tracking_domain"] = params.remove_tracking_domain
        if params.inbox_placement_test_limit is not None:
            body["inbox_placement_test_limit"] = params.inbox_placement_test_limit
        
        result = await client.patch(f"/accounts/{email_encoded}", json=body)
        return json.dumps(result, indent=2)
  • Pydantic BaseModel defining the input schema and validation for the update_account tool parameters.
    class UpdateAccountInput(BaseModel):
        """Input for updating account settings (partial update)."""
        
        model_config = ConfigDict(str_strip_whitespace=True, extra="ignore")
        
        email: str = Field(..., description="Account to update")
        first_name: Optional[str] = Field(default=None)
        last_name: Optional[str] = Field(default=None)
        warmup: Optional[WarmupSettings] = Field(default=None, description="Warmup configuration")
        daily_limit: Optional[int] = Field(default=None, ge=1, le=100, description="Daily send limit")
        sending_gap: Optional[int] = Field(
            default=None, ge=0, le=1440,
            description="Minutes between emails (0-1440)"
        )
        enable_slow_ramp: Optional[bool] = Field(default=None)
        tracking_domain_name: Optional[str] = Field(default=None)
        tracking_domain_status: Optional[str] = Field(default=None)
        skip_cname_check: Optional[bool] = Field(default=None)
        remove_tracking_domain: Optional[bool] = Field(default=None)
        inbox_placement_test_limit: Optional[int] = Field(default=None)
  • Registration of the update_account tool as part of the ACCOUNT_TOOLS list, which is used by the server to dynamically register all account-related tools.
    ACCOUNT_TOOLS = [
        list_accounts,
        get_account,
        create_account,
        update_account,
        manage_account_state,
        delete_account,
    ]
  • MCP annotations for update_account tool registration, specifying destructiveHint: False, applied during server tool registration.
    # Account tools
    "list_accounts": {"readOnlyHint": True},
    "get_account": {"readOnlyHint": True},
    "create_account": {"destructiveHint": False},
    "update_account": {"destructiveHint": False},
    "manage_account_state": {"destructiveHint": False},
    "delete_account": {"destructiveHint": True, "confirmationRequiredHint": True},
Behavior3/5

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

The annotations provide 'destructiveHint: false,' indicating non-destructive behavior, which the description doesn't contradict. The description adds useful context about partial updates and common use cases, but doesn't disclose other behavioral traits like authentication needs, rate limits, or what happens to unspecified fields. With annotations covering the safety profile, this is adequate but not rich in additional behavioral details.

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 well-structured and appropriately sized, with a clear purpose statement followed by a bulleted list of common updates and a closing instruction. Every sentence adds value, and it's front-loaded with the core functionality. It could be slightly more concise by integrating the instruction into the opening sentence.

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 complexity (multiple parameters, nested objects) and the presence of an output schema (which reduces the need to explain return values), the description is reasonably complete. It covers key parameters and the partial update nature, but doesn't address all schema parameters or potential side effects. With annotations providing destructiveHint and an output schema existing, it's sufficient but not exhaustive.

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 description coverage is 0%, so the description carries the full burden. It adds significant value by explaining the semantics of common parameters (e.g., 'first_name, last_name: Display name,' 'daily_limit: Max emails per day (1-100)'), which clarifies their purpose beyond the schema's basic types. However, it doesn't cover all parameters listed in the schema, such as 'enable_slow_ramp' or 'remove_tracking_domain.'

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 the tool's purpose: 'Update account settings (partial update).' It specifies the verb ('update'), resource ('account settings'), and scope ('partial update'), which distinguishes it from other update operations. However, it doesn't explicitly differentiate from sibling tools like 'manage_account_state' or 'create_account'.

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

Usage Guidelines3/5

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

The description provides implied usage guidance through the 'Common updates' list and the instruction 'Only include fields you want to update,' which suggests this is for partial updates. However, it doesn't explicitly state when to use this tool versus alternatives like 'manage_account_state' or 'create_account,' nor does it mention prerequisites or exclusions.

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