PROBLEM — This is not a PAGS platform bug; it's a gap in the operating instructions given to an orchestrator (e.g. a Claude project) that drives a PAGS instance through this MCP connector. Two distinct gaps surfaced in the same session:
-
NO GENERAL GUIDANCE ON NESTED TOOL DISCOVERY — The instructions never state the discover-then-call sequence for an instance's own nested tools (list_instance_tools to get exact names/schemas, then call_instance_tool with those exact names/field names). Without that stated explicitly, the orchestrator guessed tool names and field names repeatedly (e.g. trying issue_number before discovering the real field is number) before landing on a working call. This is a generic sequencing rule that applies to every nested tool, not a fix for one specific case.
-
UNCLEAR WHEN DIRECT ACTION IS APPROPRIATE VS. HANDING OFF TO THE CODER — The orchestrator's instructions describe an issue-driven workflow ("when we agree on work, it becomes an issue, and the issue goes to the coder"), which was read as implying that even simple, safe, read-only-adjacent actions like filing a GitHub issue must be routed through a full coding run. In fact call_instance_tool can file issues, read issues, comment, etc. directly — no run needed. The instructions describe the philosophy of issue-driven work, but don't clarify that simple direct actions (via call_instance_tool) are appropriate and preferred over spending a coding run when the action doesn't require code changes.
ASK — Update the orchestrator-facing instructions/guidance (not PAGS platform code) to state: (a) always discover a nested tool's exact schema via list_instance_tools before calling it via call_instance_tool, never guess field names from memory or a similar tool's shape; (b) simple direct GitHub/instance actions (reading, filing, commenting on issues) should be done directly via call_instance_tool rather than dispatched as a coding run, reserving coding_loop_start/start_work for work that actually requires code changes or repository access.
NOTE — This may be purely a documentation/instructions change outside this repo (e.g. a project's own system prompt), rather than a platform code change. If so, the actionable output of this issue may just be recommended instruction text rather than a code diff — please confirm scope before starting implementation work.
PROBLEM — This is not a PAGS platform bug; it's a gap in the operating instructions given to an orchestrator (e.g. a Claude project) that drives a PAGS instance through this MCP connector. Two distinct gaps surfaced in the same session:
NO GENERAL GUIDANCE ON NESTED TOOL DISCOVERY — The instructions never state the discover-then-call sequence for an instance's own nested tools (list_instance_tools to get exact names/schemas, then call_instance_tool with those exact names/field names). Without that stated explicitly, the orchestrator guessed tool names and field names repeatedly (e.g. trying issue_number before discovering the real field is number) before landing on a working call. This is a generic sequencing rule that applies to every nested tool, not a fix for one specific case.
UNCLEAR WHEN DIRECT ACTION IS APPROPRIATE VS. HANDING OFF TO THE CODER — The orchestrator's instructions describe an issue-driven workflow ("when we agree on work, it becomes an issue, and the issue goes to the coder"), which was read as implying that even simple, safe, read-only-adjacent actions like filing a GitHub issue must be routed through a full coding run. In fact call_instance_tool can file issues, read issues, comment, etc. directly — no run needed. The instructions describe the philosophy of issue-driven work, but don't clarify that simple direct actions (via call_instance_tool) are appropriate and preferred over spending a coding run when the action doesn't require code changes.
ASK — Update the orchestrator-facing instructions/guidance (not PAGS platform code) to state: (a) always discover a nested tool's exact schema via list_instance_tools before calling it via call_instance_tool, never guess field names from memory or a similar tool's shape; (b) simple direct GitHub/instance actions (reading, filing, commenting on issues) should be done directly via call_instance_tool rather than dispatched as a coding run, reserving coding_loop_start/start_work for work that actually requires code changes or repository access.
NOTE — This may be purely a documentation/instructions change outside this repo (e.g. a project's own system prompt), rather than a platform code change. If so, the actionable output of this issue may just be recommended instruction text rather than a code diff — please confirm scope before starting implementation work.