Skip to main content
Glama
Sign In
Microsoft Advertising MCP server

Microsoft Advertising MCP server

by get-mcp-ads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

bing get keywords

bing_get_keywords
Read-onlyIdempotent

Read keywords, bids, match types, and status for specific ad groups within your accounts. Manage Microsoft Advertising campaign data to optimize your search performance using the MCP server.

Instructions

Read keywords, match types, bids and status from an owned ad group.

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": {
      "accountId": "<accountId>",
      "campaignId": "<campaignId>",
      "campaignType": "<campaignType>",
      "adGroupId": "<adGroupId>"
    },
    "name": "bing_get_keywords"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountIdYesAccount ID listed in BING_ADS_ACCOUNT_IDS. Use the numeric ID, not the eight-character account number shown in the web app.
adGroupIdYesNumeric ad group ID in the selected campaign.
campaignIdYesNumeric campaign ID in the selected account.
campaignTypeYesNative type of campaignId, used to verify that it belongs to the account. Dynamic Search campaigns use Search with DynamicSearchAdsSetting.

Output Schema

NameRequiredDescriptionDefault
resultYesOriginal tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.1
    • changedOutput schema / properties / result / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no restating. The description adds the "owned" qualifier, which signals an access/permission precondition — useful context that annotations don't convey — but says nothing about volume, pagination, or whether all keywords are returned in one call.

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?

A single front-loaded sentence with zero filler; the operation and the returned data are stated immediately. Nothing could be removed without losing information.

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 an output schema present, return values need no explanation, and all four required parameters are fully documented in the schema. The remaining gap is behavioral: no statement about result volume or whether the call returns the full keyword list, which matters for a list-style read with no limit parameter.

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 100% and every parameter carries a detailed description, including the accountId vs. account-number caveat and the campaignType enum semantics, so the schema does the heavy lifting. The description adds nothing beyond the schema — its "owned ad group" phrasing loosely maps to the required accountId/campaignId/campaignType/adGroupId chain but adds no syntax or format detail.

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?

Specific verb+resource ("Read keywords ... from an owned ad group") and it enumerates the returned fields (match types, bids, status), so the agent knows exactly what it gets. It's implicitly distinct from siblings like bing_get_ads and bing_get_ad_groups by operating at the ad-group level, but it never names an alternative or explicitly scopes itself against them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"From an owned ad group" is the only contextual cue, hinting that the resource must be owned/accessible, but there is no when-to-use guidance, no prerequisites spelled out, and no alternatives (e.g., bing_get_ads, bing_get_targeting) referenced. The agent must infer selection from the tool name alone.

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