Skip to main content
aidax speaks the Model Context Protocol (MCP), so AI clients like Claude, Cursor, VS Code, and others can read and act on your workspaces, projects, and tasks — as you, with your permissions. There’s nothing to install: aidax hosts the MCP server for you.

​
Connect a client

Point your MCP client at the hosted aidax MCP endpoint:
https://one.aidax.io is the aidax cloud origin. If your workspace is on a different aidax domain, use that host instead.
On first connect, your client opens aidax’s login page. After you sign in, every MCP tool call runs as your authenticated user, scoped to what you can access. Authentication uses OAuth 2.1 with PKCE — no tokens to copy or manage by hand.

​
Example: Claude

Add aidax as a custom connector and paste the endpoint URL above. Claude walks you through the sign-in, then the aidax tools become available in your conversations.

​
Example: Cursor

Add an MCP server in Cursor’s settings with the URL above, approve the sign-in, and the aidax tools appear to the assistant.

​
What the AI can do

Once connected, the client can use these tools:
  • Session: whoami, list_workspaces
  • Projects: list_projects, get_project, create_project, update_project, set_project_details, get_project_content, write_project_overview
  • Tasks: list_tasks, get_task, create_task, update_task, move_task, update_task_status
  • Task conversation: list_task_activity, create_task_comment, read_task_attachment
  • Task relations: create_task_relation, get_task_relations, delete_task_relation
  • Labels: list_workspace_labels, create_label, attach_label_to_task, detach_label_from_task, delete_label
  • Memory: search_memory, list_docs, read_doc
  • Content files: list_content_files, read_content_file, write_content_file
  • Apps and assets: list_apps, publish_app, list_assets, create_asset
All actions respect your workspace permissions — a client can only see and change what you can.

​
Reading a task’s conversation

list_task_activity returns a task’s timeline: its comments and its events, oldest first. It is the same thing you see in the task’s Activity tab, so an assistant asking “what has been said about this task?” gets the whole story, including comments imported from a linked GitHub or Gitea issue. Files attached to a comment arrive as a reference — a name, a type, and a link — not as content. To open one, pass that link to read_task_attachment: text and PDFs come back as text, images come back as images. Size limits apply, so for a very large document expect to be asked for the part that matters.
list_task_comments still exists and still answers, but it reads a legacy store the app does not write to, so it will report nothing for tasks that plainly have comments. Use list_task_activity.

​
Comments and attachments are data, not instructions

Anything a tool reads on your behalf — a comment, an attached file, text inside an image — is returned to the assistant clearly fenced as untrusted content, with the instruction to treat it as material it is reading for you and never as a command directed at it. That matters most where a project is linked to a public GitHub or Gitea issue, because then a stranger’s comment lands in the same timeline.
This lowers the risk; it does not remove it. A model can still be talked into something. Treat it as one layer, and keep the same care with untrusted content that you would anywhere else.