Skip to main content
Glama

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Snap rough points to the picture

snap
Read-onlyIdempotent

Move rough coordinates onto the image: a quad's corners onto the sign's real corners (its sides fitted to the edges; edgeOf picks a bordered sign's outer or inner edge), a box onto the object's edges, a point onto the nearest corner. Each point comes back with its move (delta), its confidence and whether it moved. Nothing moves farther than 75% of radius or on evidence under 0.6 confidence: that point stays where it was (moved false) and the answer says why. Use it on corners read off a preview before track_plane or a , so a seed is exact rather than a few pixels off. Example: snap({geometry:{type:"quad", space:"preview", previewId:"pv_7q2kxm3a9d", points:[[402,188],[611,201],[604,330],[398,322]], assetId:null, clipId:null, trackId:null, tile:null, time:null}, assetId:"vid_street", clipId:null, at:{seconds:null, atSpace:null}, radius:null, edgeOf:null, to:null, detail:null}). Answers in the geometry's own space and in source, film and film_norm, prose first and one json block after. Free and fast.

Input Schema

NameRequiredDescriptionDefault
atYesWhen to read the frame.
toYesauto (null): a quad's or box's sides fit to edges and its corners where they cross, a line to the nearest edge along it, a point to the nearest strong corner or else edge. corners: every point to the nearest corner. edges: points to the nearest edge.
clipIdYesThe clip whose frame to read and whose transforms map the answer to the film. Else null.
detailYesHow much the answer says: brief is one line per result with its ids; normal (null) adds the transform; full adds every matrix of the chain.
edgeOfYesWhich edge of a bordered surface (a sign with a frame) a quad's or a box's sides sit on: outer (the frame's outside), inner (the panel inside it) or auto (null): of the two, the one with clearly more support along the sides, the same kind on every side, else the outer edge. snap and detect_geometry use the same rule, so a quad detect_geometry found does not move when snapped.
radiusYesHow far to look for evidence, in source pixels, up to 64. A point moves at most 75% of it; a point whose evidence is farther, or under 0.6 confidence, stays put and is named. null: 12.
assetIdYesThe asset whose frame to read. null: the geometry's assetId, or the asset of clipId.
geometryYesThe rough point, box, quad, line or polygon to snap, in any space (a quad read off a preview: space preview and its previewId).
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / edgeOf / description
      Previous value: -"Which edge of a bordered surface (a sign with a frame) a quad's or a box's sides sit on: outer (the frame's outside), inner (the panel inside it) or auto (null): the outer edge when a border shows on all four sides, else the edge nearest each side. snap and detect_geometry use the same rule, so a quad detect_geometry found does not move when snapped."New value: +"Which edge of a bordered surface (a sign with a frame) a quad's or a box's sides sit on: outer (the frame's outside), inner (the panel inside it) or auto (null): of the two, the one with clearly more support along the sides, the same kind on every side, else the outer edge. snap and detect_geometry use the same rule, so a quad detect_geometry found does not move when snapped."
  2. Changed3 schema fields changed
    • addedInput schema / properties / edgeOf
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "outer",
+        "inner",
+        "auto"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Which edge of a bordered surface (a sign with a frame) a quad's or a box's sides sit on: outer (the frame's outside), inner (the panel inside it) or auto (null): the outer edge when a border shows on all four sides, else the edge nearest each side. snap and detect_geometry use the same rule, so a quad detect_geometry found does not move when snapped."
+}
    • changedInput schema / properties / radius / description
      Previous value: -"How far a point may move, in source pixels, up to 64. A point whose evidence is farther stays put and is named. null: 12."New value: +"How far to look for evidence, in source pixels, up to 64. A point moves at most 75% of it; a point whose evidence is farther, or under 0.6 confidence, stays put and is named. null: 12."
    • changedInput schema / required
      Previous value: -[
-  "geometry",
-  "assetId",
-  "clipId",
-  "at",
-  "radius",
-  "to",
-  "detail",
-  "projectId"
-]New value: +[
+  "geometry",
+  "assetId",
+  "clipId",
+  "at",
+  "radius",
+  "edgeOf",
+  "to",
+  "detail",
+  "projectId"
+]
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial operational detail: per-point delta, confidence, moved status, the 75%-of-radius limit, the 0.6 confidence floor, and why a point may stay put. It also discloses the answer spaces and prose-plus-JSON response shape.

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 purpose and behavior are front-loaded, and the text is generally efficient. The inline example is quite long and includes several null required fields that are already covered by the schema, which keeps it from being maximally concise.

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 complex nine-parameter tool with nested geometry and no output schema, the description is complete enough to call correctly. It explains the return fields, the coordinate spaces, and the prose-first JSON-block response, while the schema handles parameter-level details.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all nine parameters in depth. The description reinforces radius, edgeOf, and the snapping behavior, but it does not add parameter semantics beyond what the schema already provides.

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: moving rough coordinates onto the image. It explicitly covers quad corners, box edges, and point-to-corner behavior, and names track_plane and a pin as downstream use cases, making its role distinguishable from siblings.

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 clear usage context: use it on corners read off a preview before track_plane or a pin so a seed is exact. It does not explicitly state when not to use it or name an alternative like detect_geometry, so it falls short of full when/when-not guidance.

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

All Vidova toolsInspect
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