Animated map videos of any story: trips, wars, empires, storms, data. Free, no signup.
Scored across 15 tools
Most tools target clearly distinct operations (create/join/validate/export/render), but studio_list_capabilities, studio_describe_capabilities, and studio_get_guide all partly serve action discovery and schema lookups, which could cause some misselection. The request_preview vs get_job pairing is complementary but also slightly overlapping in intent.
Every tool uses the studio_ prefix followed by a consistent verb_noun pattern (create_project, list_templates, request_preview, validate_project, etc.). No mixed conventions or vague one-word names.
15 tools is well within the sweet spot for a project-editing studio and each tool maps to a genuine lifecycle step (discover, create, join, edit, validate, preview, export). No obvious redundancy bloat.
The surface covers the full workflow: capabilities/templates/examples discovery, project creation and pairing, atomic edits, validation, summaries, JSON export, and local preview/export rendering. Minor gaps like project deletion or listing existing projects are possible but not blocking for the stated purpose.
Atomically applies one or more registered actions. Non-conflicting stale edits are rebased; conflicting edits are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en | |
| actions | Yes | ||
| projectId | Yes | ||
| agentToken | Yes | ||
| baseRevision | Yes | ||
| clientMutationId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only and non-destructive, and the description adds genuine value beyond them: atomic application, rebasing of non-conflicting stale edits, and rejection of conflicting edits. This concurrency/conflict behavior is exactly the kind of context annotations cannot convey. It stops short of naming the revision parameter or the authentication requirement that governs those semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the atomicity guarantee is front-loaded before the conflict-handling detail. Nothing could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutation tool with 6 parameters, 0% schema coverage, and no output schema needs to carry far more of the load. The description omits authentication requirements, the role of baseRevision as the concurrency anchor, batch size limits, and what a successful or rejected application returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters, so the description must compensate and largely does not. 'Rebased/conflicting edits' gestures at baseRevision but never names it or explains its relationship to the described conflict behavior; agentToken, projectId, locale, clientMutationId, and the 1-100 action limit are entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('applies') and resource ('one or more registered actions') with an atomicity qualifier. It is clearly distinguishable from siblings like studio_validate_project or studio_request_preview, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no routing to alternatives. An agent cannot tell from the description whether this is the right call versus studio_validate_project or studio_request_preview, nor when a single vs batched application is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an anonymous project and returns the Studio link for the person plus an agent token for later edits. In one call it can start from a template (studio_list_templates), a guide example (studio_list_examples) or your own actions (studio_get_guide); aspect "9:16" makes a vertical Short.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| aspect | No | ||
| locale | No | en | |
| actions | No | ||
| example | No | ||
| template | No | ||
| agentLabel | No | AI agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a non-read-only, non-destructive creation call, and the description adds genuinely useful behavioral context beyond that: the project is anonymous, it returns both a share link and an agent token that authorizes later edits. It still omits limits, whether the token expires, or whether project creation is rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the return values and creation modes front-loaded. It is dense to the point of being slightly clipped (the second sentence compresses three modes plus the aspect hint), but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on explaining the return payload (link + agent token). For a 7-parameter, nested-object tool with zero required parameters, though, an agent still lacks guidance on defaults, on what 'anonymous' implies for ownership, and on the untouched name/locale/agentLabel parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the description must compensate, and it does so only partially. It usefully explains aspect ('9:16' makes a vertical Short) and identifies the template, example and actions sources, but leaves name, locale and agentLabel entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Creates an anonymous project') and immediately discloses what is returned: a Studio link for the person plus an agent token for later edits. It also enumerates the three viable starting points (template, guide example, own actions), clearly distinguishing it from the sibling list/get helpers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent to the right precursors by naming studio_list_templates, studio_list_examples and studio_get_guide in the context of each creation mode, which is strong when-to-use guidance. It does not state when *not* to use this tool (e.g., reusing an existing project via studio_join_project or editing via studio_apply_actions), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns schemas and examples for one or more Studio actions.
| Name | Required | Description | Default |
|---|---|---|---|
| actionIds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this is a safe read, and the description adds what is actually returned (schemas plus examples), which is meaningful context. It says nothing about result size, pagination, or what happens when an unknown action ID is passed, so it does not go far beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the resource and the return payload are both stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value meaning; 'schemas and examples' is a partial but honest summary. Missing are the 30-item limit's practical implication, ID format, and any hint that IDs come from a sibling listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter is an untyped array of strings with a 30-item cap. The phrase 'one or more Studio actions' clarifies that actionIds are action identifiers and that multiple may be supplied, but the ID format and where to obtain valid IDs are not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and resource ('schemas and examples for one or more Studio actions'), so the operation is clear. It does not, however, explicitly distinguish itself from siblings like studio_list_capabilities or studio_list_examples, which appear to overlap in the same discovery space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no prerequisites, and does not name an alternative tool. With three closely related discovery siblings (list_capabilities, list_examples, describe_capabilities), the absence of routing guidance leaves the agent to guess which one to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the portable .amtstudio.json content without collaboration secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds one genuinely useful behavioral fact — that collaboration secrets are stripped from the payload — but says nothing about auth requirements for agentToken, size limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the key payload fact front-loaded and no filler. It is efficient, though the extreme brevity is partly what leaves the usage and parameter gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value; it names the artifact type (.amtstudio.json) and notes secret stripping, which is reasonable. But it omits any auth/permission context and any distinction from the other export-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description explains neither parameter. In particular, agentToken is clearly a credential but its role and provenance are never stated, so an agent has no help beyond the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and resource ('portable .amtstudio.json content'), which is concrete enough for an agent to know what comes back. However it does not distinguish itself from the sibling studio_request_export, which plausibly also produces an export, so sibling differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance at all: nothing says whether this is synchronous or kicks off a job, nor when to prefer it over studio_request_export or studio_request_preview. The agent must infer the usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real coordinates for cities, towns and landmarks ([lat, lng], from OpenStreetMap) and the countries Studio can draw (with isoA2). Use it instead of guessing coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context: the data source (OpenStreetMap) and the exact return shape ([lat, lng] plus isoA2 for countries). It omits result-count/limit behavior and whether multiple matches are ranked, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the returned artifact and the OpenStreetMap provenance, closing with the routing directive. Every clause earns its place and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotation detail on returns, the description correctly takes on the job of describing what is returned (coordinates, isoA2), which is the key missing piece. It is slightly incomplete on multi-result/limit behavior, but for a two-parameter lookup tool it is essentially sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It implies that 'query' accepts place names for cities, towns, landmarks and countries, which is useful, but it never explains the 'limit' parameter, defaults, or the maximum result count even though the schema allows up to 10.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('find places') and precisely enumerates what comes back: coordinates for cities, towns and landmarks, plus drawable countries with isoA2. No sibling tool in the list performs geocoding, so the scope is unambiguous and the agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage directive: 'Use it instead of guessing coordinates,' which tells the agent the triggering condition (a need for real lat/lng). It does not name an alternative tool or state when-not to use it, but no sibling overlaps this capability, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything needed to build a story in one read: the fastest paths, how pieces combine (frame, shapes, move, mark, say, link, data, look), a complete example and the actions with their schemas. Read it once before building from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this is a safe read with no side effects. The description adds genuine value beyond that by disclosing what the payload contains (fastest paths, primitive list, a complete worked example, action schemas), letting the agent decide whether a full read is warranted before building.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the payload summary first and the call-to-action last; every clause names distinct content. The parenthetical primitive list is dense but informative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no output schema, and read-only annotations, the only open question is what comes back, and the description answers it by enumerating the guide's contents. Nothing needed to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema baseline of 4 applies. There is nothing for the description to clarify about inputs, and it does not attempt to invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('the Studio guide') and enumerates its contents (fastest paths, composition primitives, a complete example, action schemas), so an agent knows exactly what it gets. It does not explicitly distinguish itself from thematic siblings like studio_describe_capabilities or studio_list_examples, though the 'read once before building from scratch' framing implies an onboarding role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: 'Read it once before building from scratch,' which tells the agent this is a prerequisite/onboarding step rather than a per-task tool. No explicit exclusions or named alternatives are given, which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a local browser preview/export request.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| projectId | Yes | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is already supplied by annotations, so the description's only real job is to add behavior beyond that and it does not. It says nothing about job states, whether results are terminal or pending, polling expectations, or the agentToken auth requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no wasted words, but its brevity comes from under-specification rather than efficiency. There is no front-loaded actionable content beyond a restated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-parameter tool with no output schema and only a readOnlyHint annotation, the description is far too thin. An agent cannot tell what the return value represents or how this fits the preview/export workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three required parameters (jobId, projectId, agentToken), so the description carries the full burden and adds nothing. It never mentions jobId, projectId, or the token, leaving the meaning and sourcing of every parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'checks' is vague and the resource 'a local browser preview/export request' is a restatement of the title. It does not distinguish this polling-style read from siblings like studio_request_preview or studio_request_export, which are what create such requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no indication that this is the follow-up call after studio_request_preview/studio_request_export, and no mention of when it should not be used. The agent must infer the relationship to siblings entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the current revision and a compact timeline summary. Set includeProject only when complete raw data is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| agentToken | Yes | ||
| includeProject | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds the meaningful detail that the default output is a 'compact timeline summary' rather than raw data, but discloses nothing about auth requirements for agentToken, error behavior, or limits on the summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste; the purpose is stated first and the parameter guidance second. Tight and front-loaded, though the phrasing is terse enough to feel slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only summary tool with annotations covering safety and no output schema, the description conveys what is returned (revision + compact timeline summary) and how the flag changes it. The main gap is that the two credential/identity parameters are undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains includeProject well (only for complete raw data), but projectId and agentToken are left entirely to the schema types, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reads the current revision plus a compact timeline summary of a Studio project. The purpose is clear, but it never names a sibling (e.g. studio_export_json or studio_get_guide) to differentiate when this read is preferred, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives conditional guidance for one parameter ('Set includeProject only when complete raw data is needed'), which is real when-to-use guidance. However, it says nothing about when to choose this tool over the many read-oriented siblings like studio_export_json or studio_get_guide, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consumes a five-minute one-time pairing code shown by Studio.
| Name | Required | Description | Default |
|---|---|---|---|
| pairingCode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the write-but-safe profile is already covered. The description adds genuinely useful behavioral context beyond that: the code is valid for five minutes and is single-use, which implies it is consumed/invalidated on success. It does not say what joining does or what state change results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the key constraint (five-minute one-time) is stated up front. It is efficient, though the brevity contributes to the missing outcome/usage detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, return values need not be explained. However, for a mutation tool it does not state what joining accomplishes, what session/state results, or any auth requirements, leaving the post-invocation picture incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required parameter, so the description carries the semantic burden. It meaningfully describes the pairingCode's origin (shown by Studio), lifetime (five minutes), and single-use nature, compensating well, though it omits any format hints beyond the schema's length constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific mechanism (consuming a pairing code) that is unique among the siblings, so an agent can distinguish it from create_project, apply_actions, etc. It is clear but framed around the input mechanism rather than the action outcome (joining a project), which the title carries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use, when-not-to-use, or alternative routing. The only implicit guidance is that the code is 'shown by Studio', hinting at a prerequisite, but no condition for selecting this tool over siblings is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the live action registry. Call this before preparing or modifying a project.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this a safe read, so the bar is lower. The description adds only that the registry is 'live' and that it should precede project work; it says nothing about return format, filtering behavior, or result size. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero padding, and the purpose statement is front-loaded ahead of the usage cue. It is efficiently sized, though the brevity is partly under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only registry listing with a single optional parameter and no output schema, the description conveys purpose and a usage trigger but omits what a capability entry contains and what category filters. Adequate for a simple tool, with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional 'category' parameter at 0% schema description coverage, so the description carries the burden of explaining it. The description never mentions category, its accepted values, or its filtering effect, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Lists the live action registry.' The phrase 'live action registry' gives more than a bare restatement of the name. However, it does not differentiate from the closely overlapping sibling studio_describe_capabilities, leaving the list-vs-describe distinction to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear triggering context: 'Call this before preparing or modifying a project.' That tells the agent when to reach for this tool. It stops short of naming the alternative (studio_describe_capabilities) or stating when not to use it, so it is not a full when/when-not/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finished stories from the guides (a wildfire spreading, the euro year by year, a bar chart race, a war map, a train trip…). Start from one with studio_create_project example, then adapt places, texts and numbers with studio_apply_actions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so the safe-read nature is already covered. The description adds valuable context by explaining that these are finished stories intended as starting points for adaptation, which is behavioral insight beyond what annotations provide. It doesn't discuss return format or pagination, but that's minor given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the resource with vivid examples, the second outlines the intended usage sequence. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description sufficiently explains what the tool lists and how to use the result. It provides enough context for an agent to understand the tool's role in a workflow without needing more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4, and the description appropriately does not fabricate parameter details. It focuses on what the tool returns conceptually, which is relevant for a parameterless listing tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (list) and resource (finished guide examples) and paints what those examples are with concrete illustrations (wildfire spreading, euro year by year, bar chart race). This clearly distinguishes it from sibling tools like studio_list_templates or studio_list_capabilities, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes a usage pattern: start from an example with studio_create_project, then adapt with studio_apply_actions. This guides the agent on when and how to use the tool in a workflow. However, it doesn't state when not to use it or mention alternatives like studio_list_templates, so it's clear but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ready-made stories to fill in (a trip with stops, visited countries, an invasion, a growing empire, World War I and II, data maps, breaking news…). Pass one to studio_create_project as template { id, values }; values not given keep the defaults shown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already establishes this is a safe read, so the bar is lower. The description adds genuine behavioral context beyond that: values omitted keep the defaults shown, and the consumed shape is { id, values }, which tells the agent what it will need from the result when creating a project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource identity before the workflow instruction. The parenthetical example list is long and could be trimmed, but each example is illustrative rather than filler, so nothing is seriously wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with annotations and no output schema, the description covers what the templates are and how to use them downstream. It does not spell out the exact return shape (e.g., whether each template carries an id and default values), which is the only material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description's mention of the { id, values } shape is supplementary output-related context, not a substitute for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource concretely ('ready-made stories to fill in') and enumerates representative examples (trip with stops, visited countries, data maps), so an agent understands these are project templates. It differentiates from siblings by tying the output to studio_create_project, though it never states an explicit verb like 'list' or 'returns' for the tool itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit downstream usage: 'Pass one to studio_create_project as template { id, values }', which tells the agent the workflow this tool feeds. It lacks any when-not guidance or differentiation from nearby list tools (studio_list_examples, studio_list_capabilities), so the routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asks an open Studio browser to render and download the video locally.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | ||
| aspect | No | ||
| format | No | ||
| locale | No | en | |
| timeMs | No | ||
| quality | No | ||
| projectId | Yes | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it non-read-only and non-destructive, so the safety profile is covered. The description usefully adds that rendering happens client-side in an already-open browser and the file is downloaded locally, but omits whether the call is asynchronous, whether a job handle must be polled via studio_get_job, and any rate or session requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence, front-loaded with the key distinction (local browser render/download). It wastes no words, though brevity here comes at the cost of completeness rather than by design.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotation-derived detail, a single sentence is inadequate. Missing are the browser-session precondition, async/polling behavior, and any hint about the six optional export settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, and the description supplies no parameter meaning at all, not even for the required projectId/agentToken. The enums and const constraints for fps, format, aspect, and quality are self-explanatory, but the optional settings (timeMs, locale, quality) carry no explanation in either place.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (asks/renders/downloads) and resource (the video) plus the medium (locally via an open Studio browser), which separates it from server-side export tools. It does not name or contrast with the closest siblings studio_export_json or studio_request_preview, so it falls short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'an open Studio browser' hints at a precondition, but the description gives no explicit when-to-use guidance, no mention of when to prefer studio_request_preview or studio_export_json, and no sequencing advice. An agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asks an open Studio browser to render a frame locally.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | ||
| aspect | No | ||
| format | No | ||
| locale | No | en | |
| timeMs | No | ||
| quality | No | ||
| projectId | Yes | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is already covered. The description usefully adds the precondition that an open Studio browser must be present, but says nothing about whether the call blocks until the frame is rendered, whether it is queued/async, or what comes back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It is efficient, though its brevity is partly under-specification rather than disciplined concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, non-read-only tool with no output schema and no schema descriptions, the description is far too thin. It omits authentication, the render configuration surface, and any indication of the return value or how the local preview is retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, and the description compensates for none of them. It never mentions the required projectId, the required agentToken (an authentication credential), or what fps/aspect/format/quality/timeMs control, leaving every parameter undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ("render a frame locally") plus the mechanism ("asks an open Studio browser"), which is more than a tautology. It does not distinguish itself from the sibling studio_request_export, and "a frame" sits oddly against the mp4/webm/fps/quality parameters that suggest video rendering. Still, an agent can broadly tell what this does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as studio_request_export. The only hint of context is the implied precondition that a Studio browser must be open, which is stated as mechanism rather than as a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks entity, track, clip, timing, and reference integrity.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description usefully adds that the validation scope covers entities, tracks, clips, timing and references. It does not disclose whether issues are merely reported or auto-fixed, how failures are surfaced, or any rate/permission behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though the terseness leaves required content unstated elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a readOnlyHint annotation, the description should explain what a validation run returns (issue list? severity? does it persist a job?), how to obtain agentToken, and how it relates to studio_get_job or studio_apply_actions. None of that is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are two required parameters. The description says nothing about projectId or agentToken (format, where the token comes from, required scope), so it fails to compensate for the schema gap beyond the self-evident parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Checks") and resource (project) and enumerates the five integrity dimensions checked, so the agent knows this is an inspection/validation operation rather than a mutation. It does not explicitly contrast itself with siblings like studio_get_project_summary or studio_request_preview, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites or ordering relative to studio_apply_actions or studio_request_export, and no statement of when validation should be skipped. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
studio_apply_actionsstudio_create_projectstudio_describe_capabilitiesstudio_export_jsonstudio_find_placesstudio_get_guidestudio_get_jobstudio_get_project_summarystudio_join_projectstudio_list_capabilitiesstudio_list_examplesstudio_list_templatesstudio_request_exportstudio_request_previewstudio_validate_projectTurn words, images, and audio into an animated video with MP4 export.
Ask in plain English, get a rendered, shareable map from live public data. 24 geospatial tools.
Creates 2D motion-graphics videos: kinetic typography, charts, formulas, narrated explainers.
Generate styled PNG/SVG map images of any location with 11 customizable color themes.
Add one secure layer between your agents and this server.
