deliverd

Endpoint

Hosted endpoint · transport streamable-http

Connect

This is a remote MCP server — point an MCP client at the endpoint URL. Clients with native remote support (Claude, Cursor, VS Code, …):

For stdio-only clients (older Claude Desktop, etc.), bridge with mcp-remote:

If the server requires authentication, add the provider's token/header (e.g. an X-API-Key) per its docs. A quick reachability check:

Tools

• request_approval — Ask named people to authorise an action before you take it; returns the request and its page.
• get_approval — The status of an approval — pending, approved, rejected or expired — with any questions the approver asked.
• answer_approval_question — Answer a question an approver asked about your request, on the approval page.
• cancel_approval — Withdraw an approval you asked for, while it is still undecided.
• request_review — Ask named people to read work and say whether it is right; returns the request and its page.
• get_review — The outcome of a review — pending, approved or changes requested — with each reviewer's verdict and note.
• cancel_review — Withdraw a review you asked for, while it is still unanswered.
• request_information — Ask named people typed questions and get structured answers back; returns the request and its page.
• get_collection — The answers to a request for information, with who replied and what they said.
• cancel_collection — Withdraw a request for information you made, while it is still open.
• check_gate — Ask whether you may perform a registered action before you perform it; policy answers allow, refuse, or a person decides.
• get_gate — The state of a gate decision you raised, once a person has answered it.
• cancel_gate — Withdraw your own gate request, or a permission you have not used yet.
• record_execution — Report what you did with a gate's permission; a different artifact or destination is refused.
• release_version — Have Deliverd make the staged report version a gate authorised live, and record it as verified.
• create_flow — Start a flow: the thread tying one job's approvals, reviews, requests and publishes together.
• find_flow — Find the flow you started with an externalId, or null, so a restarted job extends it rather than starting a second.
• get_flow — A flow with everything in it and the timeline of what happened across all of them, in order.
• complete_flow — Say the work a flow covers is done. Only whoever started it, and it takes no new members afterwards.
• cancel_flow — Close a flow as abandoned rather than done, so the history says which of the two happened.
• create_task — Start an objective: what the work is ultimately for, kept apart from the conversation and returned at the top of every context.
• get_task_context — The objective, where a task stands, its decisions, open questions, side-task results, reports and next action — read instead of the history.
• list_tasks — The objectives you can see, with status, next action and side-task counts — find work already under way before starting more.
• get_task — One task in full: objective, state, result, findings, decisions, where it sits and its side tasks.
• get_task_graph — Every side task under an objective, with its status and one-line result, and the links between them.
• update_task — Update a task's working state — where it stands, open questions, what blocks it, the next action — or its status.
• create_side_task — Branch a problem out of the main task so the main thread stays on its goal. It starts with a chosen snapshot of the parent.
• add_finding — Record a work product on a task: hypothesis, test, evidence, conclusion, recommendation or a decision you suggest.
• complete_task — Finish a task with a structured result: summary, findings, proposed decisions, open questions and the next action.
• apply_side_task — Carry a finished side task's result into its parent, or keep or discard it, and return to the objective.
• reopen_task — Reopen a finished task when there is more to do. What it found the first time is kept.
• cancel_task — Call a task off as abandoned rather than finished. Cancelling an objective cancels its open side tasks.
• request_decision_approval — Put a decision you suggested to the organisation's approval process; approved confirms it, rejected rejects it.
• create_governed_task — Start an objective under Compliance Mode: the AI system, purpose, owners, risk, data and oversight, held to the controls they require.
• govern_task — Put an existing objective under Compliance Mode, with what is known of its governance profile.
• get_governance_context — A governed task's profile, AI system, controls and their state, evidence, readiness and gate answer.
• update_governance_profile — Record what was learnt about a governed task. An agent may raise risk or add facts; only a person lowers or clears them.
• get_required_controls — The governance controls a governed task must satisfy, and what satisfies each.
• submit_evidence — Record evidence for a governed task and the controls it speaks to, with the scores a run measured or the tool's own report.
• request_control_approval — Put a compliance or deployment approval control to a person through the organisation's approval process.
• check_governance_gate — Whether governed work may proceed, naming the controls still outstanding. Recorded.
• get_evidence_pack — The AI governance evidence pack of a governed task, with a digest. Assists audit; certifies nothing.
• register_ai_system — Add an AI system to the organisation's register so governed tasks can name it.
• update_ai_system — Change an AI system's register entry. An agent cannot lower its risk or set its status.
• move_ai_system — Put an AI system's register entry forward for assessment, or withdraw it. Decisions on it are a person's.
• list_ai_systems — The organisation's register of AI systems.
• get_ai_system — One AI system's register entry: its lifecycle status and steps, who answers for it, and the governed tasks that name it.
• get_ict_register — The ICT third-party register: providers, contracts, the AI systems under each, what entries lack, and concentration per provider.
• get_framework_mapping — How framework requirements map onto governance controls, and how far a governed task's completed controls cover them. Not a compliance verdict.
• create_custom_framework — Draft the organisation's own governance framework. Applies only once a person publishes and adopts it.
• check_agent_authority — Whether this agent may take a kind of action on its own, only with a person's approval, or not at all.
• screen_data — Before sending text to an AI model, find the personal data, secrets and confidential terms in it, and whether that model may receive them.
• record_model_change — Record a new provider, model or version for an AI system; every governed task using it is reassessed.
• search_knowledge — Search the organisation's confirmed knowledge — facts, conventions, decisions, who to ask — before you start or when unsure.
• get_knowledge — One knowledge entry in full: its words, who confirmed it, when it is due for review, and the versions it replaced.
• propose_knowledge — Propose something you learned as organisation knowledge, for any agent to rely on once a person confirms it.
• list_playbooks — The organisation's playbooks and approved prompts: how a kind of job is done, with which version is in force.
• get_playbook — One playbook: its purpose, its inputs and each step with the rule that applies — a gate check, an approval or a review.
• draft_playbook — Write down a procedure as a playbook draft. A person puts it in force; nobody runs a draft.
• start_playbook — Run the playbook in force: an objective with a side task per step, each holding its instruction and its rule.
• use_prompt — Take one of the organisation's approved prompts, filled in with your inputs: the version in force, with its limitations.
• propose_setup — Describe the consequential things you can do here, and get rules for them drafted for an administrator to review and add.
• trigger_reassessment — Ask for a governed task to be reassessed. Its gate stays closed until a person completes it.
• report_ai_incident — Report an AI incident against a governed task or AI system. High or critical closes the gate until a person resolves it.
• get_ai_incident — One incident with its DORA classification, its reports and which report is due next, by when.
• get_risk_indicators — The AI risk scorecard for a month: each indicator against its green, amber and red limits, the trend and the actions open.
• submit_risk_indicator_reading — Give a month's figure for an AI risk indicator Deliverd cannot measure itself, with where it comes from.
• draft_incident_report — Draft the next DORA report on a major incident and put it to a person to sign off.
• get_evidence — An evidence pack for a flow or a report: every step, who decided what, and the full timeline.
• get_profile — Who this connection belongs to, to tell connected accounts apart.
• resolve_audience — Turn natural-language audience phrases into concrete principals.
• list_workspaces — List workspaces, with who can already open a given report.
• publish_report — Publish HTML to a persistent secure URL, with an audience named in plain English.
• update_report — Publish a new version of an existing report, keeping its URL and audience.
• rename_report — Change a report's title or address; the old address keeps working.
• move_report — File a report into a workspace.
• archive_report — Stop a report's URL serving. Reversible; nothing is deleted.
• unarchive_report — Put an archived report back, at the same URL and audience.
• rollback_report — Serve an earlier version again, without republishing it.
• get_report — Fetch a report's metadata, URL and current version.
• find_reports — Search reports by title or slug.
• list_templates — Reports the organisation offers as starting points.
• share_report — Grant people, teams or groups access to a report.
• revoke_access — Take a report's access away again, from the same audience phrase that granted it.
• send_report — Email a report to a list of addresses, with a covering note. Each gets their own link.
• list_due_schedules — Recurring reports waiting on this agent.
• create_schedule — Ask an agent for a recurring publish, on a cron cadence.
• update_schedule — Change a schedule's cadence, or turn it on or off.
• delete_schedule — Stop asking for a recurring publish.
• list_report_data — List the datasets a report reads when it is opened.
• update_report_data — Replace a report's live data without publishing a new version.
• delete_report_data — Remove a dataset from a report.
• list_comments — Read reader feedback, with the quoted passage and context.
• list_open_comments — Every open comment thread across the organisation's reports — what needs attention.
• get_report_analytics — Who read a report and when: views, readers, by day and by version.
• get_org_analytics — Readership across every report, including the ones nobody has opened.
• get_revision_brief — The open feedback on a report as one revision prompt, with the readers' screenshots.
• comment_on_report — Comment on a report, anchored to a quoted passage.
• retract_comment — Take back a comment nobody has answered yet.
• resolve_comment — Mark a comment thread resolved.

About MCP

The Model Context Protocol (MCP) is an open protocol Anthropic introduced for connecting LLM-based agents to external tools and data sources. Providers publish MCP servers that expose their API surface as structured, discoverable tools — an MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.) can connect to the server and call its tools without any per-provider integration code.

Browse every MCP server on the APIs.io network or compare with the broader Agent Skill surfaces of the same providers.

Work with this as data

Every MCP server here is available over the APIs.io API and to AI agents over MCP.

curl "https://apis.io/api/v1/mcp/deliverd"

curl "https://apis.io/api/v1/mcp?limit=25"