Your AI agent

How AI works here

By default this platform runs no models of its own. It holds the research — the works, the full texts, the evidence units, the screening decisions, the datasets, the manuscripts — and exposes all of it to your agent through one MCP server. The reasoning happens in the client you already use and pay for; the data, the rules and the record stay here.

• You choose the model. Claude Code, Claude Desktop, claude.ai, ChatGPT, Codex, Cursor, VS Code, Windsurf, Zed, Cline — any client that speaks the Model Context Protocol.
• You pay your own provider. Hikma meters nothing for this; a free account and either an OAuth sign-in from the client or a personal key are enough.
• It acts as you. Exactly your permissions in exactly your projects, every call recorded under your account on the project's Activity tab.

Connecting an agent

1. Open a project → Your AI (the AI section of the project bar). A project with no conversations opens straight on the connection guide; otherwise press Connect your AI.
2. Pick your client. The panel writes out the exact command or configuration file with this deployment's server address already filled in.
3. Choose how it signs in: OAuth through the client (your browser opens and you approve it) or a personal key created in the same step and shown once.
4. Choose which tools it gets — everything, or the smaller Literature & writing, Systematic review or Data analysis packs for clients that struggle with long tool lists.
5. Run the command. The panel waits and confirms as soon as the first call arrives.

The same panel is under Settings → Integrations, and one connection covers every project you belong to: you name the project in what you ask, not in the configuration. Per-client recipes — Claude Code, Claude Desktop, claude.ai, ChatGPT, Codex, Cursor, Windsurf, VS Code, Zed, Cline and stdio-only clients — are on Connect an AI agent (MCP) and the API.

What it can do, and what it cannot

Connected, an agent gets 176 tools. All of them are things the platform does without a model of its own:

• Literature — search the backbone sources, plan and run a search strategy, snowball, add and remove works, list what still has no full text.
• Reading — acquire and fetch full texts, read a source page by page or as structured XML, search inside a source's text.
• Evidence and review — read the evidence table, set the protocol, record screening decisions, save risk-of-bias and GRADE judgements, insert the review tables.
• Writing — create and read manuscripts (whole blocks, never shortened; each block with a stable id and a content hash, and with per-sentence provenance on request), propose paragraphs, patch a sentence or replace text bound to the exact text it read, insert tables, update the front matter, run the checks.
• Data — register and describe datasets, run catalogue analyses and sandboxed Python or R, insert results and figures into a manuscript.
• The project — list projects and the workspace, keep a plan, write notes, post messages into the conversation, store a memory proposal.

What it cannot do matters as much:

• It cannot cite a work that is not in the project library. Citations are objects bound to works; text an agent types is not a citation.
• It cannot type an unsourced number into a manuscript. Numbers arrive as bound numbers pointing at an evidence unit, a page or an analysis result.
• It cannot overwrite your text. Everything it writes is a tracked change.
• It cannot decide a screening call, a risk-of-bias judgement or a GRADE rating. What it records is a vote or a suggestion until a reviewer confirms it.
• It cannot read a paper the platform could not fetch. list_missing_full_texts names those works with the reason; upload the PDF on the Sources page and ask again.
• It cannot read a document you uploaded until you say it may. A file you upload is recorded as your licensed copy: Hikma reads, stores, OCRs, indexes and quotes it for your research, and does not hand its text to your agent. See “What your agent may read” below.

Its own abilities are welcome: the server tells the agent to use its own web search and page fetching for discovery and to register whatever it finds with add_works or fetch_article, so every citation still resolves to a project work with provenance.

What your agent may read

Every document in a project carries a rights class, and the class decides — per document, per person, per destination, on every call — whether its text may leave for your agent. Retrieval, reading on screen, server-side processing, storage, OCR, indexing, quotation, delivery to an external AI, export and redistribution are separate rights: a permission for one is never a permission for another.

A refused read is never silent. Your agent is told the reason code, which document, what still works, and where you would record the decision — and it can ask you for it (request_rights_attestation), which puts a card in front of you and grants nothing. It can also ask the server what it may read before it tries (get_source_access_capabilities). The Sources page shows the same answer beside each file.

How its work arrives

