Connect with Google Ads, Meta Ads, Search Console and more
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 7 tools
Each tool has a clearly distinct purpose: memory management (delete, list, save), data retrieval (fetch_data), artifact pagination (get_artifact_page), brand context (list_brands), and transformation (transform). No two tools overlap in functionality.
Most tools follow a verb_noun pattern (delete_memory, fetch_data, get_artifact_page, list_brands, list_memories, save_memory), but 'transform' is just a verb without a noun, a minor deviation. The style is otherwise consistent.
7 tools is well within the ideal range for a focused server. Each tool is necessary and contributes to a coherent workflow—no redundant or trivial tools.
The tool surface covers the core workflow: brand selection, memory context, data fetching, pagination, and transformation. Missing write-back or refresh capabilities, but the server appears read-only and analysis-focused, so no critical gaps.
Use when the user asks to forget a memory or before replacing overlapping context with one consolidated memory. Deletes the exact memory ID only for this user and brand.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_id | Yes | Brand whose personal reporting memories should be loaded. Example: `br_abc123`. Rules: copy an exact accessible ID supplied by the host or list_brands. | |
| memory_id | Yes | Personal memory to delete. Example: `me_abc123`. Rules: copy the exact ID returned by list_memories or save_memory for this brand. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | |
| memory_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the mutation risk is known. The description adds useful behavioral context beyond that: deletion is limited to the exact memory ID and is scoped to a single user and brand, and it clarifies the replacement workflow sequencing. This adds value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The when-to-use condition is front-loaded, and the scope constraint follows immediately. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive operation with a fully documented schema, an output schema, and a destructiveHint annotation, the description is complete. It covers when to invoke the tool, what it deletes, and the isolation scope. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both brand_id and memory_id fully documented including patterns, examples, and rules for sourcing exact IDs. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Deletes'), a precise resource ('the exact memory ID'), and a clear scope ('only for this user and brand'). This distinguishes it from siblings like save_memory and list_memories without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: when the user asks to forget a memory, or before replacing overlapping context with a consolidated memory. It does not explicitly name sibling alternatives or state when not to use it, but the context and exact-ID scoping make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for one fresh, read-only table from exactly one source. Choose google_ads for Google paid-media delivery and account performance; meta_ads for Meta Ads performance across Facebook, Instagram, and Messenger; google_search_console for the connected site's observed organic queries, pages, clicks, impressions, and positions; google_analytics for sessions, users, events, and website conversions; keyword_research for exact demand, phrase suggestions, category or site ideas, historical demand, paid or organic competitor rankings, paid competitors, or a current Google results page; or web_search for public-page discovery, one exact page scrape, or a bounded site URL map. Keyword research requires an explicit market and language from the request or saved user context; never infer either. All keyword-research monetary estimates are USD, and paid competition is not organic difficulty. Site-derived ideas are not rankings. When the user does not request a keyword count, ask for at most 25 rows. Give one self-contained request with its scope, dates, metrics, dimensions, filters, and ordering. Keep each fetch to one resource and grain. Use additional fetch_data calls for other resources, grains, or sources, then transform their artifacts when they must be combined.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Reporting source for this request. Example: `google_ads`. Rules: choose exactly one listed source; use separate calls for other sources. | |
| request | Yes | Self-contained data request. Example: `Show campaign spend and conversions from 2026-08-01 through 2026-08-31, highest spend first.` Rules: use 3–6000 characters and include the required scope, dates, metrics, dimensions, filters, and ordering. | |
| brand_id | Yes | Accessible brand workspace. Example: `br_abc123`. Rules: copy an exact ID supplied by the host or list_brands and never infer it from a name. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| title | Yes | |
| offset | Yes | |
| columns | Yes | |
| has_more | Yes | |
| expires_at | Yes | |
| total_rows | Yes | |
| artifact_id | Yes | |
| next_offset | No | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavioral context beyond that: 'fresh' data, 'exactly one source,' the non-ranking nature of site-derived ideas, and the USD convention for keyword-research estimates. It also clarifies that paid competition is not organic difficulty, preventing a common misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, and every sentence carries a real constraint or routing rule. It front-loads the core invariant ('fresh, read-only table from exactly one source') before diving into source-specific guidance, and the caveats about keyword research are essential rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—six distinct data sources, nuanced keyword-research semantics, and a free-form request parameter—the description is remarkably complete. It covers source selection, request construction, row limits, combining results via transform, and the key pitfalls, while the presence of an output schema makes a return-format explanation unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning for the `source` and `request` parameters. It explains what each source is for, what a self-contained request must include (scope, dates, metrics, dimensions, filters, ordering), and adds constraints like at most 25 rows when no count is requested.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action statement: 'Use for one fresh, read-only table from exactly one source,' naming the resource class and its scope. It then enumerates each source (google_ads, meta_ads, etc.) with the exact use case it serves, making the tool's purpose unmistakable and differentiated from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance by mapping each source enum to a specific reporting need, then says to use additional fetch_data calls for other sources and transform artifacts when combining. It also provides hard rules such as requiring an explicit market and language for keyword research, never inferring them, and capping unrequested keyword rows at 25.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only to retrieve another page of an existing artifact. Copy its exact artifact ID and next_offset. This does not filter, aggregate, transform, or refresh data.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | First row index to return. Example: 20. Rules: use an integer from 0 to 19999; copy next_offset for the following page or omit for 0. | |
| brand_id | Yes | Brand that owns the artifact. Example: `br_abc123`. Rules: copy the exact accessible brand ID used to create the artifact. | |
| artifact_id | Yes | Artifact to paginate. Example: `ar_abc123`. Rules: copy an unexpired artifact ID returned by fetch_data or transform. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| title | Yes | |
| offset | Yes | |
| columns | Yes | |
| has_more | Yes | |
| expires_at | Yes | |
| total_rows | Yes | |
| artifact_id | Yes | |
| next_offset | No | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond those hints: the tool returns an already-existing artifact page and does not refresh or transform data, so the agent knows not to expect fresh computation or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core instruction ('retrieve another page') is front-loaded, and the negative constraints are stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pagination tool with full schema coverage and an output schema, the description is complete. It explains the exact purpose, what not to expect, and how to call it correctly; the schema covers parameter formats and valid ranges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents offset, brand_id, and artifact_id. The description reinforces copying artifact_id and next_offset, but adds no materially new parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('retrieve') and resource ('another page of an existing artifact'), and clarifies what the tool does not do ('filter, aggregate, transform, or refresh data'), which separates it from sibling tools like fetch_data and transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use only to retrieve another page' clearly states when the tool is appropriate, and 'does not filter, aggregate, transform, or refresh data' excludes common misuse. It does not explicitly name alternative tools for initial fetching or transformation, but the intended usage is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use first when the requested brand is unknown or ambiguous, or when its available reporting sources are unclear. Lists accessible brands with their exact brand ID, team, role, connected sources, and selected advertising account context. Select one exact ID for later operations. Similarly named brands do not imply shared access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| brands | Yes | |
| next_action | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds access-scoping context ('accessible brands', 'Similarly named brands do not imply shared access') and clarifies the included advertising account context, which is meaningful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. It front-loads the trigger condition, then lists outputs, next action, and a caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only enumeration tool with an output schema, the description fully covers when to use it, what it returns, how to use the result, and an access caveat. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description's guidance to 'Select one exact ID for later operations' adds practical downstream context without needing to define parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('accessible brands'), enumerating the returned fields (brand ID, team, role, connected sources, advertising account context). This clearly distinguishes it from sibling tools like delete_memory, fetch_data, and transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use first when the requested brand is unknown or ambiguous, or when its available reporting sources are unclear') and instructs the agent to select one exact ID for later operations. The caveat about similarly named brands not implying shared access adds useful exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use once before substantive reporting for a selected brand. Lists this user's durable preferences and business context for that accessible brand. Treat memories as user-provided context, not evidence, and let the current request override conflicting memory.
| Name | Required | Description | Default |
|---|---|---|---|
| brand_id | Yes | Brand whose personal reporting memories should be loaded. Example: `br_abc123`. Rules: copy an exact accessible ID supplied by the host or list_brands. |
| Name | Required | Description |
|---|---|---|
| memories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds valuable epistemic guidance: memories are 'user-provided context, not evidence,' and the current request should override conflicting memory. It also notes the 'accessible brand' constraint, which is useful boundary information beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no redundant phrasing. The core purpose is front-loaded, and each sentence adds distinct value: when to use it, what it returns, and how to interpret the memories.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with a full output schema and comprehensive annotations, the description covers the key operational context: when to invoke it, what it provides, and the reliability caveats. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself provides a detailed description, example, and copy rule for brand_id. The tool description does not add meaningful parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: 'Lists this user's durable preferences and business context for that accessible brand.' It specifies a concrete resource (brand memories) and a verb ('lists'), and the scope ('for a selected brand') distinguishes it from sibling tools like list_brands or save_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use once before substantive reporting for a selected brand.' It does not explicitly name when not to use it or alternatives, but the instruction 'Use once' and the focus on pre-reporting context provide clear guidance for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only when the user explicitly asks to remember something or clearly establishes a durable preference. Saves one personal preference or business fact for this user and brand. Never save report results, temporary account state, inferred facts, or credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Durable personal preference or business fact to remember. Example: `Default keyword-research market and language: United States, English.` Rules: use 1–1000 characters, save one consolidated fact, and never store report results, temporary state, inferred facts, or credentials. | |
| brand_id | Yes | Brand whose personal reporting memories should be loaded. Example: `br_abc123`. Rules: copy an exact accessible ID supplied by the host or list_brands. |
| Name | Required | Description |
|---|---|---|
| memory | Yes | |
| created | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the description doesn't need to restate those. The description adds meaningful behavioral context by defining what counts as saveable content and what must never be saved, which goes beyond the annotations. It doesn't describe side effects like overwriting existing memories, but the idempotent hint covers the core safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most important usage rule. Every sentence earns its place: the first sentence states the trigger, the second states the action and scope, and the third lists exclusions. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter write tool with an output schema and strong annotations, the description covers the essential context: when to use, what to save, and what to avoid. The only minor gap is not explaining what happens on overwrite or how the memory is stored, but the idempotent hint and output schema mitigate that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces the content rules and brand_id sourcing ('copy an exact accessible ID supplied by the host or list_brands'), which adds practical guidance beyond the schema's basic descriptions. The example values in the schema also help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('saves'), a specific resource ('one personal preference or business fact for this user and brand'), and explicitly distinguishes it from report results, temporary state, inferred facts, and credentials. It clearly differentiates from siblings like list_memories and delete_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition ('Use only when the user explicitly asks to remember something or clearly establishes a durable preference') and explicit exclusions ('Never save report results, temporary account state, inferred facts, or credentials'). This is strong when-to-use guidance that also prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after inspecting one or more existing artifacts to create a new artifact through a precise natural-language transformation. State the exact aliases, columns, joins, unions, grouping, calculations, filtering, sorting, deduplication, normalization, and output shape required. This does not refresh reporting sources.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Complete transformation instructions. Example: `Group campaigns by Channel, sum Spend, and sort descending.` Rules: use 3–6000 characters and state exact aliases, columns, joins, calculations, filters, ordering, and output shape. | |
| brand_id | Yes | Accessible brand workspace. Example: `br_abc123`. Rules: copy an exact ID supplied by the host or list_brands and never infer it from a name. | |
| artifacts | Yes | Input tables available to the transformation. Example: [{ artifact_id: `ar_abc123`, as: `campaigns` }]. Rules: include 1–20 unexpired artifacts with unique aliases from the same brand. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| title | Yes | |
| offset | Yes | |
| columns | Yes | |
| has_more | Yes | |
| expires_at | Yes | |
| total_rows | Yes | |
| artifact_id | Yes | |
| next_offset | No | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false; the description adds that the tool creates a derived artifact and explicitly does not refresh reporting sources. No contradiction: 'create' refers to the transformation output, not a persistent mutation of source state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the purpose, then give the core instruction and a qualifying non-goal. The long list of transformation dimensions is dense but directly actionable, so no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations present, the description covers the invocation context ('after inspecting'), the required precision of the request, and what the operation does not do. Parameter-level rules are already in the schema, so the remaining gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for request, brand_id, and artifacts. The description restates much of the request parameter's guidance and adds only minor terms (deduplication, normalization), so it does not materially move beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('a new artifact') and frames the operation as a transformation of existing artifacts. It distinguishes itself from fetch/list/save siblings by positioning the tool as post-inspection derivation and by stating it does not refresh reporting sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use after inspecting one or more existing artifacts,' giving a clear sequencing condition. It also states an explicit non-goal ('does not refresh reporting sources'), though it stops short of naming the sibling tool to use when a refresh is actually needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
delete_memoryfetch_dataget_artifact_pagelist_brandslist_memoriessave_memorytransform
Add one secure layer between your agents and this server.