Skip to main content
Glama
yaaif

@yaaif/platform-mcp

by yaaif

yaaif_agent_spec_sync_apply

Apply a reviewed preview to sync a scenario with bound catalog objects: push changes to objects or adopt live catalog drift into the scenario.

Instructions

Apply a reviewed preview: to_objects writes the Scenario onto bound catalog objects; from_objects adopts live catalog drift into the Scenario.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spec_idYes
directionYes
preview_idYes
expected_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.5

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are present, so the description carries the full burden. It does disclose the two concrete behaviors: to_objects writes the Scenario onto bound catalog objects, and from_objects adopts live drift into the Scenario. However, it omits side-effect/irreversibility context, expected_version conflict behavior, and what happens if the preview is stale.

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?

One compact sentence, front-loaded with the action, then a clean semicolon-separated mapping of the two directions. Every clause earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four required parameters, no output schema, and no annotations, this is under-specified for an apply/commit tool. The agent is not told how expected_version controls the apply, how to obtain a reviewed preview_id, or how this fits with sync_preview and the direct sync operations.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only clarifies the direction enum values. spec_id and preview_id are left to naming convention, and expected_version's role is completely unexplained despite being a required integer with exclusiveMinimum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete action ('Apply a reviewed preview') and a resource, and the semicolon clause explains both directions (to_objects/from_objects), so the agent knows what the tool does. It doesn't explicitly distinguish this from sibling sync_from_objects/sync_to_objects tools beyond the preview/apply framing.

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

Usage Guidelines3/5

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

'Apply a reviewed preview' clearly implies a prerequisite: the preview must already be reviewed before this tool is called. However, it does not name alternatives or explicitly state when NOT to use this tool versus sibling tools like yaaif_agent_spec_sync_preview or the direct sync tools.

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

Deploy Server

Other Tools