- When completing development work in this repo, commit the finished change and push it to the tracked remote branch as part of the task. Do not leave completed dev work only in the local worktree unless the user explicitly asks not to commit or push.
- Project-local Codex agent specs live in
.codex/agents/. Keep the Dev Agent and BA Agent instructions there aligned with this workflow. - For tasks with two or more independent areas of investigation, use subagents in parallel. Delegate codebase exploration, documentation research, testing, and reviews where appropriate. Wait for relevant agents and consolidate their results before finishing.
Use ProAgentStore account state only through the configured MCP server.
- Do not use the ProAgentStore web UI for account actions unless the user explicitly asks.
- Do not call private REST, GraphQL, database, or worker APIs directly unless the user explicitly overrides this rule.
- First inspect available MCP tools/resources before choosing an action. The surface is
per-connection — some tools are gated to the console surfaces of the agents the connected
user actually subscribes to, so call
tools/listrather than assuming a name exists. - Prefer read-only tools unless the task explicitly requires changes. You do not have to
guess which those are: every tool carries
readOnlyHint/destructiveHintannotations, and they are accurate —readOnlyHint: truemeans the tool only reads. - Use
dry_run: truebefore uncertain write/runtime/destructive actions. - Confirm before destructive actions such as cancelling instances, deleting knowledge, unregistering runtimes, cancelling tasks, or overwriting files.
- Use the exact
confirmvalue required by the MCP tool schema. - Use
mcp_audit_logwhen the user asks what MCP actions were attempted or completed. - Never use a generic shell/API proxy as a substitute for a specific MCP tool.
[mcp_servers.proagentstore]
url = "https://mcp.proagentstore.online/mcp"Use the public trial flow only for previews:
list_agents -> chat_with_agent
Use private instance flow for durable user work:
list_agents -> subscribe_agent -> my_instances -> add_instance_knowledge -> chat_with_instance -> instance_messages
Use the runtime flow when work has to happen on the user's own machine — a browser acting on a real site, or a coding CLI in a real checkout. The runner reaches the platform over a WebSocket relay, so "is a runtime registered" is a question you must ask, not assume:
subscribe_agent -> register_instance_runtime -> instance_runtime_status -> run_instance_task -> approve_instance_task -> instance_task_events
The server sends instructions on initialize. Read them: they are the server's own
statement of how it expects to be driven, and they are maintained with the tool surface.
Two tools return a structured object, not a bare array — this is the shape to code against:
list_agents -> {"agents": [...]}
my_instances -> {"instances": [...]}
Both also declare an outputSchema and answer with structuredContent. Every other tool
returns a single text content block.
Failure is detected structurally, not by reading prose. This server does not set isError.
A failure is either text beginning Error: , or JSON carrying an error key. Check both;
treat anything else as success.
Four distinctions the platform makes and a caller routinely collapses. Getting one wrong produces a confident, wrong report about someone's agent.
mutatesis the field that answers "does this change anything" — notscope.scopeis what triggers the write-consent gate; the two are separate questions and a read can carry a write scope. Readmutates.reachanswers "does this touch anything outside the platform":platform(never leaves),machine(the owner's computer),internet(a third party, or any host the caller names). Do not derive this from whether a tool names a connector — that proxy is wrong in both directions. It fails closed: an unclassified tool reportsinternet.tierhas four values, not two:base(always granted),standard(creator-selectable),runtime(needs a local runner),connector(external system).- A run's
healthhas four values:working,waiting,stalled, andended.endedmeans the run is CLOSED and makes no claim that anything is running — and since it is returned for any run that is notrunning, it is the answer you will see most often. Quotehealth; do not derive your own verdict fromstatusor from timestamps.lastAliveAt(a heartbeat) andlastProgressAt(the last instruction advance) are different facts: a healthy long step looks stale on the second and fresh on the first. A parked run carrieswaitingReason, andwaitingUntilonly when a resume time is actually knowable — a run waiting on a person has no such time.