Summer

This connector has been deprecated

This was a duplicate manual listing. Use Summer’s official listing, imported from the official MCP Registry. Summer’s MCP server remains active at https://api.gosummer.ai/mcp. Setup and documentation: https://gosummer.ai/docs/mcp-clients.

Add a texting line

summer_messenger_sms_create

Add a texting line. Received texts on it can join Summer conversations. The line starts off; nothing is sent. Fast replies follow the texting channel's autonomy setting.

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": {
      "company": "<company>",
      "environment": "<environment>",
      "quo_phone_number_id": "<quo_phone_number_id>",
      "persona_name": "<persona_name>"
    },
    "name": "summer_messenger_sms_create"
  }
}

Input Schema

Name	Required	Description
`company`	Yes	Summer company ID
`environment`	Yes	Environment that owns the resource
`persona_mode`	No	human: a person on the team (default). ai: a visible AI assistant.
`persona_name`	Yes	The name the assistant texts as, such as Alex.
`reply_end_hour`	No	Hour the assistant stops texting, in the customer's local time. Default 21 (9pm).
`idempotency_key`	No	Reuse the same key when retrying the same change
`installation_id`	No	Messenger installation whose assistant instructions and knowledge the line uses. Defaults to the first installation.
`escalation_style`	No	check_back (default): 'Let me check and get back to you.' manager: may say it is checking with a manager.
`reply_start_hour`	No	First hour the assistant may text, in the customer's local time. Default 8 (8am).
`quo_phone_number_id`	Yes	The Quo line ID, from available_lines in messenger.sms.read.
`ingest_phone_number_ids`	No	Other Quo lines, from available_lines, whose received texts join this line's conversations. Replies always go out from this line. Replaces the whole list; [] stops taking texts from other lines.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

changedInput schema / properties / reply_end_hour / description

Previous value: -"Hour the assistant stops texting, in the customer's local time. Default 23."New value: +"Hour the assistant stops texting, in the customer's local time. Default 21 (9pm)."

changedInput schema / properties / reply_start_hour / description

Previous value: -"First hour the assistant may text, in the customer's local time. Default 5."New value: +"First hour the assistant may text, in the customer's local time. Default 8 (8am)."

Changed2 schema fields changedOct 25, 2026

changedInput schema / properties / escalation_style / description

Previous value: -"check_back (default): 'Let me check on that for you.' manager: may say it is asking a manager."New value: +"check_back (default): 'Let me check and get back to you.' manager: may say it is checking with a manager."

addedInput schema / properties / ingest_phone_number_ids

Added value: +{
+  "description": "Other Quo lines, from available_lines, whose received texts join this line's conversations. Replies always go out from this line. Replaces the whole list; [] stops taking texts from other lines.",
+  "items": {
+    "pattern": "^PN[A-Za-z0-9]{1,60}$",
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

AddedOct 24, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Goes beyond annotations with non-obvious behavior: the new line "starts off; nothing is sent," inbound texts can join existing Summer conversations, and outbound replies are governed by the channel's autonomy setting. It stops short of covering permissions, whether the underlying Quo number must already be provisioned, or how the line is later activated.

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?

Four short sentences, front-loaded with the action and its immediate side-effect clarification. No filler, though the closing sentence about "Fast replies" is slightly cryptic in isolation.

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?

For an open-world creation call with 11 parameters and no output schema, the description omits what is returned (e.g., a line ID for later update/read calls) and any permission or eligibility prerequisites. The rich schema fills most of the gap, but the post-call path is not described.

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% across all 11 parameters, so the schema already carries the semantics and the baseline applies. The description names no parameter and adds no constraints the schema lacks, so it neither compensates nor detracts.

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?

Opens with a specific verb and resource: "Add a texting line," which an agent can map to the SMS channel domain given the sibling summer_messenger_sms_read/update. It does not explicitly distinguish itself from summer_messenger_sms_update or summer_messenger_installations_create, so the operation's boundaries are inferred rather than stated.

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

Usage Guidelines2/5

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

No statement of when to use this versus summer_messenger_sms_update, summer_messenger_installations_create, or summer_messenger_voice_read. The only routing hint ("available_lines in messenger.sms.read") lives in the schema, not the description, and no prerequisites or exclusions are given.

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

All Summer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?