01Safety
0.0 / 30
What changed in the harness
Selection accuracy 83→76, token cost up 2%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
25.3 / 30
03Economics
19.8 / 20
04Discoverability
12.3 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
1 defect found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
convert_text |
params_unexplained no_return_description |
Convert the text passed in the `text` parameter — a printed drawing callout or a short string containing several callouts — from the unit system given by `from` to the opposite one, preserving notation: "Ø30 H7" → "Ø1.1811 H7", "84±0.1" → "3.3071±0.0039", "R13" → "R0.5118", "M8" → "5/16-18 UNC", "1/4-20 UNC" → "M6". Angle values (°) are left unchanged. `category` controls how bare numbers are read: the default `dimension` treats them as lengths, `surface` as Ra roughness. `assume_lengths=true` additionally converts every remaining number as a length (for tolerance-table rows like "bis 30"). Returns the converted text as a string, with the original notation preserved. |
Selection evidence
Confusable tool pairs.
4 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
convert_value |
convert_text |
high | Both convert metric↔imperial and accept the same logical inputs — e.g. 'M8'→'5/16-18 UNC' (kind=thread vs callout text) and '84±0.1' (kind=tolerance_deviation vs callout notation). A task like 'convert M8 to imperial' or 'convert this tolerance to inches' satisfies both schemas (convert_value needs kind/from; convert_text needs text/from), so an agent could plausibly pick the wrong one. |
convert_text |
convert_drawing_pdf |
medium | Both convert drawing callouts between unit systems; convert_text converts a pasted callout or short text while convert_drawing_pdf stamps converted values onto an entire PDF. A task like 'convert the callout on the drawing to imperial' with no explicit file path or pasted text doesn't reveal whether the output should be converted text or a rewritten PDF, making either choice defensible. |
extract_drawing_text |
convert_drawing_pdf |
medium | Both act on the same technical-drawing PDF and explicitly reference each other: extract produces tokens/classifications meant for conversion, convert stamps converted values back over the callouts. A task like 'convert the text in this drawing PDF' or 'extract the converted text' is ambiguous — an agent may call extract and stop, or invoke convert when only a token readout was wanted. |
convert_text |
extract_drawing_text |
low | Both descriptions center on 'printed drawing text': convert_text rewrites a drawing callout between units, while extract returns raw tokens without converting. A task like 'extract the printed callout text from the drawing' could be misread as a conversion request because convert_text handles the same notation, though the read-vs-convert verb usually disambiguates. |
Compare the field