Skip to main content
Glama
eonik-ai

eonik-mcp

Official

get_account_memory

Retrieve insights from your ad account's testing history to identify which creative choices are separating winners from losers in their own auctions, and how that edge holds or fades over time.

Instructions

What the user has tested in their OWN ad account, with receipts. Returns scopes (the auctions the account actually buys - objective + optimization goal + funnel stage), by_dimension allocation (spend and ad counts per creative dimension), and winners/losers where each ad is compared ONLY against the median CTR of its own auction, carried on scope_median_ctr. Rates are never comparable across auctions: on a live account two top-of-funnel auctions sit 41x apart on CTR from the optimization goal alone, so median_ctr is null and by_dimension[].avg_ctr is null wherever that value spans auctions. winners + losers equals judged_ads, not tested_ads - ads in an auction too thin to have a median appear in neither. Two horizons, and they answer different questions: craft_profile is a 90-day rolling snapshot - what separates the ads above their auction's median RIGHT NOW, and it can never say how long that has been true. craft_standing is the decay-weighted read across CLOSED weeks - held is what keeps separating, faded is what used to and stopped (which is the more useful half: it is how the account forgets last season on purpose). Never describe a craft_profile row as having held or worked for weeks - only craft_standing carries that, and only with weeks_separating of weeks_seen beside it. craft_standing is null until two weeks have closed; that is an honest silence, not an absence of craft. ⚠️ held means the choice keeps SEPARATING the two arms - not that it keeps working. Read latest_delta: a NEGATIVE delta means that craft choice is more common among the ads BELOW their auction's median. Always state the direction from the row's own counts, and never call a held row a thing that worked without checking its sign. Facts only, no predictions. Empty if Meta is not connected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It extensively explains nuances: non-comparability of rates across auctions, null behavior, the meaning of held/faded, the direction of delta, and the fact that winners+losers equals judged_ads not tested_ads. No contradictions exist.

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

Conciseness4/5

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

The description is lengthy but each sentence serves a purpose—clarifying interpretation, warning about pitfalls, and defining key terms. It is front-loaded with the primary purpose and structured around major concepts. While it could be trimmed, the density of critical caveats justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no annotations, and no output schema, the description is exceptionally complete. It explains the shape of the output, field semantics, null handling, temporal horizons, and interpretation guidelines, ensuring an agent can correctly use the tool without external references.

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?

The tool has zero parameters, so the baseline is 4. The description adds depth by explaining the meaning of output fields and how to interpret them, which is essential given the lack of an output schema. It does not need to describe parameters since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as retrieving the user's own ad account testing history, with specific outputs (scopes, by_dimension allocation, winners/losers) and unique comparative logic against auction medians. It distinguishes from sibling tools like get_account_condition or lookup_ad_performance by focusing on account memory and receipt-like details.

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?

The description implicitly clarifies usage: it's for the user's own account, not competitors or external data, and explains the two horizons (craft_profile vs craft_standing) answer different questions. It does not explicitly state when NOT to use it or name alternatives, but the context is strong enough that an agent can infer appropriate usage scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eonik-ai/eonik-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server