autario-mcp

geo_experiment

ADMIN/CURATOR ONLY, the GEO/SEO experiment ledger (spec 2026-11-08-geo-mcp-loop): the dated book of every crawler-touchable change, marker, open question and prediction, the one thing that makes a move in the organic channel (Google, Bing, LLM citations) attributable. Three actions: add writes one row ({title, change?, expected_effect?, kind? = change | marker | open_question | prediction, date? = today, review_after_days? = 14, notes?, url_path? = the page the change touched, as a path like /connectors/shopify, so the row joins the per-URL signals}; same date + title twice = reported as duplicate, never a second row); review records the verdict on one row ({id, verdict = helped | hurt | neutral | unknown, notes?}); list returns the ledger ({open?: true = unreviewed rows only, limit? = 50}), each row with id, date, kind, title, change, expected_effect, review_after_days, reviewed_at, verdict, notes, url_path. The numbers to judge a row against are in get_traction_overview under geo (28 days of geo_metrics_daily, SSR health, the crawler split) and geo_ledger (open rows with due flags, the last verdicts, Bing citations per URL); per-URL detail is in seo_360 / content_360 / audience_360 on the autario.com property. The same doors as the CLI geo-experiment add|review|list. Requires the connector to be OAuth-authorized as the autario curator account | any other caller gets a permission error. Use when asked "log this change in the GEO ledger", "what is due for review", "record the verdict on experiment 12".

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": {
      "action": "<action>"
    },
    "name": "geo_experiment"
  }
}

Input Schema

Name	Required	Description
`id`	No	review: the ledger row id (from list).
`date`	No	add: the day the change went live, YYYY-MM-DD (default today).
`kind`	No	add: change (default) = something we shipped; marker = an observed external inflection; open_question = a suspected external cause; prediction = a standing falsifiable prediction.
`open`	No	list: true = unreviewed rows only (default all).
`limit`	No	list: max rows (default 50).
`notes`	No	add or review: free-form notes or links.
`title`	No	add: short stable handle of the change (unique with date).
`action`	Yes	add = one new ledger row; review = the verdict on one row; list = the ledger rows.
`change`	No	add: what exactly changed, one or two sentences.
`format`	No	Output wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
`verdict`	No	review: the verdict.
`url_path`	No	add: the page the change touched, a site-relative path (/connectors/shopify) or an autario.com URL; omit for site-wide changes.
`expected_effect`	No	add: the effect expected on impressions, clicks, LLM leads or indexing (the falsifiable part).
`review_after_days`	No	add: when the verdict is due, counted from date (default 14).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and idempotentHint=false; the description adds real context on top: OAuth must be the autario curator account or callers get a permission error, and re-adding the same date+title is reported as a duplicate rather than creating a second row. It does not disclose what happens if `review` is called twice on the same id (overwrite vs. error), which matters given idempotentHint=false.

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?

Front-loaded and free of filler, but it is one dense run-on block with deeply nested parentheticals that restate schema defaults (date=today, review_after_days=14, limit=50) and the kind enum already documented in the schema. The information density is high, but the structure makes it harder to scan than necessary.

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?

For a three-action mutation tool with 14 parameters and no output schema, the description still enumerates the fields returned by `list` (id, date, kind, title, change, expected_effect, review_after_days, reviewed_at, verdict, notes, url_path), names the auth requirement, and points at where the judging data lives. An agent has everything needed to call it correctly.

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%, so baseline is 3, but the description adds genuine meaning: url_path is explained as the join key to per-URL signals (with a concrete path example), expected_effect as "the falsifiable part", and title+date as the uniqueness pair. Some of the parameter detail (defaults, kind enum values) merely restates 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?

States a specific resource (the GEO/SEO experiment ledger) with an explicit verb set (`add` writes, `review` records a verdict, `list` returns rows) and explains what makes it distinct: it is the attributable record of crawler-touchable changes. It also names the companion tools (get_traction_overview, seo_360, content_360, audience_360) so an agent can tell ledger-writing apart from metric-reading.

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?

Gives concrete trigger phrasings ("log this change in the GEO ledger", "what is due for review", "record the verdict on experiment 12") and routes the agent to get_traction_overview under `geo`/`geo_ledger` for the numbers to judge against. It also states the ADMIN/CURATOR-only gate. It does not say when not to use it (e.g. logging non-GEO work), but the context is otherwise clear.

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

All autario-mcp 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.