Skip to main content
Glama

GroundTruth — subsurface scan QA & trade estimating

by ai.gtfi

read_scan

Get an independent AI second opinion on a subsurface scan before anyone cores or digs. Send a public image URL of a GPR scan, a marked-up concrete slab photo, a utility-locate markup, a concrete radiograph, or a CCTV pipe frame. TWO different AI models read it independently — the second is prompted to refute the first — and you get back every located target with its hazard class (do-not-core / rebar / verify / clear), plus a QA flag when the two reads disagree. Advisory only: a certified technician must review and sign off before any cutting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
image_urlYesPublic https URL to a JPEG or PNG of the scan or the marked-up surface. Max 8 MB.
disciplineNoOne of: gpr (concrete scanning), locate (utility locating), pipe (CCTV sewer), xray (concrete radiograph), milestone (FL SB 4-D condo concrete). Defaults to gpr.
field_noteNoOptional: what the technician said on site. Used as context for names and depths only — it can never clear a hazard the image shows.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description fully explains the dual-model reading process, QA flag for disagreements, and that results are advisory. No contradictions exist.

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 two sentences, front-loading the purpose. Every sentence adds value, though the first sentence is somewhat lengthy and could be slightly more structured.

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?

Despite no output schema or annotations, the description covers purpose, inputs, process, output highlights (targets, hazard class, QA flag), and limitations (advisory). Sufficient for a tool with 3 simple params.

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?

The input schema provides 100% coverage with descriptions for all three parameters. The tool description adds no further parameter details, so baseline of 3 is appropriate.

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 provides an AI second opinion on subsurface scans, listing specific image types. It distinguishes itself from sibling tools like draft_estimate and get_pricing by focusing on scan analysis.

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 explicitly advises use 'before anyone cores or digs' and notes the advisory nature requiring technician sign-off. However, no explicit when-not-to-use or alternatives are provided, though siblings are unrelated.

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

All GroundTruth — subsurface scan QA & trade estimating toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: draft_estimate for generating bids, get_pricing for plan costs, and read_scan for analyzing subsurface scans. There is no overlap or ambiguity.

Naming Consistency5/5

All tools use lowercase snake_case with a consistent verb_noun pattern (draft_estimate, get_pricing, read_scan), making them predictable and easy to understand.

Tool Count4/5

With 3 tools covering two related domains (estimating and scanning), the count is slightly minimal but still appropriate for a focused service. Each tool is justified and not excessive.

Completeness4/5

The tools cover the core advertised features: pricing info, estimate generation, and scan analysis. Minor gaps like estimate management or scan history exist but do not hinder primary use cases.

Resources