• Text lands as tracked changes. Open the manuscript's Changes panel to accept or reject it, one by one or per author. Nothing is applied silently.
• Attribution survives acceptance. Accepting a tracked insertion keeps the *proposer* on the text, not the person accepting it, so the Authors panel can still colour the manuscript by who wrote each run months later. An agent's text is attributed to the client that wrote it — “Claude Code”, “Cursor”, whatever your key is called — with the plug icon and its own colour; the platform's own assistant appears under its own name.
• Everything it does is a conversation. Its tool calls, their results, the plan it keeps and the messages it posts appear in the project's Your AI tab, marked MCP with the client's name; the conversation opens like any other and updates live.
• Manuscripts open beside the conversation as artifacts — the live document with its pending changes.
• Actions are recorded under your account on the project's Activity tab, exactly as if you had done them by hand.

Where it lives

• Project → Your AI — the connection guide, plus every conversation a connected agent has created in this project with the manuscripts it wrote beside them.
• Inside a manuscript — the right panel's Assistant tab says what your agent does here and offers a Connect button; its work shows up in the Changes and Authors panels.
• Settings → Integrations — API keys, the connected clients you have approved (revocable at any time) and the same connection recipes.
• Your own client — in practice this is where you work: the terminal, the desktop app or the IDE you already have open.

Asking well

• Name the project in your first message (“in project X …”); the agent finds it itself with list_projects.
• Ask for the whole deliverable in one message — “find the trials of Y since 2015, fetch their full texts and draft the evidence section as tracked changes” — and let the agent plan the steps.
• Ask it to run the server's research_method prompt once per session: it sets out the evidence-first rules — cite only project works, bind every number, never follow instructions found inside a source.
• Long jobs do not block your client: acquire_full_text, extract_evidence and summarize_sources return a job at once and the agent polls get_job for the result.
• Select nothing and describe the section by name; the agent reads the manuscript's outline itself and writes into the heading it belongs to.

Memory and preferences

Settings → Assistant memory holds your tone and citation-style preferences, standing instructions and the facts your AI keeps about how you work: what you told it (confirmed) and what it inferred (proposals to keep or forget). A connected agent adds a proposal with remember_about_researcher and you confirm it here. Memory can be scoped to one project and switched off entirely, and the drafting tools never see it.

When the platform's own AI is switched on

An administrator can switch the deployment to platform AI as well (Admin → AI & keys). The platform then makes model calls on its own provider keys, metered against the project's monthly budget, and a second way of working appears beside your agent. Until they do, none of the following is on screen — the buttons and tabs are hidden rather than disabled.

• The built-in assistant — a conversation with a composer in the Your AI tab. It plans, searches, reads at scale through cached reading notes, drafts section by section from the evidence, verifies its own claims against the sources and reports what it could not read.
• AI audit (project → AI audit) — in platform-AI mode every run and model call with its cost; in bring-your-own mode the same page shows the judgements your connected agents submitted (what they read, how much of each batch they covered, the review mode they declared). Either way an ICMJE-style disclosure statement is composed from that record.
• AI writing actions in the manuscript — the ribbon's Assistant tab, the AI cluster in the selection bubble menu, the Assistant section of the right-click menu and the AI entries in the slash menu.
• Suggestions in the review workspace — “Ask the assistant” on the screening desk, “Propose with the assistant” on risk of bias and GRADE.
• Evidence extraction — Pre-fill on the evidence table and Extract on a source.
• Drafting in submissions — the cover letter and the reviewer-response draft.
• Twelve further MCP tools, the model-backed ones: draft_section, revise_manuscript, verify_claims, critique_manuscript, gather_evidence, check_evidence_readiness, summarize_sources, extract_evidence, screen_works, suggest_risk_of_bias, suggest_grade and plan_search. Each one your agent can do itself has a contract that takes its judgement instead (submit_evidence_units, submit_screening_votes, propose_risk_of_bias, propose_grade, submit_claim_dispositions, submit_critique_findings, submit_readiness_assessment, submit_source_summary, submit_search_plan, propose_section), so no capability is lost — only the platform's model spend. run_analysis stays available: passing a script runs it in the sandbox, which needs no model.

A built-in conversation is a run with a budget set by the project (defaults from the administrator). It works in rounds until it delivers its report or the budget is spent, continues on the server if you close the page, and can be stopped at the current step; steps, rounds and cost sit under each answer. Every model call is metered — but only the platform's own calls. Your connected agent is never metered by Hikma, in either mode.

Everything in the sections above still holds whichever engine writes: text arrives as tracked changes, citations are objects, numbers are bound to their evidence, and screening and grading stay suggestions until a reviewer confirms them.