gtm-api: LinkedIn MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GTM_API_KEY | Yes | API key (gtm_live_...) from app.gtm-api.com, sent as the bearer token. Without it the launcher signs in with OAuth in a browser. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_toolsetsA | List the available toolsets (domains) on this server. Each toolset groups related tools (e.g. linkedin.messaging, id.billing). Start here, then get_toolset_tools to inspect one, then call_tool to run a tool. Requires OAuth authorization (Bearer token). |
| get_toolset_toolsA | List the tools in a toolset. Default (lite) returns name + title + one-line summary; pass verbose:true for full descriptions, safety flags, and parameter names. Run one via call_tool. |
| call_toolA | Invoke a tool by name (discovered via get_toolset_tools) with its arguments object. Behaves exactly like calling the tool on its domain mount. Dangerous tools still require the two-step preview→confirm (pass commit_token inside arguments on the confirm call). To act in another of your teams, set the top-level team_sid: the edge swaps the token for that team (the OAuth grant must cover it); every response echoes the team it ran in as meta.team_sid. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools form an explicit, non-overlapping discovery→inspection→invocation pipeline, and each description states its position in that sequence. There is no realistic way to confuse listing toolsets, listing tools in a toolset, and invoking a tool.
All names are snake_case verb_noun pairs (list_toolsets, get_toolset_tools, call_tool), which is predictable and readable. The only minor wrinkle is that the object noun shifts between 'toolsets' and 'tool', though the intent is obvious from context.
Three tools is at the low end, but for a dynamic gateway that proxies an unbounded catalog, a small fixed surface is exactly right and each tool earns its place. Nothing is redundant or missing at the plumbing layer.
Discovery, schema retrieval (lite vs verbose), and execution including the preview→confirm commit_token flow and team_sid override are all covered. Minor gaps: no cross-toolset keyword search and no dedicated authorization/introspection tool, so an agent must walk toolsets sequentially to find a capability.