01Safety
0.0 / 30
What changed in the harness
Selection accuracy 95%, destructive-action safety rate 0% (baseline only -- no rewrite pass applied).
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
27.9 / 30
03Economics
17.5 / 20
04Discoverability
11.6 / 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.
0 defects 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 |
|---|---|---|
| No description defects were flagged in this assessment. | ||
Selection evidence
Confusable tool pairs.
7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
workflow_create |
workflow_activate |
medium | A task like 'deploy my workflow' or 'get my workflow into production/go live' is ambiguous: if the workflow doesn't exist the agent must call create (which leaves it inactive per the description), but if it exists it must call activate. The phrase 'set up my workflow so it runs' could cause an agent to pick only one member when both (or the other) were needed. |
workflow_list |
workflow_get |
medium | 'Show me / look at my workflow' is ambiguous: list returns summary fields (id, name, active, nodeCount) and accepts a name filter, while get returns the full JSON but requires an id and has no name filter. An agent asked for a workflow's full details might call get with a name (invalid input) or call list when the full nodes/connections payload was expected. |
execution_explain |
execution_timeline |
medium | Both tools ingest an execution payload and describe what happened in a run; a vague task like 'analyze/diagnose this execution and walk me through it' is ambiguous between explain (why: dropped items, errors, expressions) and timeline (when: per-node timing). Only a task explicitly asking for timing or for root-cause reasons disambiguates them. |
workflow_list |
execution_list |
low | Both are list-type queries on a live instance, so a vague 'show me recent activity / what's happening on my n8n' could be resolved against workflows or executions. Entity nouns ('workflows' vs 'executions') mostly disambiguate, but generic 'recent activity' phrasing is genuinely ambiguous. |
execution_explain |
execution_list |
low | 'Explain/diagnose my last failed run' could make an agent call execution_list to fetch execution bodies, or call execution_explain which requires an execution payload the agent may not yet have. The two are complementary (list fetches, explain analyzes), so a single-step interpretation can pick the wrong member. |
workflow_lint |
workflow_diff |
low | Both take workflow JSON and analyze it, so 'review/audit/check this workflow' could be satisfied by lint (errors/warnings) or diff (before/after comparison). They diverge only when the task explicitly asks for validity checks vs. comparing two versions, which is not always named by the user. |
workflow_diff |
workflow_get |
low | 'Compare my local workflow to the deployed/server version' requires fetching the server copy (get) and then comparing (diff); an agent may pick only one member — calling get when a diff was wanted, or diff without having the deployed JSON. The descriptions hint at pairing them, but a compressed task can lead to choosing the wrong single tool. |
Compare the field