Autario

update_app_manifest

Idempotent

Update the manifest of an app YOU own: its name, tagline, entry URL, version, source repository and the autario datasets or operations it is allowed to read (consumed_datasets, which is what the sandbox bridge enforces at runtime: a World Bank or FRED dataset id, a live Yahoo quote op, or the caller's own Google Search Console and GA4 connector tables). Only the fields you pass change; everything else on the manifest is kept. Use it to declare data access after create_app, to declare that reports of the app may be shared on a secret link (share), or to rename or re-point an existing app. An app you do not own answers "not found". This never changes who may open the app: publishing is publish_app, deliberately a separate act.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New display name. Omit to keep the current one.
`tier`	No	Runtime model. 2 = sandboxed custom app (the default for anything you build here). Only set this if you know you need 1.
`share`	No	Let a report of this app be opened on a secret read-only link, e.g. {"subjects":["account"],"sections":["meta","report"]}. "subjects" says WHOSE data a link points at and may only name kinds autario can resolve ("account" = the owner of the link, which is what a third-party app wants); "sections" is the list a link may request, and anything outside it is refused. Omit the key to leave the current setting alone. An app that has never declared this cannot be shared at all. The owner still decides per link who may open it: anyone with the URL, only signed-in people from named company domains, or only named addresses.
`app_id`	Yes	The app id returned by create_app.
`tagline`	No	One-line description, max 200 chars.
`version`	No	Free-text version, e.g. "1.2.0". Bundles are stored per version.
`entry_url`	No	Where the app runs. An uploaded bundle uses the conventional "index.html".
`source_url`	No	Link to the open source repository.
`consumed_datasets`	No	What the app reads, e.g. [{"op":"datasetData","dataset":"<id>"}]. The sandbox bridge refuses any read the manifest did not declare. To read the connected accounts of whoever opens the app, add the connector keys: [{"op":"connectors","providers":["google_search_console","ga4"]}] \| those providers then appear on the Settings tab of the app with the connection state of that viewer, so a user who has not connected one can connect it from inside the app. Add "optional": true and "unlocks":"<what it adds>" for a source the app works without.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026

addedInput schema / properties / share

Added value: +{
+  "description": "Let a report of this app be opened on a secret read-only link, e.g. {\"subjects\":[\"account\"],\"sections\":[\"meta\",\"report\"]}. \"subjects\" says WHOSE data a link points at and may only name kinds autario can resolve (\"account\" = the owner of the link, which is what a third-party app wants); \"sections\" is the list a link may request, and anything outside it is refused. Omit the key to leave the current setting alone. An app that has never declared this cannot be shared at all. The owner still decides per link who may open it: anyone with the URL, only signed-in people from named company domains, or only named addresses.",
+  "type": "object"
+}

Changed1 schema field changedSep 12, 2026

changedInput schema / properties / consumed_datasets / description

Previous value: -"What the app reads, e.g. [{\"op\":\"datasetData\",\"dataset\":\"<id>\"}]. The sandbox bridge refuses any read the manifest did not declare."New value: +"What the app reads, e.g. [{\"op\":\"datasetData\",\"dataset\":\"<id>\"}]. The sandbox bridge refuses any read the manifest did not declare. To read the connected accounts of whoever opens the app, add the connector keys: [{\"op\":\"connectors\",\"providers\":[\"google_search_console\",\"ga4\"]}] | those providers then appear on the Settings tab of the app with the connection state of that viewer, so a user who has not connected one can connect it from inside the app. Add \"optional\": true and \"unlocks\":\"<what it adds>\" for a source the app works without."

AddedSep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotation hints, it discloses partial-update semantics ('Only the fields you pass change'), ownership behavior ('app you do not own answers not found'), runtime enforcement by the sandbox bridge, and the sharing restriction when share was never declared. This all aligns with readOnlyHint=false, idempotentHint=true, and destructiveHint=false.

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 dense and front-loaded with the core purpose, which suits a complex nested-parameter tool. However, it is one long continuous paragraph with many parenthetical asides and compound clauses, which makes scanning slightly harder than a more structured layout would.

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 9-parameter mutation tool with nested objects and no output schema, the description provides everything needed to decide when to call it and how to invoke it correctly: ownership rules, field scope, examples for complex params, runtime enforcement, and the sibling tool that handles publishing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning the schema alone lacks: consumed_datasets gets concrete op/dataset examples and connector behavior, share gets subject/section semantics and the 'never declared cannot be shared' rule, and tier is contextualized via the sandbox runtime model.

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 opens with a specific verb and resource: 'Update the manifest of an app YOU own', then enumerates exactly which fields are affected. It also differentiates from siblings by stating that publishing is deliberately handled by publish_app, so an agent cannot confuse manifest updates with access control.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit use cases: declaring data access after create_app, enabling secret-link sharing, and renaming or re-pointing an existing app. It also states exclusions clearly: apps you do not own answer 'not found', and this tool never changes who may open the app — that is publish_app's role.

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

All Autario 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?