01Safety
30.0 / 30
What changed in the harness
Selection accuracy 93→89, token cost down 0%, unconfirmed writes 100%→100%.
Category breakdown
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
30.0 / 30
27.5 / 30
15.2 / 20
18.4 / 20
Highest-impact fix
Estimated gain +5 pointsConsolidate overlapping tools and trim repetitive schema text while preserving behavior, parameter, and return semantics.
Description evidence
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 |
|---|---|---|
scan_job_board_keywords |
no_return_description |
Scan a company's job board for roles in chosen categories across Greenhouse, Lever, Ashby, Workday, and Rippling. Returns matched role counts and titles per category as a flat, Clay-ready JSON row; when previous_roles_detected and previous_run_date are supplied, the row also includes a delta of newly added or removed roles since that prior run. Read-only; requires an APIFY_TOKEN and consumes Apify credits per call. |
Selection evidence
5 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
scan_gtm_hiring_signals |
aggregate_gtm_signals |
medium | A task like 'check this company's GTM hiring signals' could map to either the narrow hiring-only scan or the composite aggregator that also includes hiring; both take a company domain and return GTM signal data, so the agent may pick the aggregate one when only hiring detail was wanted, or vice versa. |
resolve_linkedin_url |
resolve_company_identity |
high | Both resolve a company name/domain to a LinkedIn URL with confidence scoring; a request like 'find this company's LinkedIn page' plausibly matches either tool, and the distinction (single-field resolution vs. full cross-checked canonical identity) is subtle from the description alone. |
enrich_company_firmographics |
get_company_changes |
low | Both take a domain and return firmographic-related data, but their purposes (static enrichment vs. change monitoring since last run) are clearly distinct, making confusion unlikely except in vague prompts like 'get company info updates'. |
resolve_company_identity |
enrich_company_firmographics |
low | Both accept a domain and company_name and return company data, but resolve_company_identity is about identity/URL matching while enrich_company_firmographics is about firmographic attributes; a generic 'get company details' request could theoretically hit either. |
resolve_company_identity |
get_company_changes |
low | Shared domain/company_name inputs but very different purposes (identity resolution vs. change monitoring), so confusion is only plausible under vague phrasing like 'look up this company'. |
Compare the field