smartscale

Credit card photo instructions

credit_card_photo_instructions

Return safe capture guidance for upstream CR80 pixel picking.

The image stays with the caller or upstream vision system; SmartScale only receives numeric pixel geometry.

Input Schema

Name	Required	Description	Default
`measurement_goal`	No
`objects_to_measure`	No

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`field`	No
`result`	No
`status`	Yes
`message`	No
`timestamp`	No
`constraint`	No
`error_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedJul 27, 2026

addedOutput schema / properties / constraint

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Constraint"
+}

addedOutput schema / properties / data

Added value: +{
+  "default": null,
+  "title": "Data"
+}

addedOutput schema / properties / error

Added value: +{
+  "default": null,
+  "title": "Error"
+}

addedOutput schema / properties / error_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Error Type"
+}

addedOutput schema / properties / field

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Field"
+}

addedOutput schema / properties / message

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Message"
+}

addedOutput schema / properties / result / default
```
Added value: +null
```
removedOutput schema / properties / result / type
```
Removed value: -"string"
```

addedOutput schema / properties / status

Added value: +{
+  "title": "Status",
+  "type": "string"
+}

addedOutput schema / properties / timestamp

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Timestamp"
+}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "status"
+]

changedOutput schema / title

Previous value: -"credit_card_photo_instructionsOutput"New value: +"FleetToolResult"

First observedJul 10, 2026

TDQS

C2.7/5.0

Behavior3/5

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

The description adds a useful privacy and data-flow guarantee: the image stays with the caller or upstream vision system, and SmartScale only receives numeric pixel geometry. However, it does not reconcile this passive guidance framing with the annotations readOnlyHint=false and idempotentHint=false, nor does it explain any side effects.

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 short and front-loads the main purpose before adding the data-handling note. Some jargon such as 'CR80 pixel picking' is unexplained, but there is little wasted wording.

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?

The tool is simple and has an output schema, so return values need not be described. Still, the description leaves the two input parameters completely unaddressed and provides no usage guidance, which is a notable gap for a tool with 0% schema description coverage.

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

Parameters1/5

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

Schema description coverage is 0% and the description never mentions measurement_goal or objects_to_measure. For a tool with two optional parameters, the description provides no meaning, format, or expected values beyond the raw schema.

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?

The description gives a specific verb and resource: it returns 'safe capture guidance' for upstream CR80 pixel picking. It also implies a boundary with the actual scaling tool by saying the image remains upstream and only numeric pixel geometry is received, though it does not name the sibling tool explicitly.

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

Usage Guidelines2/5

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

The phrase 'for upstream CR80 pixel picking' gives context but does not say when to use this tool instead of scale_objects_from_credit_card, nor does it state prerequisites or when not to use it. An agent must infer the usage scenario entirely.

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

All smartscale 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.