Skip to main content
Glama
Sign In
slidecold-mcp

slidecold-mcp

by slidecold
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add an Instagram account

create_account

Adds an Instagram account and queues a login job; include a proxy and optional 2FA secret to complete authenticated setup.

Instructions

Add an Instagram account. Required API key scope: accounts:write. POST /accounts Queues a login job. A proxy (proxyId or inline proxy) is required in production. The login may need 2FA or a challenge (see verifyAccount2fa / verifyAccountChallenge). Body validation uses a throwing parse, so a malformed body yields a 500 rather than a 400.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "body": "<body>"
    },
    "name": "create_account"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesJSON request body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses that this is an asynchronous job ('Queues a login job'), that a proxy is required in production, that login may stall on 2FA/challenge, and that malformed bodies return 500 instead of 400. That is exactly the non-obvious behavior an agent needs and cannot get from structured fields.

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 action, then scope and path, followed by behavioral caveats; each sentence carries real information. The 'POST /accounts' line is slightly redundant with the name but is the only low-value element.

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?

For a mutation with a nested body object and no output schema, the description covers async behavior, proxy requirements, the 2FA branch, and error semantics. It omits what the call returns (account identifier or job handle) and does not point at get_login_status / check_account_session for polling, which is the one missing piece for an async job tool.

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 100%, so the baseline is 3, but the description adds meaning the schema cannot express: the proxy is mandatory in production and may be supplied either as proxyId or as an inline proxy object. It does not explain totpSecret or displayName usage, so it is good rather than complete.

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 opens with a specific verb+resource ('Add an Instagram account') and adds the concrete effect ('Queues a login job'), which clearly separates it from list_accounts, update_account, and delete_account. It stops short of explicitly naming which sibling handles re-login or account retrieval, so it is clear but not maximally differentiated.

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 states real prerequisites (accounts:write scope, proxy required in production via proxyId or inline proxy) and routes the agent to verifyAccount2fa / verifyAccountChallenge when 2FA or a challenge occurs. It does not contrast with relogin_account or discuss when NOT to create a new account versus reusing one, leaving a small gap.

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

Deploy Server

Other Tools