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, change, remove (retire) or restore one pharmacy in the directory with the expected version

summer_pharmacy_calls_directory_update

Destructive

Add, change, remove (retire) or restore one pharmacy in the directory with the expected version. Save sends every field; empty fields are cleared. Calls stay off until call_allowed is true, and need a phone number. Retire turns calls off and keeps the record and its history. Starts no call.

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>",
      "operation": "<operation>",
      "version": "<version>"
    },
    "name": "summer_pharmacy_calls_directory_update"
  }
}

Input Schema

Name	Required	Description
`id`	No	The pharmacy to change. Leave out to add a new pharmacy.
`entry`	No	Every field of the pharmacy, for save. Fields you leave empty are cleared.
`company`	Yes
`version`	Yes	The version you read, or 0 for a new pharmacy. A newer saved version refuses the change.
`operation`	Yes	save adds a pharmacy (no id, version 0) or replaces all fields of one; retire removes it from use and turns calls off; restore brings a removed one back with calls off.
`environment`	Yes
`idempotency_key`	No	Reuse the same key when retrying the same change

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the destructive/open-world annotations, it discloses meaningful behavior: save sends every field and clears empty ones, retire keeps the record and history while turning calls off, and the operation starts no call. These details materially improve the agent's understanding of consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with the core purpose first and then only high-value constraints about save, calls, retire, and side effects. Every sentence contributes useful information without waste.

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 tool with nested objects, no output schema, and destructive annotations, it covers the essential operational behavior and side effects. It is slightly incomplete on return behavior and does not fully address all sibling distinctions, but the combination of schema and description is largely sufficient to call it correctly.

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 71%, so many parameters are already documented, but the description adds cross-field semantics: save replaces all fields and clears empty ones, calls need call_allowed=true and a phone number, and retire preserves history. It does not clarify every parameter, such as preferred_channel or company/environment context, but it adds real meaning beyond the schema.

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 states a specific verb and resource: updating one pharmacy in the directory, with add/change/retire/restore operations. It is clear what the tool does, but it does not explicitly distinguish this from nearby siblings such as directory_read or address_update.

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 explains the operation choices well: save adds or replaces all fields, retire removes from use and turns calls off, restore brings a removed entry back. It gives important usage conditions such as empty fields being cleared and calls requiring call_allowed=true plus a phone number, though it does not explicitly compare against sibling tools.

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?