Skip to main content
Glama
Sign In

Summer

by ai.gosummer.api
OverviewDiscussionsAdmin
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.

List provider integrations, their categories, required fields, alternative credential sets and saved metadata

summer_integrations_list
Read-onlyIdempotent

List provider integrations, their categories, required fields, alternative credential sets and saved metadata. Filter by search, category or connection. Connected means all required credentials and one complete alternative set are available, not a live provider check. read_only integrations are read with the company's own key and never written through. Never returns values.

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>"
    },
    "name": "summer_integrations_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
searchNo
companyYesSummer company ID
categoryNo
connectionNo
environmentYesEnvironment that owns the resource

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
-  "clinical",
-  "messaging",
-  "shipping",
-  "billing",
-  "data",
-  "custom"
-]New value: +[
+  "clinical",
+  "messaging",
+  "helpdesk",
+  "orders",
+  "shipping",
+  "billing",
+  "marketing",
+  "data",
+  "custom"
+]
  2. Changed3 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
+  "enum": [
+    "clinical",
+    "messaging",
+    "shipping",
+    "billing",
+    "data",
+    "custom"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / connection
      Added value: +{
+  "enum": [
+    "connected",
+    "not_connected"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / search
      Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent safety, but the description adds meaning annotations cannot: 'connected' is credential completeness, not a live provider health check, read_only integrations are accessed with the company's own key, and no secret values are ever returned.

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?

Three dense sentences, front-loaded with the resource and its payload contents, with no filler. The 'read_only integrations are read with the company's own key' clause is slightly compressed prose but still earns its place.

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?

With no output schema, the description does the work of describing the returned record shape (categories, required fields, credential sets, metadata) and explicitly bounds it ('never returns values'). A small gap remains on pagination/result size and on the company/environment scoping.

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 coverage is only 40%, but the description compensates for the least self-explanatory part by defining what the `connection` enum values actually mean semantically, which the enum alone does not convey; search matching behavior and source of company/environment remain implicit.

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 first sentence gives a specific verb ('List') and resource ('provider integrations') and enumerates the payload contents (categories, required fields, alternative credential sets, saved metadata), which clearly separates it from the mutation sibling summer_integrations_save and from summer_credentials_list.

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?

It states the available filters ('search, category or connection'), which implies usage, but never says when to reach for this tool instead of summer_credentials_list or summer_account_connections_list, nor any prerequisites or exclusions.

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

All Summer toolsInspect
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