Fix execution log download URL schema

[cursor]

Description

Fixes a critical schema-surface bug in harness_get for execution logs. The execution_log handler supported return_download_url=true, but the top-level harness_get schema did not advertise that field. Strict MCP clients could strip the flag before dispatch, causing URL-only log requests to fall back to full log download and buffering. For large logs with missing or unreliable Content-Length, that can reintroduce memory exhaustion risk.

This PR adds return_download_url to the registered harness_get input schema and adds focused coverage that simulates schema-driven clients forwarding only registered fields.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other

Checklist

• Tests pass
• Typecheck passes

Validation performed:

• pnpm exec vitest run tests/tools/tool-handlers.test.ts -t "harness_get — execution_log"
• pnpm build && pnpm docs:generate && pnpm typecheck && pnpm docs:check && pnpm test

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

Important

• src/tools/harness-get.ts:32, src/registry/toolsets/logs.ts:16-28, src/tools/harness-list.ts:19-23, tests/tools/tool-handlers.test.ts:436-460: This fixes the strict-client stripping bug, but it still leaves the execution_log contract mis-modeled. return_download_url is now documented only on the global harness_get schema, while execution_log still has no get.paramsSchema and still publishes execution_id via listFilterFields even though it is get-only. So harness_describe(resource_type="execution_log") still will not surface prefix / execution_id / return_download_url, and harness_list continues advertising execution_id as a global list filter for a non-listable resource. The new tests only lock the global tool schema/runtime branch, so this discovery-contract drift still passes CI. Please move these fields into execution_log.operations.get.paramsSchema, remove the listFilterFields entry, and add a focused harness_describe / filter-catalog regression.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

This closes the strict-client stripping bug, but it still leaves the execution_log discovery contract split across the wrong surfaces. harness_describe(resource_type="execution_log") still will not advertise prefix, execution_id, or return_download_url, because src/registry/toolsets/logs.ts has no get.paramsSchema for them and still misfiles execution_id under listFilterFields even though execution_log has no list op. That also leaks execution_id into harness_list's global filter catalog.

Per the architecture rules, get-only inputs should live on the get operation's paramsSchema, not on the generic tool schema / list-filter metadata. Please add an execution_log.operations.get.paramsSchema for prefix, execution_id, and return_download_url, remove the listFilterFields entry, and add a focused harness_describe regression so this metadata cannot drift again.

[cursor]

Important

• src/tools/harness-get.ts:32, src/registry/toolsets/logs.ts:16-28, src/tools/harness-list.ts:22-23, tests/tools/tool-handlers.test.ts:436-460: The runtime strict-client fix looks right, but the public discovery contract is still split across two places. return_download_url is now documented only on the global harness_get schema, while execution_log is still a get-only resource with execution_id exposed via listFilterFields and no operations.get.paramsSchema. That means harness_describe(resource_type="execution_log") still omits return_download_url from the operation metadata, and harness_list continues advertising execution_id as a global list filter for a non-listable resource. This breaks the “metadata matches operations” / “docs match implementation” rules and the new tests will not catch it because they only cover the global tool schema/runtime branch.

Open questions / assumptions

• Assuming execution_log is intentionally get-only and harness_describe remains the source of truth for resource-specific input discovery.

Change summary

• The strict-client return_download_url regression itself appears fixed; the remaining gap is resource metadata alignment and focused contract coverage.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

Good fix for the strict-client stripping path. One remaining architecture issue: this adds return_download_url only to the global harness_get schema, but execution_log is still modeled as a get-only resource with execution_id in listFilterFields and no operations.get.paramsSchema in src/registry/toolsets/logs.ts. That leaves harness_describe(resource_type='execution_log') without the get-param contract for execution_id / return_download_url, and it keeps polluting harness_list's global filter catalog with a get-only field. Please move those get-only inputs into get.paramsSchema, drop the listFilterFields entry, and add a focused describe/filter-catalog regression.