MCP Research Assistance: Define Inputs and Permissions

KabuForge's public guide describes a stdio MCP server bounded to an explicit workspace. A client launches that server and calls its tools and resources. Treat it as a research interface, rather than an unrestricted route for sending arbitrary programs or shell operations.

Inspect the selected version's Agent API and actual tool list first. Published releases and development candidates may differ. Website documentation alone does not establish capabilities in your installed environment; reconcile the schema and diagnostic output from that environment.

Choose the existing guide for Codex, Claude, Cursor or stdio. Confirm absolute paths for the installed executable and research workspace. Review and approve client-configuration changes before applying them.

Supply input references according to the selected build's workspace rules. Absolute paths in server-launch configuration and file references in tool calls have different roles. Choose a narrow workspace containing authorized research inputs rather than granting a whole home directory for convenience.

R0 inspects capabilities, catalogs and status. R1 includes local validation and analysis and may write artifacts. A visible R1 tool does not itself establish user approval to execute research. Specify the input, operation and output location, then confirm the execution scope.

Client tool settings, platform approvals and KabuForge's risk levels are separate control layers. Enabling one does not automatically grant permissions in the others. Obtain user approval appropriate to the actual side effects of the requested operation.

The public Agent API requires server-side --enable-paper and agent_call_id plus idempotency_key for R2 mutations. These technical gates do not replace user approval of a concrete change. If a candidate has additional confirmation fields, follow that selected version's schema.

For an uncertain mutation result, inspect the same call receipt and state before retrying. A fresh key can defeat duplicate prevention. Do not interpret R2 opt-in as real-order permission. This article does not provide a trading connection or order-execution procedure.

Name the authorized workspace and readable files in the request. Keep secret values out of arguments, proposed configurations and logs; also check whether material may be transmitted to an external AI service. A local workspace boundary alone does not settle client-side transmission permissions.

After a call, reconcile the actual tool, input identities, terminal status, receipt and output. Preserve failure references and reasons. Listing tools is not successful computation. The first deliverable is concrete evidence that authorized read-only inspection worked within its defined scope.

Use only the specified research workspace to inspect the selected build's MCP tools and public documents read-only.
Do not change files or execute research. Explain available operations, required inputs and permissions.
Wait for separate approval before private-data access or external transmission.
Report actual checks, receipts and unresolved items.

Read Point-in-time data · Lookahead bias · What is backtesting? to place this topic alongside other research checks. Confirm documented operations and limits in the official Agent API. Use documentation for your selected build; if public main differs from your environment, defer unverified claims.

This article teaches research procedures. Numerical examples are fictional teaching illustrations, not actual investment performance. It does not recommend securities or trades or guarantee future returns. Historical public courses do not establish complete historical information availability. Disclaimer

Explore the research data learning path

• What is point-in-time data? Understanding historical availability
• Price return and total return: check the benchmark basis
• Reproduce a Study: Preserve Data, Settings and Run Evidence