Taseli

Test an idea of the owner's

test_idea

Idempotent

Puts one idea the owner wants TESTED into Taseli's test queue: 'try a headline with the price', 'test a video with a customer', 'what if the ad shows the team'. Taseli's test calendar runs it before its own ideas, as soon as the account has room and budget (one idea against what runs now, a fixed end, the lesson kept), and shows it on the plan page. Not for a change to make now, and not for a lasting rule. It changes nothing in the ad account by itself: every ad it makes is a decision the owner approves. A queued idea shows on the plan page; no run date is promised.

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": {
      "idea": "<idea>",
      "said_by_owner": "<said_by_owner>"
    },
    "name": "test_idea"
  }
}

Input Schema

Name	Required	Description
`say`	No	The same idea, short, in the language of the conversation, as the owner would read it.
`idea`	Yes	The idea in one plain English line that stands on its own, keeping the owner's own details (what to show, say or lead with), e.g. 'A headline that opens with the price, against the current headlines.'
`quote`	No	The owner's own words, as written (any language). Required when said_by_owner is true.
`account`	No	An ad account's name, when it is about one account only; omit when it is about the whole business.
`platform`	No	Only when the owner named a platform or the idea can run on one only (a video: meta or tiktok; a headline: google). Omit when open.
`said_by_owner`	Yes	true only when the owner asked for this test outright in this conversation.

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

A4.4/5.0

Behavior5/5

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

The description discloses behavior well beyond the annotations: the idea is queued, prioritized ahead of Taseli's own ideas, run when there is room and budget, has a fixed end, and keeps the lesson. It also states that nothing changes in the ad account without owner approval and that no run date is promised.

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 front-loaded and most sentences earn their place by clarifying queue behavior, exclusions, and approval limits. There is minor repetition around showing the queued idea on the plan page, but the overall structure is efficient.

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 the mutation annotations, rich schema, and output schema, the description provides the missing context an agent needs: it explains queuing, approval behavior, timing uncertainty, and what the tool is not for. Nothing essential is left unclear for correct invocation.

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 parameter meaning is already documented in the input schema. The description reinforces the idea of preserving the owner's own details and using the owner's words, but it does not add substantial parameter-level semantics beyond the schema.

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 uses a specific verb and resource: it 'Puts one idea the owner wants TESTED into Taseli's test queue.' The examples clarify the kind of input, and the exclusions ('Not for a change to make now, and not for a lasting rule') distinguish it from related mutation and rule-setting tools.

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 clearly states when to use the tool: an idea the owner wants tested, with concrete examples. It also gives useful exclusions, but it does not explicitly name sibling alternatives such as propose_change or record_idea, so the routing guidance is strong but not fully explicit.

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?