Deterministic CR80 pixel-geometry scaler. Callers supply the card and object pixel geometry; this MC
Scored across 4 tools
The four tools have clearly distinct roles: scaling, capture guidance, capability/contract description, and health reporting. An agent can easily determine which tool to use for each need.
Names are readable snake_case, but the conventions are mixed: two single-word utilities (describe, health), a noun-phrase instruction tool, and a verb_noun main operation. There is no consistent verb_noun pattern across the set.
Four tools is well-scoped for a narrow scaling utility: one core operation, one capture-guidance helper, and two service metadata/health tools. Nothing is excessive or clearly missing due to the count.
The surface covers the core scaling operation, capture guidance, contract discovery, and health status. For a numeric-geometry-only scaling service this is essentially complete, with only minor gaps such as no standalone input-validation or card-type metadata tool.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| measurement_goal | No | ||
| objects_to_measure | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds genuinely useful data-handling context the annotations do not convey: the image never leaves the caller and only numeric pixel geometry reaches SmartScale. That is real value. However, it says nothing about the tension with readOnlyHint=false — the description reads like a pure guidance-returning call, so an agent cannot tell whether anything is persisted.
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 padding and the privacy constraint front-loaded is good structure, but the density of undefined jargon ('CR80 pixel picking') means the brevity comes at the cost of comprehension rather than from efficiency.
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?
An output schema exists, so return values need not be explained, and the caller/image separation is covered. What is missing is any account of the two input parameters and any disambiguation from siblings, which for a tool in a four-tool family leaves a real 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?
Schema description coverage is 0% for measurement_goal and objects_to_measure, and the description mentions neither. Neither the schema nor the description explains what values measurement_goal accepts or what form objects_to_measure entries take, so the agent must guess before it can call the 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?
It states a verb and a resource ('return safe capture guidance') but the resource is framed in compressed jargon ('upstream CR80 pixel picking') that only insiders will decode; CR80 is never expanded to 'credit-card-sized reference object'. It also gives no hint of how it differs from the sibling scale_objects_from_credit_card.
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 statement of when to call this versus scale_objects_from_credit_card or describe, and no prerequisites. The phrase 'upstream' gestures at a workflow position but leaves the agent to infer the trigger condition entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return SmartScale capabilities and input contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the description needn't restate safety. It adds only that the call surfaces the input contract, with no mention of response shape, versioning, or caching behavior; the annotations lower the bar and the description meets it only minimally.
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 no filler. It is front-loaded with the key information, though 'capabilities and input contract' is compressed to the point of vagueness rather than economy.
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?
An output schema exists, so return values needn't be explained, and a zero-param read-only introspection tool is inherently simple. Still, the description never positions this tool relative to 'health' or explains what an agent should do with the returned contract, leaving a moderate gap for a discovery-oriented 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?
The tool takes zero parameters, which is the baseline-4 case per the rubric. The description correctly implies a no-argument introspection call, so there is nothing further the schema could be compensating for.
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 verb ('Return') and an object ('SmartScale capabilities and input contract'), so the general intent is legible. However, 'capabilities and input contract' is abstract shorthand that doesn't tell an agent concretely what comes back, and there is no differentiation from the sibling 'health' tool, which could plausibly be confused with a capabilities check.
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 statement of when to call this versus 'health' or the other siblings, and no mention of calling it first to discover the contract. The agent must infer usage entirely from the name and the one-line summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return SmartScale health status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is known. The description adds only the basic purpose and no further behavioral context, such as what health statuses mean or whether the call has side effects or latency implications.
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 a single concise sentence that front-loads the verb and resource. It contains no redundant or wasted wording.
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 simple zero-parameter health-check tool with an output schema and full annotations, the description is nearly complete. It could clarify what 'health status' entails, but the output schema likely covers return values.
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 has zero parameters, so there are no parameter semantics to document. The baseline score for a zero-parameter tool is 4, and the description does not need to compensate for any schema gaps.
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 uses a specific verb ('Return') and resource ('SmartScale health status'), making the tool's purpose clear. It does not explicitly distinguish itself from siblings like 'describe', but the health-check framing is sufficiently distinct.
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 no guidance on when to use this tool versus alternatives such as 'describe' or the scale/credit-card tools. A health check is implied, but no explicit context, exclusions, or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale object pixel dimensions using a standard CR80 credit card reference.
Args:
image_id: Caller-defined source identifier; no image is uploaded.
credit_card_pixel_width: Caller-supplied pixel width of a CR80-size card.
objects: Objects to scale. Each object needs pixel_width and pixel_height;
label, pixel_area, pixel_perimeter, and input confidence are optional.
credit_card_pixel_height: Optional caller-supplied height for distortion check.
payment_ref: Optional paid escrow reference consumed by the gateway.
request_id: Optional retry-safe idempotency key (maximum 128 characters).
| Name | Required | Description | Default |
|---|---|---|---|
| objects | Yes | ||
| image_id | Yes | ||
| request_id | No | ||
| payment_ref | No | ||
| credit_card_pixel_width | Yes | ||
| credit_card_pixel_height | No |
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readonly, non-destructive, closed-world behavior. The description adds meaningful context beyond that: no image is uploaded, credit_card_pixel_height is used for a distortion check, payment_ref is consumed as paid escrow, and request_id supports retry-safe idempotency. It does not fully clarify the mutation or return side effects, but the output schema covers the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation and then uses a structured Args list efficiently. It avoids unnecessary prose, though the docstring style is slightly less immediately scannable than concise prose.
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 the output schema exists and annotations cover the safety profile, the description is largely complete. It explains all inputs and notable behaviors such as escrow consumption and distortion checking, but lacks explicit usage guidance and alternative-tool routing.
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, and it does. It documents all six parameters, including nested object requirements (pixel_width and pixel_height) and optional object fields, plus limits and purposes for request_id and payment_ref.
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 first sentence states a specific verb and resource: scaling object pixel dimensions using a CR80 credit card reference. This is clear enough for an agent to understand the tool's core function, though it does not explicitly distinguish itself from sibling tools or explain what is produced.
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 does not state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. The Args section implies prerequisites such as object pixel dimensions and a card pixel width, but usage context is left to inference.
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.
credit_card_photo_instructions12 fields changedOutput schema / properties / constraintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Constraint"
+}Output schema / properties / dataAdded value: +{
+ "default": null,
+ "title": "Data"
+}Output schema / properties / errorAdded value: +{
+ "default": null,
+ "title": "Error"
+}Output schema / properties / error_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error Type"
+}Output schema / properties / fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field"
+}Output schema / properties / messageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Message"
+}Output schema / properties / result / defaultAdded value: +nullOutput schema / properties / result / typeRemoved value: -"string"Output schema / properties / statusAdded value: +{
+ "title": "Status",
+ "type": "string"
+}Output schema / properties / timestampAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Timestamp"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "status"
+]Output schema / titlePrevious value: -"credit_card_photo_instructionsOutput"New value: +"FleetToolResult"describe12 fields changedOutput schema / properties / constraintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Constraint"
+}Output schema / properties / dataAdded value: +{
+ "default": null,
+ "title": "Data"
+}Output schema / properties / errorAdded value: +{
+ "default": null,
+ "title": "Error"
+}Output schema / properties / error_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error Type"
+}Output schema / properties / fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field"
+}Output schema / properties / messageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Message"
+}Output schema / properties / result / defaultAdded value: +nullOutput schema / properties / result / typeRemoved value: -"string"Output schema / properties / statusAdded value: +{
+ "title": "Status",
+ "type": "string"
+}Output schema / properties / timestampAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Timestamp"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "status"
+]Output schema / titlePrevious value: -"describeOutput"New value: +"FleetToolResult"health12 fields changedOutput schema / properties / constraintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Constraint"
+}Output schema / properties / dataAdded value: +{
+ "default": null,
+ "title": "Data"
+}Output schema / properties / errorAdded value: +{
+ "default": null,
+ "title": "Error"
+}Output schema / properties / error_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error Type"
+}Output schema / properties / fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field"
+}Output schema / properties / messageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Message"
+}Output schema / properties / result / defaultAdded value: +nullOutput schema / properties / result / typeRemoved value: -"string"Output schema / properties / statusAdded value: +{
+ "title": "Status",
+ "type": "string"
+}Output schema / properties / timestampAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Timestamp"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "status"
+]Output schema / titlePrevious value: -"healthOutput"New value: +"FleetToolResult"scale_objects_from_credit_card14 fields changedInput schema / properties / payment_refAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Payment Ref"
+}Input schema / properties / request_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Request Id"
+}Output schema / properties / constraintAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Constraint"
+}Output schema / properties / dataAdded value: +{
+ "default": null,
+ "title": "Data"
+}Output schema / properties / errorAdded value: +{
+ "default": null,
+ "title": "Error"
+}Output schema / properties / error_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error Type"
+}Output schema / properties / fieldAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field"
+}Output schema / properties / messageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Message"
+}Output schema / properties / result / defaultAdded value: +nullOutput schema / properties / result / typeRemoved value: -"string"Output schema / properties / statusAdded value: +{
+ "title": "Status",
+ "type": "string"
+}Output schema / properties / timestampAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Timestamp"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "status"
+]Output schema / titlePrevious value: -"scale_objects_from_credit_cardOutput"New value: +"FleetToolResult"credit_card_photo_instructionsdescribehealthscale_objects_from_credit_cardMeasure card centering and check PSA, BGS, CGC and SGC centering ceilings and standards.
Turn images into pixel art, extract and remap palettes, and upscale sprites without blur.
Remote MCP server for deterministic educational practice-assessment score conversions.
Add one secure layer between your agents and this server.