Skip to main content
Glama

smartscale

by io.github.jdhart81
OverviewDiscussionsAdmin

Server Details

Deterministic CR80 pixel-geometry scaler. Callers supply the card and object pixel geometry; this MC

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
jdhart81/viridis-agent-fleet
GitHub Stars
0
Server Listing
viridis-agent-fleet

TDQS

B3.2/5.0

Scored across 4 tools

Disambiguation4/5

The primary tool, scale_objects_from_credit_card, is distinct from utility tools (health, describe). However, credit_card_photo_instructions overlaps somewhat in domain with the main scaling tool, as both relate to credit card imagery, though one is for capturing and the other for scaling. Overall, the boundaries are clear enough.

Naming Consistency3/5

Two tools use verb_noun patterns (scale_objects_from_credit_card, credit_card_photo_instructions), but 'describe' and 'health' are single-word verbs, which deviates from the pattern. The naming is readable but not fully consistent.

Tool Count3/5

With only 4 tools, the server feels slightly thin for a service that appears to be an image scaling API. However, the core function is present, and the utility tools are minimal. It is borderline acceptable, but could benefit from more modular tools.

Completeness2/5

The main scaling operation exists, but there is no way to retrieve past scaling results, update parameters, or delete records. The absence of any list/get/delete operations for scaled objects creates a dead end for agents that need to manage or verify prior work.

Available Tools

4 tools
credit_card_photo_instructionsCInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
measurement_goalNo
objects_to_measureNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
fieldNo
resultNo
statusYes
messageNo
timestampNo
constraintNo
error_typeNo

TDQS

C2.9/5.0
Behavior3/5

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

The description discloses that the image is not sent to SmartScale, only numeric pixel geometry is received, which is key behavioral info. However, with no annotations, additional details like idempotency or side effects are missing.

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?

The description is extremely concise with two sentences, no fluff, and the key purpose is front-loaded.

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?

While the output schema exists, the description fails to contextualize the two input parameters, which are crucial for the agent to use the tool correctly. The overall guidance is incomplete for a tool with undocumented parameters.

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?

The description does not explain the parameters 'measurement_goal' and 'objects_to_measure' at all, leaving their purpose and values ambiguous. With 0% schema description coverage, this is a significant gap.

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 clearly states the tool returns safe capture guidance for CR80 pixel picking, which is a specific action and distinguishes it from siblings like 'scale_objects_from_credit_card' which processes images. However, the term 'CR80 pixel picking' may be too technical and not immediately clear.

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 description does not provide any explicit guidance on when to use this tool versus alternatives. It implies usage for obtaining capture guidance but fails to mention prerequisites or when not to use it.

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

describeAInspect

Return SmartScale capabilities and input contract.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
fieldNo
resultNo
statusYes
messageNo
timestampNo
constraintNo
error_typeNo

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description must convey behavioral traits. 'Return' implies a read-only operation, but no details about side effects or requirements are given. The simplicity of the tool (0 params) partially justifies the minimal description, but it could be more explicit.

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?

The description is a single sentence that directly states the tool's purpose with no unnecessary words.

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

Completeness4/5

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

Given the tool has no parameters and an output schema, the description is nearly complete. It clearly states what is returned, but could briefly mention that it is a read-only introspection tool.

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

Parameters4/5

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

The input schema has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed.

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 clearly states the tool returns 'SmartScale capabilities and input contract', using a specific verb and resource. It distinguishes from sibling tools like `credit_card_photo_instructions` and `scale_objects_from_credit_card`, which have different purposes.

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 description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites or typical use cases, which is particularly needed given the sibling tools exist.

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

healthAInspect

Return SmartScale health status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
fieldNo
resultNo
statusYes
messageNo
timestampNo
constraintNo
error_typeNo

TDQS

A3.6/5.0
Behavior2/5

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

Without annotations, the description carries full burden of behavioral disclosure. It only states 'Return health status'—no mention of side effects, speed, or any traits beyond the basic operation. This adds little value over the tool name.

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?

A single sentence that is perfectly concise and front-loaded. Every word is earned; no verbosity.

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

Completeness4/5

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

For a simple, parameterless health check with an existing output schema, the description is nearly complete. It could briefly note the purpose (e.g., availability check) but is adequate as is.

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

Parameters4/5

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

There are no parameters, so schema coverage is 100%. With 0 parameters, the baseline is 4, and the description correctly does not attempt to describe nonexistent parameters.

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 uses a specific verb ('Return') and resource ('SmartScale health status'), making the tool's purpose clear. It distinguishes well from sibling tools like 'describe' or 'credit_card_photo_instructions' which operate on different domains.

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?

No guidance is given on when to use this tool versus alternatives. For a simple health check, the context is implied but not explicitly stated, leaving the agent without decision support.

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

scale_objects_from_credit_cardAInspect

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).
ParametersJSON Schema
NameRequiredDescriptionDefault
objectsYes
image_idYes
request_idNo
payment_refNo
credit_card_pixel_widthYes
credit_card_pixel_heightNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataNo
errorNo
fieldNo
resultNo
statusYes
messageNo
timestampNo
constraintNo
error_typeNo

TDQS

A4.1/5.0
Behavior4/5

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

The description reveals key behaviors: no image upload, caller-supplied dimensions, optional distortion check, payment ref consumed by gateway, and idempotency key. With no annotations, this provides adequate behavioral context, though it does not mention error handling or 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 front-loaded with a one-sentence summary followed by a structured Args section. It is informative without being overly verbose, though the Args list could be slightly trimmed without losing clarity.

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?

Given the tool's complexity (6 parameters, 3 required) and the existence of an output schema, the description covers all necessary aspects: parameter explanations, domain-specific details (CR80, distortion check), and optional fields. It is complete for an AI agent to use correctly.

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

Parameters5/5

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

With schema description coverage at 0%, the description fully explains each parameter: image_id is a source identifier, credit_card_pixel_width is the card's pixel width, objects need pixel_width/height, etc. This adds significant meaning beyond the raw schema.

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 clearly states the tool's action ('Scale object pixel dimensions') and the reference method ('CR80 credit card'). It is specific and distinct from sibling tools, which are about instructions, description, and health.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., if a different scaling method is needed). The description lacks when-not-to-use or context for choosing this over sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedcredit_card_photo_instructions12 fields changed
      • 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"
    • Changeddescribe12 fields changed
      • 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: -"describeOutput"New value: +"FleetToolResult"
    • Changedhealth12 fields changed
      • 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: -"healthOutput"New value: +"FleetToolResult"
    • Changedscale_objects_from_credit_card14 fields changed
      • addedInput schema / properties / payment_ref
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Payment Ref"
+}
      • addedInput schema / properties / request_id
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Request Id"
+}
      • 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: -"scale_objects_from_credit_cardOutput"New value: +"FleetToolResult"
  2. 4 tool updates
    • First observedcredit_card_photo_instructions
    • First observeddescribe
    • First observedhealth
    • First observedscale_objects_from_credit_card

Related MCP Connectors

Related MCP Servers

  • vector-mirror

    c64dos-png
    A
    license
    Not graded
    quality
    C
    maintenance
    A deterministic SVG perception tool for LLM agents that renders SVGs in a real browser to measure geometry, colors, and spatial constraints, reporting results in grid grammar and W3C color names without guessing.
    18 npm
    MIT
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