starlink-enterprise-mcp

post_managed_customers

Create a managed customer account. Required fields: first name, last name, email, phone, locale. Optional: business name for enterprise customers.

Instructions

Create a managed customer account — This endpoint is only callable with an authorized provider account. — [POST /public/v2/managed/customers]

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": {
      "firstName": "<firstName>",
      "lastName": "<lastName>",
      "email": "<email>",
      "phone": "<phone>",
      "locale": "<locale>"
    },
    "name": "post_managed_customers"
  }
}

Input Schema

Name	Required	Description
`firstName`	Yes	First name.
`lastName`	Yes	Last name.
`email`	Yes	Email address.
`phone`	Yes	Phone number.
`locale`	Yes	ISO 639-1 language code.
`businessName`	No	Business name only required for enterprise customers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Jun 13, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations are minimal (readOnlyHint false, destructiveHint false), so the description carries the burden of behavioral disclosure. It correctly identifies the function as creating a managed customer account and adds an authorization requirement, but lacks details on what exactly happens upon creation, side effects, or response format. The absence of an output schema further limits transparency.

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 brief (three short clauses separated by dashes) and front-loads the core action. It includes the endpoint with no fluff. However, the dash-separated structure is slightly unpolished but still clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (6 params, no output schema), the description covers the basics: creation purpose and authorization. However, it does not explain what happens after creation (e.g., return value, error cases, or required follow-up actions). This is a gap, especially since no output schema exists.

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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add new semantic information beyond the schema; it only echoes the business name requirement already documented. Thus, no additional value is provided.

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 explicitly states 'Create a managed customer account,' which is a specific verb-object pair. It clearly distinguishes from sibling tools (e.g., post_contacts, post_addresses) by focusing on 'managed customer.' The endpoint URL is also provided, reinforcing the purpose.

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 mentions that the endpoint is only callable with an authorized provider account, which gives a prerequisite for use. However, it does not provide guidance on when to use this tool versus alternatives (e.g., post_user_terminals, post_service_lines). No explicit when-to-use or when-not-to-use instructions are given.

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

Deploy Server