01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 3%, 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
27.4 / 30
03Economics
7.9 / 20
04Discoverability
15.1 / 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 |
|---|---|---|
link_decision |
params_unexplained |
Attach an EXISTING decision (from record_decision) to one more entity — a service, file, symbol, contract, or domain — with a typed relationship: "motivates" (decision caused this entity to exist), "constrains" (decision limits how it can evolve), "documents" (decision explains it), "implements" (entity is the concrete realization of the decision). Use for post-hoc linking: e.g. a month after recording an ADR you realize it also motivates a new service. Unlike record_decision (which can include initial links via the links[] array in one call), link_decision adds ONE link at a time to an already-persisted decision. Unlike get_decisions_for (read), this is a write. Prerequisites: Tentra API auth + existing decision_id + a valid entity_id matching the chosen entity_type. entity_id must be the ID of a service, a CodeFile ID, a CodeSymbol ID, a contract_id from record_contract, or a domain_id — depending on the type of entity being linked. Write path. Response: { ok: true, link_id }. |
Selection evidence
Confusable tool pairs.
10 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
index_code |
index_code_continue |
medium | Both belong to the same indexing pipeline; a task like 'continue indexing' or 'finish indexing my repo' could lead an agent to re-run index_code instead of driving index_code_continue, or to call the continue tool without having started the job. |
analyze_codebase |
explain_codebase |
medium | A task like 'analyze my codebase and tell me what's in it' matches the name analyze_codebase (which creates a diagram) while the user actually wants the narrative walkthrough from explain_codebase; both claim coverage of 'understand/document my codebase'. |
update_architecture |
sync_architecture |
medium | 'Update my architecture to match the current code' is ambiguous: sync_architecture only diffs/reads and then hints to apply fixes via update_architecture, so an agent may call sync expecting it to mutate, or update the diagram without a codebase scan. |
lint_architecture |
sync_architecture |
medium | 'Check if my architecture is correct/accurate' fits both: lint_architecture validates the diagram statically while sync_architecture compares it to real code; the task doesn't reveal which validation the user wants. |
explain_codebase |
explain_code_path |
medium | Generic phrasing like 'explain this code' could select either: explain_codebase narrates the whole repo while explain_code_path walks the shortest path between two symbols; a task about a specific code path or connection can be routed to the wrong one. |
record_decision |
link_decision |
medium | 'Link this ADR to the payment service' is ambiguous when the decision may or may not already exist: record_decision creates a decision and can attach initial links, while link_decision only attaches an existing one; an agent can pick the wrong write tool based on the same request. |
query_symbols |
get_symbol_neighbors |
medium | A request like 'find symbol X and show what it's connected to' could trigger either: query_symbols matches by name and its doc explicitly positions it as the starting point returning IDs that the neighbor-walking get_symbol_neighbors consumes. |
set_service_mapping |
set_domain_membership |
medium | Both 'set' a file-to-group assignment; a task like 'map these files to the payments service/domain' is ambiguous because one tool assigns concrete canvas services and the other tags abstract business domains, and each description contrasts it against the other. |
index_code |
get_index_job |
low | 'What's the status of my indexing?' or a vague 'index the repo' request could make an agent reach for get_index_job (name suggests running an index job) instead of starting with index_code or querying status, but the read-only definition and job_id dependency mostly disambiguate. |
record_contract |
bind_contract |
low | A task like 'save/bind this new API contract' could ambiguously map to record_contract (persisting the spec) or bind_contract (linking symbols to an existing contract); the distinction between creating vs. attaching is generally clear from the definitions. |
Compare the field