[DIvyaNautiyal07]

Proposed changes

A session driving mech_tools or mech_request now sees whose mech it is about to pay. Both reports carry mech-client 0.24.0's ToolManager.mech_report_or_terms next to the valory_operated, terms and terms_url they already had:

• operator: the domain the manifest claims, as the operator's identity, with domain_verified and a verification_note when the domain does not back it. The name is claimed_name, which mech-client never checks.
• benchmarks and benchmark_note: the operator's link per tool, as a claim, never a figure.
• delivery: requests received, self-delivered and delivered by others, the creation time and age_days, with the note that the counters cover on-chain requests and off-chain requests settled on-chain.
• payment: the method, no price.

mech_request reports these before anything is paid or any allowance is armed, so a session that skips mech_tools still learns whose mech it pays and whose terms apply. The on-chain flow keeps reporting the terms only, as it never reads the manifest.

The record lookup and the fallback to the terms are mech-client's: when the manifest or the record cannot be read, mech_report_or_terms returns the terms with report_note. Connect calls it directly, inside listing_mechs(), so its indexer reads do not log false RPC mismatch warnings after a request on another chain. There is no extra deadline: a slow proof host stalls only the report on the mech being paid, and the request's timeout does not bound the other steps before payment either.

The pearl-connect skill tells the agent to name the operator's domain and whether it is verified, to treat the name as the operator's claim, and that a missing operator means the operator is unknown unless valory_operated is true. The skill and tool descriptions stay short, since each report field carries its own note. The old terms_note is gone: report_note already says when the manifest could not be read.

Depends on

mech-client 0.24.0, released and pinned from PyPI.

Not reported, by upstream design: the mech owner. The indexer's Mech.owner is the creation-tx sender and is never updated on transfer.

Fixes

None.

Types of changes

• Non-breaking feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING doc
• I am making a pull request against the main branch (left side). Also you should start your branch off our main.
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• The suite enforces 100% coverage; my changes do not reduce it
• Public-facing documentation has been updated with the changes affected by this PR. Even if the provided contents are not in their final form, all significant information must be included.
• If I changed a package under packages/, I have re-locked the Olas package hashes (autonomy packages lock)

Further comments

Run locally from common_checks.yml: the full lint set, safety, unit-tests-coverage and integration-tests. Launch tests were not run (they need a real terminal).

The guard tests run mech-client's real report past a faked resolver, indexer, agent-id lookup and proof fetch: the full report and the two fallbacks.

🤖 Generated with Claude Code

[OjusWiZard]

The report runs before the digest is registered or any deposit is armed, an indexer failure falls back to the terms with report_note, and domain_verified / verification_note pass through unchanged. The call matches mech-client#263's mech_report, and the test against the real pinned client guards the shape. Tests pass (1214). Merge after mech-client 0.24.0 is released and the git source is dropped.

[bennyjo]

One question on how the skill tells the agent to name the operator, raised after the approval because an unchecked name next to a verified domain can lead an agent to pay a lookalike mech.

[OjusWiZard]

Could connect/mech_report.py move into mech-client, same as mech_terms.py did in #73? Reading the mech's record from the indexer, falling back to the terms when it can't be read, and setting report_note is mech logic, and for separation of concerns mech stuff belongs in its own library. With it in mech-client (e.g. ToolManager.mech_report doing the record lookup itself and degrading to the terms), connect calls one function, the fallback rule lives in one place for every client, and its tests go with it. valory-xyz/mech-client#263 is still open, so it can land there before the release.

Also, the pinned rev (d002711) is behind #263, and the bump to its current head (33d99a7) breaks a couple of things here:

• test_tools_use_mech_client_s_real_mech_report asserts operator["name"], which is now claimed_name plus name_note.
• The same test's fake requests.get returns a plain object; the proof fetch now uses with requests.get(..., stream=True) and iter_content, so the fake needs __enter__/__exit__/iter_content. As it stands the AttributeError is caught upstream, the domain comes back unverified, and the assertion fails.
• SKILL.md, README.md and the CLAUDE.md operator key list describe operator as the name and domain the manifest claims; upstream now treats the domain as the identity and claimed_name as unchecked, and a redirecting domain gets its own verification_note.

[DIvyaNautiyal07]

Done. connect/mech_report.py is gone and both flows call mech-client's mech_report_or_terms, so the record lookup, the fallback to the terms and report_note live upstream (mech-client#263, da08f07). The pin is on that commit. The real-client guard now checks claimed_name/name_note and link-only benchmarks, uses a streaming proof fake, and has two more cases that run the real fallback for an unreadable record and an unreadable manifest. Docs describe the domain as the identity and the redirect note.

[bennyjo]

No blockers from me, just four questions inline about a stall before payment, a false RPC warning, the missing operator case and the stale description.

[OjusWiZard]

Thanks. Re-checked at c6f1b62: both flows call mech-client 0.24.0's mech_report_or_terms directly inside listing_mechs(), the docs are short, and tests pass (1258).

[bennyjo]

All four points are addressed and CI is green, so this is good to merge with the pre-payment check as your follow-up.