Skip to main content
Glama

Businesses like this one

get_benchmarks
Read-onlyIdempotent

How this account compares with businesses like it across Taseli (same platform, goal, kind of business and region; no business can be identified), as a decision: better, typical or weaker, with the rounded typical range (middle half) of cost per result, return on ad spend, cost per click, click rate, result rate and cost per 1,000 views next to this account's own value. Only comparisons from 10 or more businesses are given. Useful for 'is my cost per lead good?', 'what should I expect?'. A range is guidance, never a target. 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": "get_benchmarks"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoAn ad account's name, when it is about one account only; omit when it is about the whole business.
languageNoThe owner line's language. The business's language by default.

Output Schema

NameRequiredDescriptionDefault
asOfNoThe day the data runs to (the daily sync).
noteNoA plain note instead of a decision (nothing connected yet, not available here).
errorNoWhy nothing was judged, as a short code.
answerNoThe answer in one line, in the asked language. Every number in it comes from Taseli's code.
dontDoNoWhat not to do now, and why.
actionsNo
reasonsNoAt most 3 (6 with detail full), strongest first.
verdictNo
currencyNo
languageNo
nextCheckNoWhen Taseli looks again.
confidenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • addedOutput schema / properties / actions
      Added value: +{
      +  "items": {
      +    "properties": {
      +      "approvalUrl": {
      +        "description": "Where the owner approves it, in Taseli.",
      +        "type": "string"
      +      },
      +      "proposalId": {
      +        "type": "string"
      +      },
      +      "tool": {
      +        "description": "A ready call with its arguments.",
      +        "properties": {
      +          "args": {
      +            "type": "object"
      +          },
      +          "name": {
      +            "description": "A tool on this server.",
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "what": {
      +        "type": "string"
      +      },
      +      "who": {
      +        "description": "taseli: Taseli does it or already watches; owner: a tap in Taseli or a fix on the site; agent: the caller may do it.",
      +        "enum": [
      +          "taseli",
      +          "owner",
      +          "agent"
      +        ],
      +        "type": "string"
      +      },
      +      "worth": {
      +        "properties": {
      +          "basis": {
      +            "enum": [
      +              "measured",
      +              "estimated"
      +            ],
      +            "type": "string"
      +          },
      +          "monthly": {
      +            "type": "number"
      +          }
      +        },
      +        "type": "object"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / answer
      Added value: +{
      +  "description": "The answer in one line, in the asked language. Every number in it comes from Taseli's code.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / asOf
      Added value: +{
      +  "description": "The day the data runs to (the daily sync).",
      +  "type": "string"
      +}
    • addedOutput schema / properties / confidence
      Added value: +{
      +  "properties": {
      +    "level": {
      +      "enum": [
      +        "low",
      +        "medium",
      +        "high"
      +      ],
      +      "type": "string"
      +    },
      +    "why": {
      +      "description": "Why, in numbers (days, results, what was left out).",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
    • addedOutput schema / properties / currency
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / dontDo
      Added value: +{
      +  "description": "What not to do now, and why.",
      +  "items": {
      +    "properties": {
      +      "line": {
      +        "type": "string"
      +      },
      +      "why": {
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / error
      Added value: +{
      +  "description": "Why nothing was judged, as a short code.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / language
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / nextCheck
      Added value: +{
      +  "description": "When Taseli looks again.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / note / description
      Previous value: -"A plain note instead of data (nothing connected yet, not available here)."New value: +"A plain note instead of a decision (nothing connected yet, not available here)."
    • addedOutput schema / properties / reasons
      Added value: +{
      +  "description": "At most 3 (6 with detail full), strongest first.",
      +  "items": {
      +    "properties": {
      +      "evidence": {
      +        "items": {
      +          "properties": {
      +            "fact": {
      +              "type": "string"
      +            },
      +            "n": {
      +              "description": "Peers only: how many businesses the figure comes from.",
      +              "type": "number"
      +            },
      +            "source": {
      +              "enum": [
      +                "account",
      +                "history",
      +                "peers",
      +                "rules",
      +                "memory",
      +                "calendar"
      +              ],
      +              "type": "string"
      +            },
      +            "value": {
      +              "anyOf": [
      +                {
      +                  "type": "number"
      +                },
      +                {
      +                  "type": "string"
      +                }
      +              ]
      +            },
      +            "window": {
      +              "type": "string"
      +            }
      +          },
      +          "type": "object"
      +        },
      +        "type": "array"
      +      },
      +      "line": {
      +        "description": "One plain reason.",
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • removedOutput schema / properties / text
      Removed value: -{
      -  "description": "The answer in plain words.",
      -  "type": "string"
      -}
    • removedOutput schema / properties / truncated
      Removed value: -{
      -  "type": "boolean"
      -}
    • removedOutput schema / properties / truncatedNote
      Removed value: -{
      -  "type": "string"
      -}
    • addedOutput schema / properties / verdict
      Added value: +{
      +  "enum": [
      +    "better",
      +    "typical",
      +    "worse",
      +    "range_only",
      +    "not_enough"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and closed-world behavior, and the description adds genuinely new context: comparisons are anonymized ('no business can be identified') and suppressed below a 10-business sample. It also sets interpretation expectations ('a range is guidance, never a target'), though it does not say how the 'better/typical/weaker' verdict is computed.

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 purpose is front-loaded in the first clause and nearly every phrase carries information (sample threshold, privacy, metric list, interpretation caveat). The main cost is that the core is delivered as one long run-on sentence with an embedded parenthetical, which slows parsing.

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?

With an output schema handling return shape and annotations handling safety, the description fills the remaining gaps: privacy, the minimum peer sample, and how the range should be read. Nothing an agent needs to call this correctly or interpret the result is missing.

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% and the two parameters are already documented there, including the omit-for-whole-business rule for 'account' and the language default. The description adds nothing parameter-specific, so the baseline of 3 applies.

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 names a specific operation (comparing this account's metrics against peer businesses on the same platform, goal, kind and region) and enumerates the five metrics compared plus the three-way decision outcome. That is enough for an agent to distinguish it from market-level siblings such as get_market_insights or get_market_trends without opening a schema.

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 gives concrete triggering questions ('is my cost per lead good?', 'what should I expect?'), which tells the agent when to reach for this tool. It stops short of naming an alternative or stating when not to use it, so it lands at clear-context-without-exclusions rather than a full routing rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources