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.

Change a texting line with the expected version: persona name, handoff wording, reply hours, other Quo lines it takes texts in from and whether texts join conversations

summer_messenger_sms_update

Change a texting line with the expected version: persona name, handoff wording, reply hours, other Quo lines it takes texts in from and whether texts join conversations. Turn fast replies on or off in messenger.autonomy.update.

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>",
      "line": "<line>",
      "version": "<version>"
    },
    "name": "summer_messenger_sms_update"
  }
}

Input Schema

Name	Required	Description
`line`	Yes
`company`	Yes	Summer company ID
`enabled`	No	Received texts join Summer conversations.
`version`	Yes
`environment`	Yes	Environment that owns the resource
`persona_mode`	No
`persona_name`	No
`reply_end_hour`	No
`idempotency_key`	No	Reuse the same key when retrying the same change
`escalation_style`	No
`reply_start_hour`	No
`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.

Changed1 schema field changedOct 25, 2026

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"
+}

Changed1 schema field changedOct 24, 2026

removedInput schema / properties / assistant_enabled

Removed value: -{
-  "description": "The assistant answers texts inside the reply hours.",
-  "type": "boolean"
-}

AddedOct 24, 2026

TDQS

B3.1/5.0

Behavior2/5

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

Annotations declare non-read-only, open-world, non-idempotent, non-destructive, which is the baseline safety profile this description does nothing to enrich. It never explains what happens to fields that are omitted (patch vs. full replace), what a stale 'version' does (rejection? overwrite?), or whether changes are reversible — all critical for a mutation tool with 12 parameters.

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?

Two sentences with the action and its configurable fields front-loaded, and no filler. The main weakness is redundancy: the first sentence duplicates the title verbatim, so the marginal information is only the cross-reference at the end.

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

Completeness2/5

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

For a 12-parameter mutation with optimistic-concurrency semantics, no output schema, and no annotations covering side effects, the description leaves too much out: version-conflict behavior, replace-vs-merge semantics for ingest_phone_number_ids, and reply-hour conventions are all absent. An agent could construct the call from the schema but could easily misuse version or wipe the ingest list.

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 coverage is only 42%, so the description carries real weight; it does mention most of the undocumented fields by name (persona name, reply hours, ingest lines, conversation joining), mapping prose to parameters. But it adds no semantics beyond the names — no hour/timezone convention for reply_start_hour/reply_end_hour, no meaning for persona_mode or escalation_style (the 'handoff wording'), and no explanation of the required version parameter beyond a vague 'expected version'.

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 names a specific verb (Change) and resource (texting line) and enumerates the configurable surface — persona name, handoff wording, reply hours, ingest lines, conversation joining — so an agent knows the blast radius. It is essentially the title restated, but the title itself is substantive, and the closing pointer to messenger.autonomy.update helps separate fast-reply settings from this tool's scope.

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 only routing guidance is the closing sentence, which sends fast-reply autonomy toggling to messenger.autonomy.update — useful but not the nearest sibling. There is no guidance on when to use this versus summer_messenger_sms_read or summer_messenger_sms_create, and no note on prerequisites such as needing the current version before changing a line.

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?