Skip to main content
Glama
LinkedIn Ads MCP Server

LinkedIn Ads MCP Server

Get example prompts

get_example_prompts
Read-onlyIdempotent

Returns example prompts for reporting, optimizing, and launching LinkedIn Ads campaigns, helping users decide what to try first or ask the agent.

Instructions

Get example prompts that work with the hosted LinkedIn Ads MCP server by AdKit, such as reporting, optimizing and launching campaigns. Use this when the user asks what to try first or what to ask the agent. Returns a Markdown list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_example_prompts"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context by stating the return format ('Returns a Markdown list') and by naming the backing server, which matters for this zero-parameter tool. It does not say how many prompts are returned or whether the content is static, so a 4 rather than 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.

Conciseness5/5

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

Three sentences with zero filler: what it returns, when to call it, and what the output looks like. The trigger condition is placed early, so an agent scanning the definition finds the decision-relevant clause immediately.

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 zero-parameter, no-output-schema content fetch, this covers purpose, trigger and return format, which is essentially everything an agent needs to call it correctly. A minor omission is scope information such as whether the prompt list is static or how comprehensive it is, but nothing blocks correct invocation.

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?

There are no parameters, so the baseline is 4. The schema correctly exposes an empty object and the description rightly spends no words on parameter syntax.

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 concrete verb and resource ('Get example prompts that work with the hosted LinkedIn Ads MCP server by AdKit') and illustrates the content domain with 'reporting, optimizing and launching campaigns'. It does not explicitly distinguish itself from same-family content siblings like get_faq or get_setup_guide, which keeps it out of the top band.

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 gives an explicit trigger: 'Use this when the user asks what to try first or what to ask the agent.' That is a clear use case an agent can pattern-match on. It stops short of stating when-not to use it or naming get_faq/get_setup_guide as alternatives for adjacent questions.

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