How to connect an AI agent to a PRO-dela project via MCP

You can now connect an external AI agent to a PRO-dela project via the Model Context Protocol (MCP): for example, opencode, Claude Code, Codex, or another client that supports remote MCP servers. The agent will be able to get project context, find tasks, create one or more tasks, assign an assignee, and change status — within the rights of the person who issued the token.

Each token is tied to exactly one project, stored on the server only as a hash, and works on a separate narrow surface of commands. Documents, invoices, budgets, chats, and project settings are not accessible through this connection.

Why connect an external agent to the task system

AI agents work well with development context: they read code, help create a plan, and find related changes. But the result often stays in the chat or terminal. To transfer it to the project management system, you have to manually create tasks, assign assignees, and update statuses.

After the analysis, the agent can transfer the agreed plan to PRO-dela tasks or update an existing task right during the work session. It gets statuses, participants, and rights from the current project.

What a connected agent can do

The current MCP surface includes six tools:

• get_project_context — returns the project, its statuses, participants, and the token owner's rights;
• list_tasks — searches and shows project tasks with filters;
• create_task — creates one task, optionally assigning an assignee and status immediately;
• create_tasks — creates a batch of up to 25 tasks;
• set_task_status — changes the status of a task;
• set_task_assignee — assigns an assignee and optionally a status.

Tasks are addressed only by numeric ID. This is a deliberate limitation: similar names should not lead to changing the wrong task. Status and assignee names can be passed as text; if the match is ambiguous, the agent will receive a list of candidates instead of guessing.

Batch creation works on a best-effort basis: successfully processed items are created, and errors are returned separately in failed. Only unsuccessful items need to be retried, not the entire batch.

How access is restricted

The project agent token stores two important bindings: the project and the user who issued it. Therefore, the agent does not get a new role and does not expand the token owner's permissions.

• If a user cannot create tasks in the interface, the agent also cannot create them.
• If a person does not have access to someone else's task, the token will not bypass that check.
• A token for project A cannot access a task in project B.
• After a user is removed from the project, their tokens stop working.
• The project owner can disable all external agent connections with a single switch.

The secret is shown only once, immediately after issuance. Later, the interface retains the name, short prefix, expiration, state, and time of last use. The token can be revoked at any time. Available durations are 30, 90, and 365 days, or an option without a fixed date; a token unused for 90 days is automatically revoked.

How to connect opencode

1. Open the desired project in PRO-dela.
2. Go to the project section "Integrations" and the block "External AI agents".
3. Click "Issue agent token", set a clear name and duration.
4. Copy the secret: after closing the window, it cannot be shown again.
5. Copy the ready opencode configuration from the same form.

{ "mcp": { "pro-dela": { "type": "remote", "url": "COPIED_MCP_URL", "headers": { "Authorization": "Bearer pdl_YOUR_TOKEN" }, "oauth": false } } }

The parameter "oauth": false is mandatory: a static project-scoped bearer token is used here, not OAuth. It is better to take the exact URL from the project interface — local and published servers have different addresses.

Claude Code and Codex

For Claude Code, PRO-dela shows a ready connection command:

claude mcp add --transport http pro-dela COPIED_MCP_URL \ --header "Authorization: Bearer pdl_YOUR_TOKEN"

In Codex, it is more convenient to store the secret in an environment variable, and leave only its name in config.toml:

[mcp_servers.pro-dela] url = "COPIED_MCP_URL" bearer_token_env_var = "PRODELA_MCP_TOKEN"export PRODELA_MCP_TOKEN="pdl_YOUR_TOKEN"

Do not add the working secret to a public repository, screenshot, or message. If the token is accidentally exposed, revoke it and issue a new one.

How to connect two projects to one agent

One token cannot cover multiple projects. For two projects, issue two tokens and register one MCP URL twice under different names:

{ "mcp": { "pro-dela-alpha": { "type": "remote", "url": "COPIED_MCP_URL", "headers": { "Authorization": "Bearer pdl_TOKEN_PROJECT_ALPHA" }, "oauth": false }, "pro-dela-beta": { "type": "remote", "url": "COPIED_MCP_URL", "headers": { "Authorization": "Bearer pdl_TOKEN_PROJECT_BETA" }, "oauth": false } } }

In the configuration, each project needs a separate name: the tools of each server get their own prefix, by which the model distinguishes connections. Before changing a task, the agent should explicitly call get_project_context of the relevant connection. If cross-project work is not required, it is safer to store a separate connection in the configuration of each working repository and not show both projects to one session.

Who manages tokens

Any project participant can issue a token for themselves if the plan limit is not exhausted. They see and revoke their own tokens. The project owner and a participant with the right to change the project see the list of all connections and can revoke any of them. The secret itself is not shown again to anyone.

The number of simultaneously issued tokens is counted separately for each project and depends on the company's plan. If the limit is exhausted, you can revoke an unused connection or choose a plan with a higher limit.

Practical scenario

Imagine that the agent has finished analyzing a new feature and prepared a plan of eight steps. Instead of manual transfer, you can ask:

Get the project context. Show a draft of eight tasks with assignees and statuses. After confirmation, create them in PRO-dela and resend only the items that returned in failed.

A good working habit is to first request the context and task list, then check the proposed changes, and only then allow writing. MCP reduces mechanical work, but the decision about what exactly should appear in the project remains with the person.

Frequently asked questions

Can the token see all projects in my account?

No. It is tied to one project. For another project, you need a separate token and a separate MCP client entry.

Will the agent get access to documents and invoices?

No. Currently, the agent surface is limited to project context and task operations. The project token does not accept the regular user API.

What happens after token revocation?

The agent's next request will fail authentication. The revoked secret cannot be returned — if necessary, a new one is issued.

Can I connect multiple clients to one project?

Yes. It is better to issue a separate named token for each device or client: this way you can see the last use and disable one connection without affecting others. The number of tokens is limited by the plan.

Does the AI agent act autonomously?

MCP gives it the technical ability to call allowed tools. The degree of autonomy, confirmations before writing, and usage rules depend on the MCP client itself and your instructions to the agent.

Connect the agent to your first project

Open the project, go to "Integrations" and issue a separate token for your MCP client. Start with a safe check: ask the agent to call get_project_context and list_tasks without creating or modifying data. Once you are sure the correct project is connected and the rights match expectations, move on to working commands.

If you don't have an account yet, register in PRO-dela, create a project, and check the available connection limit on the pricing page.