Jepto

Analytics Custom Field Create

analytics_custom_field_create

Creates a reusable calculated metric or dimension for a client using Jepto's existing Formula field API. Call analytics_schema first and use exact field names in the formula. The returned field can then be used by analytics_query and report_card_create.

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

Input Schema

Name	Required	Description	Default
`kind`	No	METRIC or DIMENSION. Calculated metrics are the normal use case.	METRIC
`label`	No	Display label for the calculated field.
`formula`	No	Formula expression (e.g. 'googleAds.cost / googleAds.clicks') or FormulaAST JSON.
`clientId`	No	16-character hex client id, as returned by client_list.
`isGlobal`	No	Create the field at account scope instead of client scope.
`fieldType`	No	NUMBER, CURRENCY, or PERCENTAGE.	NUMBER
`aggregation`	No	Optional aggregation such as SUM, AVG, or COUNT.
`dataSources`	No	Optional source keys; inferred from formula when omitted.
`description`	No	Human-readable explanation of the field.
`fieldFormat`	No	Optional ValueFormat configuration.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful workflow context — the mandatory schema-first step and that the created field becomes reusable by analytics_query and report_card_create. It stops short of describing duplicate-name handling, validation failures, or whether creation is idempotent.

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

Conciseness5/5

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

Three sentences, front-loaded with the core action, then prerequisite, then downstream use. Every sentence carries actionable information; nothing is redundant with the title or schema.

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 values need no explanation, and the description correctly focuses on inputs and follow-on tools. For a 10-parameter, zero-required mutation, it could say more about which parameters are practically mandatory (label, formula, clientId) and how scope selection works.

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?

Schema coverage is 100% and each parameter already carries a description, so the baseline is 3. The description adds real semantic value on top by instructing that formula field names must come from analytics_schema, which is the single most error-prone input here. It does not elaborate on the isGlobal/clientId interaction, which the schema leaves implicit.

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 states a specific verb and resource — 'Creates a reusable calculated metric or dimension' — plus the mechanism ('Jepto's existing Formula field API'). This is clearly distinct from sibling tools like report_card_create or analytics_query, which the description frames as downstream consumers rather than equivalents.

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 an explicit prerequisite ordering ('Call analytics_schema first and use exact field names in the formula') and names the tools that consume the result. What it lacks is any exclusion guidance — nothing says when to prefer isGlobal over client scope or when a plain report field would suffice instead.

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

All Jepto 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.