Skip to main content
Glama
ghl-mcp-server-v2

ghl-mcp-server-v2

by zackscriven

ghl_store_list_shipping_carriers

Read-onlyIdempotent

Retrieve available shipping carriers for a GoHighLevel sub-account location, so you can identify carrier options for store shipping setup.

Instructions

List Shipping Carriers The "List Shipping Carrier" API allows to retrieve a list of shipping carrier. Endpoint: GET /store/shipping-carrier (Version header: v3; source: v3/store-v3.json) Requires a Sub-Account (location) token.

Input Schema

NameRequiredDescriptionDefault
altIdYesLocation Id or Agency Id
altTypeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds the auth requirement of a location token plus the concrete endpoint and API version, which is real context beyond the annotations. It omits pagination and result-size behavior, keeping it from a 5.

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

Conciseness3/5

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

The core purpose is front-loaded, but three lines are spent on API metadata (endpoint path, version header, JSON source file) that adds little for an agent selecting a tool, and the first two sentences restate the same thing.

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 a 2-required-param read tool with no output schema, the description covers auth and the endpoint but says nothing about the returned carrier fields, pagination, or whether results are scoped per location. Adequate but with clear gaps.

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 50%: altId is documented as 'Location Id or Agency Id' but altType (enum 'location') has no schema description. The description's note about a location token loosely maps to altId but adds nothing for altType, so it neither compensates for nor worsens the coverage gap.

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?

States a specific verb and resource ('List Shipping Carriers' / 'retrieve a list of shipping carrier') that clearly separates it from single-record siblings like ghl_store_get_shipping_carrier. The title line and API sentence are redundant but the intent is unambiguous.

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?

No explicit when-to-use or alternatives are named; selection versus ghl_store_get_shipping_carrier or ghl_store_get_available_shipping_rates is left implicit. It does state a prerequisite ('Requires a Sub-Account (location) token'), which gives partial usable context.

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

Deploy Server

Other Tools