Taseli

Why a change was made

explain_change

Read-onlyIdempotent

The full recorded story of one change in an ad account, for 'why did you do that?', 'who changed X?', 'what happened with the budget change on…': what started it (an engine check, the daily review, a plan branch and its condition, a chat request, the owner, or someone outside Taseli), the numbers it was based on at the time, the owner's rules in force, the playbook rules and similar-business results it cited, the platform's dry run, who approved it, when and how, the run and its read-back, the watch and verdict, and what Taseli learned. Built from Taseli's records, not reconstructed. It covers one change; why a number moved is answered by the account review. Read only.

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": "explain_change"
  }
}

Input Schema

Name	Required	Description
`about`	No	The change in the person's own words, any language, e.g. 'the budget change on Summer sale yesterday' or 'who paused the brand campaign'.
`change`	No	The change's id (a decision id, the page or a link) or its number, e.g. '#12'. Omit when you only have words.
`account`	No	An ad account's name, when it is about one account only; omit when it is about the whole business.
`language`	No	Answer language. The business's language by default.

Output Schema

Name	Required	Description
`note`	No	A plain note instead of data (nothing connected yet, not available here).
`text`	No	The answer in plain words.
`truncated`	No
`truncatedNote`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the bar is lower, yet the description still adds real context beyond them: the record is 'built from Taseli's records, not reconstructed', and it enumerates the depth of the answer (trigger, contemporaneous numbers, rules in force, dry run, approver, run and read-back, watch verdict, learnings). 'Read only' merely repeats the annotation, but the provenance claim and coverage enumeration are genuine additions.

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

Conciseness3/5

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

Purpose is front-loaded in the first clause, which is good, but the rest is a single dense paragraph with a long parenthetical enumerating trigger sources and a second list enumerating artifacts, all crammed into one sentence. Every element is relevant, yet the packed list structure makes it harder to scan than a short bulleted breakdown would be.

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?

An output schema exists, so return shape need not be described, and the description still communicates the temporal/evidentiary scope of the answer and its one-change boundary. What is left thin is the relationship to sibling retrieval tools (get_decision, list_decisions), which for a zero-required-parameter lookup tool would be the main remaining ambiguity.

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 description coverage is 100%, so the schema already documents `about`, `change`, `account` and the `language` enum, including the 'omit when you only have words' rule. The description's example questions ('the budget change on Summer sale yesterday') loosely illustrate what to put in `about`, but add no format or precedence guidance beyond the schema. Baseline 3 applies.

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 pins down a specific resource: 'the full recorded story of one change in an ad account', and makes its scope explicit ('covers one change'). It differentiates from one sibling by naming the account review as the tool for number movements, but it never mentions get_decision or list_decisions, which are the closest neighbours for single-change lookup, so sibling separation is incomplete.

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?

Concrete triggering questions are given ('why did you do that?', 'who changed X?', 'what happened with the budget change on…'), which tells the agent exactly what user phrasing should select this tool. It also supplies one exclusion, routing 'why a number moved' to the account review. No guidance is offered on when to prefer get_decision or list_decisions instead.

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

All Taseli tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?