A
license-
qualityA
maintenanceLLM-native image optimization middleware & MCP server. Reduces vision model token consumption by preprocessing images into tile-boundary-aligned, padding-free formats.
Last updated
270
2
Elastic 2.0
smartscale
Server Details
Deterministic CR80 pixel-geometry scaler. Callers supply the card and object pixel geometry; this MC
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jdhart81/viridis-agent-fleet
- GitHub Stars
- 0
- Server Listing
- viridis-agent-fleet
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A3.9/5.0
Tool DescriptionsA
Average 3.6/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: instructions for photo capture, description of capabilities, health check, and object scaling. No overlap or ambiguity.
Naming Consistency5/5
All tool names use consistent snake_case pattern. While some are multi-word and others single-word, they follow the same convention without mixing styles.
Tool Count5/5
With only 4 tools, the server is well-scoped for its purpose of providing credit card-based measurement. Each tool is essential and there are no superfluous ones.
Completeness4/5
The server covers the core workflow: instructions, scaling, health, and capabilities. It lacks a tool for uploading images or retrieving historical results, but these may be handled externally.
Available Tools
4 toolscredit_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
| Name | Required | Description | Default |
|---|---|---|---|
| measurement_goal | No | ||
| objects_to_measure | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Tool Definition Quality
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Tool Definition Quality
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Tool Definition Quality
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
| 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 |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| error | No | |
| field | No | |
| result | No | |
| status | Yes | |
| message | No | |
| timestamp | No | |
| constraint | No | |
| error_type | No |
Tool Definition Quality
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityCmaintenanceUnified MCP server for graphics manipulation with multiple backends.Last updated1BSD 3-Clause
- Alicense-qualityBmaintenanceMCP server that lets AI clients drive the dfxm-geo dark-field X-ray microscopy forward model, enabling config validation, reflection enumeration, and preview-scale simulations.Last updatedMIT
- Alicense-qualityCmaintenanceReconstructs a reference image as procedural 3D geometry through a staged pipeline, generating a Three.js model, preview, comparison, and glTF export.Last updatedMIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.