[ScalePad] Get the daily backup-health history for ONE ScalePad client. Returns {client:{name, client_id}, data:[...]} — note the array is named 'data' here, whereas scalepad_br_list_clients_health names the same per-day array 'history'. Each entry carries date and a compliance object (pending_count, at_risk_count, in_compliance_count, out_of_compliance_count, out_of_compliance_no_results_count). Pass the ScalePad client_id returned by scalepad_br_list_clients_health or scalepad_core_list_clients — NOT a Backup Radar company identifier. This operation documents no 404: an unknown, inaccessible, or missing client surfaces as a 400 alongside genuine validation failures, so read the vendor error detail instead of inferring not-found from the status. Requires an ACTIVE Backup Radar product subscription of its own (HTTP 402 PRODUCT_SUBSCRIPTION_REQUIRED otherwise), and is served only from the US and EU ScalePad gateways.

[ScalePad] List monitored backup devices with their most recent result and daily SLA history. Cursor-paginated: data[], total_count, next_cursor. Each device carries br_device_id (the encrypted URL-safe Backup Radar identity — always present, and the reliable key to deduplicate on), br_job_name, br_device_name, br_backup_classification (Primary Backup | Primary Verification | Primary Boot Verification | Replication | System Alert), client (ScalePad name/client_id plus br_company_name, all nullable), last_result[] ({status: success|warning|error, date} — an empty array means no result has arrived yet, and several entries can share a timestamp when one result raised multiple flags), and history[] (most-recent-first, each {date, sla_status} where sla_status is Pending | At Risk | In Compliance | Out Of Compliance | Out Of Compliance - No Results; history is null when there is no linked backup plan or the row is a system alert). Devices are returned whether or not their Backup Radar company is mapped to a ScalePad company — the ScalePad-side fields device_id and device_name are NULL on unmapped rows. Requires an ACTIVE Backup Radar product subscription of its own (HTTP 402 PRODUCT_SUBSCRIPTION_REQUIRED otherwise), and is served only from the US and EU ScalePad gateways.

[ScalePad] List ScalePad clients with their daily backup-health history from Backup Radar. Cursor-paginated: returns data[] (each entry is {client:{name, client_id}, history:[...]}), total_count, and next_cursor (null on the last page). Each history entry carries date (yyyy-MM-ddTHH:mm:ssZ) and a compliance object of five integer counts — pending_count, at_risk_count, in_compliance_count, out_of_compliance_count, out_of_compliance_no_results_count (the last two are distinct states; do not collapse them). History ends on the tenant's current LOCAL date, not the caller's timezone. Pass a returned client.client_id to scalepad_br_get_client_health for one client's detail. Requires an ACTIVE Backup Radar product subscription of its own — any other ScalePad subscription is not enough and the call returns HTTP 402 (PRODUCT_SUBSCRIPTION_REQUIRED). Backup Radar is served only from the US and EU ScalePad gateways.

[ScalePad] Get one Backup Radar backup's detail from the classic API. Returns a single object with the same shape as an entry of scalepad_br_list_backups (backupId, companyName, deviceName, deviceType, jobName, methodName, backupType, status, daysInStatus, isVerified, lastResult, lastSuccess, ticketCount, failureThreshold, treatWarningAsSuccess, note, dayStartHour, tags, standalone, ticketingCompany, history). This operation documents no 404 — an unknown or inaccessible backupId surfaces as a 400 alongside genuine validation failures, so read the vendor error detail rather than inferring not-found from the status. Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] Get the individual backup RESULTS (the parsed status emails) for one Backup Radar backup. Page/size shaped like the lists: {Total, Page, PageSize, TotalPages, Results:[...]}, where each result carries dateTime, resultId, and the four independent flags success, warning, failure and manual — they are separate booleans, not one status field, and more than one can be true on the same result. Use scalepad_br_get_backup for the backup's rolled-up status instead. Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] Get Backup Radar's overview counts — the tenant-wide totals behind the portal's header. Takes no arguments. Returns six integers: backups, office365, workstations, activePolicies, inactivePolicies, retiredPolicies. The cheapest call on this API, so it is the natural first read to confirm the Backup Radar key and region are right before paging any list. Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] List the filter values this Backup Radar tenant actually has — the companies, tags, backup methods, device types, statuses and policy types that scalepad_br_list_backups accepts in its filtersJson list filters. Takes no arguments. Call this FIRST when filtering by any of those: the vendor ignores a value it does not recognize, so a guessed company or status name comes back as a full unfiltered page rather than an error. Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] List monitored backups from Backup Radar's classic API. Page/size paginated: returns {Total, Page, PageSize, TotalPages, Results:[...]}. Each result carries backupId (int64 — pass it to scalepad_br_get_backup and scalepad_br_get_backup_results), companyName, deviceName, deviceType, jobName, methodName, backupType {id,name}, status {id,name}, daysInStatus, isVerified, lastResult and lastSuccess timestamps, ticketCount, failureThreshold, treatWarningAsSuccess, note, dayStartHour, tags[], standalone, ticketingCompany, and history[] when HistoryDays was requested (each entry: date, status, lastResultDate, isScheduled, daysInStatus, countSuccess/countWarning/countFailure/countNoResult, daysSinceLastResult, daysSinceLastGoodResult, resultsCount). This is Backup Radar's OWN API, not ScalePad's Backup Radar surface — for client-level backup-health rollups use scalepad_br_list_clients_health instead. Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] List INACTIVE backups — jobs Backup Radar has stopped receiving results for. Page/size paginated: {Total, Page, PageSize, TotalPages, Results:[...]}, each carrying backupId, companyName, deviceName, deviceType, jobName, methodName, backupType {id,name}, emailFrom (the address the status emails arrived from) and lastReceived. Note the narrower shape: an inactive row carries NO status, history, tags or ticket counts — read scalepad_br_get_backup with its backupId for those. Inactive is not retired; retired jobs are a separate list (scalepad_br_list_retired_backups). Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] List RETIRED backups — jobs someone deliberately retired in Backup Radar, as opposed to jobs that merely went quiet (scalepad_br_list_inactive_backups). Page/size paginated: {Total, Page, PageSize, TotalPages, Results:[...]} with the same narrow row shape as the inactive list (backupId, companyName, deviceName, deviceType, jobName, methodName, backupType, emailFrom, lastReceived). Requires an active Backup Radar subscription, and is served from the US and EU only.

[ScalePad] Create a remediation action item for a client. Returns 201 with the created record (id, code, parent_entity_id, status, weakness_name, weakness_description, corrective_action, responsible_person, responsible_department, roadmap, dates, currency, priority, cost, milestones, change_in_milestone). Only three properties are schema-required: weakness_name, priority and currency. ScalePad resolves responsible_person and responsible_department against existing users/departments and returns INVALID_RESPONSIBLE_PERSON / INVALID_DEPARTMENT when they do not exist. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_action_items first. Map the new item to objectives, controls, risks or questions afterwards with scalepad_cm_map_client_action_item; the create body takes no mappings.

[ScalePad] Attach ONE document you already hold to an action item, uploading it through ScalePad in a single call (vendor multipart/form-data operation, one binary 'file' part). Returns the vendor's declared 200 with {id, code, documents[{file_name, document_id}]}. The vendor caps each upload at 10 MB; because MCP has no binary parameter type the content is passed here as base64 and decoded into a real binary part before sending, so the base64 text is roughly a third larger than the file itself. Use THIS tool for a single modest file whose bytes you have. Use scalepad_cm_create_client_action_item_document_signed_url instead when you have several files, a large file, or a file the end user will upload themselves — that tool returns pre-signed URLs and the bytes never pass through StackJack.

[ScalePad] Register one or more documents against an action item and get back vendor-minted pre-signed UPLOAD urls — an ordinary JSON POST, not a file transfer. Returns 201 with {id, code, documents[{file_name, document_id, signed_url, expires_in_seconds}]} (300 seconds in the vendor example). You then send each file's bytes yourself to its signed_url using the method the response names, before it expires; that URL is already authorized, so do NOT attach the ScalePad x-api-key to the storage request. ScalePad does not publish required storage headers, checksums, a maximum batch size or a completion callback — honor whatever the runtime response returns and invent nothing. Choose this over scalepad_cm_create_client_action_item_document for batches, for files near or above the 10 MB direct-upload cap, or when a human will do the uploading.

[ScalePad] PERMANENTLY delete an action item. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the item is not found. ScalePad's own changelog states that action-item deletion removes the record AND all associated data — its documents, mappings and history go with it — and documents no soft delete, restore or undo. Confirm the exact client and the exact item (read it back with scalepad_cm_get_client_action_item first) before calling, and prefer setting status to Not Applicable via scalepad_cm_update_client_action_item when the goal is only to take an item out of the active workload.

[ScalePad] Get one action item in full for a client. Adds to the search-row fields the complete relationship set: documents[] {id, file_name}, objectives[] {id, name, code, program_name}, controls[] {id, name, code}, risks[] {id, name, code} and assessment_questions[] {id, name, code} — the codes in those arrays are exactly the values scalepad_cm_map_client_action_item and scalepad_cm_unmap_client_action_item accept. Dates come back as planned_start_date / planned_end_date / actual_start_date / actual_end_date here (the search rows use the *_completion_date spelling for the same two fields).

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated remediation roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, action_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}}. Keep paging until next_cursor is null. This tool returns COUNTS ONLY — it never lists individual action items; use scalepad_cm_search_client_action_items with a client id for the item rows.

[ScalePad] LINK an action item to the compliance entities it remediates. For an action item the linkable entities are framework objectives (requirements), assessment questions, risks, controls, assets and asset types — each identified by its BUSINESS CODE (or, for asset types, by name), never by numeric id. Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_action_item for that). Read current links from the objectives[] / assessment_questions[] / risks[] / controls[] arrays of scalepad_cm_get_client_action_item.

[ScalePad] For ONE client, by client id: search that client's remediation action items. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted (vendor operationId a_actionitem); it replaced the retired GET /action-items list route. Returns client {id, name, tenant_id}, action_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}, and action_items {total_count, next_cursor, data[]}. Each row carries id, code (e.g. AI-9), weakness_name, weakness_description, status, priority, created_by and responsible_person (each {id, name, email}), responsible_department, corrective_action, milestones, changes_to_milestones, source_of_weakness, currency, cost, roadmap, effort_in_hours, requirements[] and timestamps. Beware one vendor inconsistency: search rows spell the end dates planned_completion_date / actual_completion_date while scalepad_cm_get_client_action_item returns planned_end_date / actual_end_date for the same values.

[ScalePad] UNLINK an action item from objectives, assessment questions, risks, controls, assets or asset types. The codes you send identify only the LINKS to remove — neither the action item nor the mapped entities are deleted — but the relationship removal is a real state change with no undo, so echo the exact action item and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update an action item (HTTP PATCH). Only the properties you send change; everything else is left alone. Returns 200 with the patched record. Every property is optional here — including the three the create call requires — but weakness_name, if present, must not be empty. This is the tool for status transitions and for recording actual start/end dates as remediation progresses. To change an item's LINKS to objectives, controls, risks or questions use scalepad_cm_map_client_action_item / scalepad_cm_unmap_client_action_item instead; relationships are not patchable here.

[ScalePad] Add a RESPONSE — a free-text entry on an assessment question's note thread. This does NOT set or change the question's answer (use scalepad_cm_update_client_assessment_question_answer for that). Returns 201 with {id, question_code, response, provided_by, created_at, updated_at, created_by {id, full_name}}; keep the returned id, because editing the note later requires it in the request body. A question can carry many responses — each call appends a new one rather than replacing the last.

[ScalePad] CLEAR the saved ANSWER on an assessment question, returning it to unanswered. Succeeds with HTTP 204 and no body (this tool returns ). Scope is deliberately narrow and worth stating to the user: this removes only the answer selection — the question itself, its note-thread responses, and its mappings to evidence/action items/policies/procedures all survive. It is still a real data loss (the previous selection and its answered_by/answered_at attribution are gone) and it lowers the client's assessment completion figures. To DELETE a note instead, use scalepad_cm_delete_client_assessment_question_response.

[ScalePad] PERMANENTLY delete ONE response (note) from an assessment question's thread. Succeeds with HTTP 204 and no body (this tool returns ). Here the response id is a PATH parameter, unlike the edit tool which carries it in the body. The question, its answer and its other responses are untouched, but the deleted note and its author attribution are unrecoverable — ScalePad documents no soft delete or restore. Confirm the exact note (read responses[] from scalepad_cm_search_client_assessment_questions) before calling. Do not use this to clear the question's ANSWER — that is scalepad_cm_delete_client_assessment_question_answer.

[ScalePad] Get one assessment question in full, addressed by its question CODE (not its numeric id). Returns id, code, question, owner {id, full_name}, status, auditor_status, answer_options[] {id, answer, order} — the authoritative list of values the answer write will accept for THIS question — plus the linked action_items[] {id, title, code, description, due_at}, objectives[] {id, code, name, program_name}, delegated_to and assessment_status. Read answer_options before calling scalepad_cm_update_client_assessment_question_answer. This fragment declares no 400, so a bad code may surface as 404.

[ScalePad] For ONE client, by client id: that client's assessment completion summary. Returns answering_progress {total_questions, answered_questions, answered_questions_percentage, yes, no, partially, na}, assessment_score_percentage, and question_group_progress[] {name, count, answered, not_answered, yes, no, partially, na}. Setting includeFrameworkAssessmentStats adds frameworks_count and frameworks[] {framework_id, framework_name, answering_progress, assessment_score_percentage}. There is no pagination envelope. Field-name caveat: the vendor's prose describes the default payload as assessment_question_groups / grades / assessment_stats while its schema and examples use the names listed above — trust the returned JSON. For every client at once use scalepad_cm_list_clients_assessment_summary.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated assessment completeness for the whole client base, for partner-level dashboards: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, assessment_summary {yes, no, partially, not_answered, not_applicable, answering_percentage, total}}. Keep paging until next_cursor is null. This roll-up is counts only and has no per-framework breakdown — call scalepad_cm_get_client_assessment_summary with includeFrameworkAssessmentStats for that, one client at a time.

[ScalePad] LINK an assessment question to the records that substantiate its answer. For a question the linkable entities are evidence records, action items, policies and procedures — each by BUSINESS CODE (evidence and action-item codes resolve against their task definitions; policy and procedure codes against document codes). Note this set is narrower than a control's or an action item's: there are no risk, objective or asset arrays here. Succeeds with HTTP 204 and no body (this tool returns ). Only non-empty arrays are applied and empty/omitted ones are ignored, so send at least one populated array. Mapping is additive; it never removes an existing link.

[ScalePad] For ONE client, by client id: search that client's common-assessment questions. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted (vendor operationId assessmentQuestionsSearchByClient). Note the path is .../assessments/common/questions with NO /search suffix; an older changelog documents a /search path that the current contract does not have. Returns {data[], total_count, next_cursor} where each question carries id, code (the question_code every other tool here takes), question, guidance, group_name, question_area, answer, past_answer, answered_at, frameworks[{id, name}], responses[{id, response, created_at, updated_at, created_by {id, full_name, email}}] and timestamps.

[ScalePad] UNLINK an assessment question from evidence records, action items, policies or procedures. This is ControlMap's ONLY unmap that uses the HTTP DELETE verb rather than a .../mappings/bulk-delete POST, and consequently the ONLY operation in the whole ScalePad connector whose DELETE carries a request body — the codes to unlink go in the BODY, not the URL. Succeeds with HTTP 204 and no body (this tool returns ); empty lists make no changes. Removal is limited to the relationships: neither the question nor any mapped record is deleted. It still destroys compliance traceability with no undo, so echo the exact question code and every code being detached back to the user first.

[ScalePad] Save the ANSWER to an assessment question — the questionnaire selection itself, not a note. Upsert semantics (HTTP PUT): it creates the answer if there is none and overwrites it if there is, with no read-modify-write step and no previous value returned other than through the question's past_answer field. Returns 200 with {question_code, answer, answered_by {id, name}, reset_answer, answered_at}. The value must be one of the question's valid options — Yes, No, Partially or NA — so check answer_options via scalepad_cm_get_client_assessment_question if unsure; an invalid value returns 400. To add commentary instead of changing the selection use scalepad_cm_create_client_assessment_question_response.

[ScalePad] Edit an existing RESPONSE (a note on an assessment question's thread) — again, not the question's answer. The vendor's HTTP PATCH targets the responses COLLECTION, so the note being edited is identified by an id INSIDE the request body, not in the URL. Returns 200 with the updated note. One documented contradiction: the operation text says you may update either or both of response and provided_by, while the schema marks id and response as required — so always send id and response, and add provided_by only when it changes. This edits one note per call; it never rewrites the whole thread.

[ScalePad] Create a control for a client. Returns 201 with the created record (id, the ScalePad-assigned code, name, description, implementation_notes, control_set_name, control_family_name, owner, created_by, timestamps). The authenticated API-key user becomes the control's owner and creator unless owner_email names someone else. Two contract details matter: UNKNOWN JSON properties are REJECTED, so send only the documented fields; and the fragment publishes no formal required array even though type, name, description, control_set_name and control_family_name all carry minLength 1 — send a real value for each rather than an empty string. No idempotency key is documented, so never blind-retry; re-check with scalepad_cm_search_client_controls. Relationships are not part of the create body — use scalepad_cm_map_client_control afterwards.

[ScalePad] PERMANENTLY delete a control. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the control is not found. ScalePad documents no soft delete, restore, undo, or dependency-conflict status for control deletion, and a control is the hub every objective, policy, procedure, evidence record, risk and action item maps to — read scalepad_cm_get_client_control first, show the user the policies/procedures/evidences/objectives/risks/action_items arrays that will lose their link, and confirm the exact client and control before calling. When the intent is only to stop tracking, patch status instead.

[ScalePad] Get one control in full for a client. Adds to the search-row fields (id, code, name, description, implementation_notes, status, compliant, control_set, control_family, owner) the audit trail — created_by, created_at, updated_at — and the complete relationship set: policies[], procedures[], evidences[], action_items[], objectives[], risks[], documents[] and audit_tests[]. Those arrays are the authoritative view of what is currently mapped; their codes are what scalepad_cm_map_client_control and scalepad_cm_unmap_client_control accept.

[ScalePad] For ONE client, by client id: that client's control implementation roll-up. Takes no query parameters. The vendor returns the same paginated envelope as the cross-client tool but with exactly one row — {data:[{client {id, name, tenant_id}, control_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}}], total_count: 1, next_cursor: null} — so read data[0], and do not try to page it. Use scalepad_cm_list_clients_controls_summary instead for the same roll-up across every client.

[ScalePad] List the control FAMILIES available to one client — the groupings inside a control set (e.g. "Human Resources Management" with code HRM, "Common Criteria Related"). Cursor-paginated: returns {data[], total_count, next_cursor}. Each row is deliberately thin: id, name, code, the creating user and created_at only — no controls are included. Use the family NAME as control_family_name when creating or patching a control; a family name is not necessarily unique across sets, so send control_set_name alongside it when disambiguating. This endpoint accepts no sort parameter.

[ScalePad] List the control SETS available to one client — the control libraries themselves (e.g. "Controlmap Baseline Controls" with code CBC, "SOC 2"). Cursor-paginated: returns {data[], total_count, next_cursor} with the same thin row shape as control families — id, name, code, creating user and created_at only. Use the set NAME as control_set_name when creating or patching a control; when a patch changes both catalog fields, ScalePad resolves the control SET first and then the family within it. This endpoint accepts no sort parameter.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated control implementation roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, control_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}}. Keep paging until next_cursor is null. Counts only — for the control rows themselves call scalepad_cm_search_client_controls with a client id.

[ScalePad] LINK a control to the compliance entities that evidence or depend on it. For a control the linkable entities are framework objectives (requirements), evidence records, policies, procedures, governance documents, risks and action items. Objectives are special: they use an objectives[] array of {program_name, codes[]} because a requirement code is only unique WITHIN its compliance program; everything else uses a flat array of business codes. Succeeds with HTTP 204 and no body (this tool returns ). Only non-empty arrays are applied and empty/omitted ones are ignored, so send at least one populated array. Mapping is additive and never removes an existing link — use scalepad_cm_unmap_client_control for that.

[ScalePad] For ONE client, by client id: search that client's controls. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted (vendor operationId openControlsSearch). Returns client {id, tenant_id, name}, control_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}, and controls {total_count, next_cursor, data[]}. Each control row carries id, code (the display code, e.g. CC6.1), name, description, implementation_notes, status, compliant (boolean), control_set {id, name}, control_family {id, name} and owner {id, name}. Use the row id with scalepad_cm_get_client_control for full relationships, and the row code as a control_codes value in every mapping body across ControlMap.

[ScalePad] UNLINK a control from objectives, evidence, policies, procedures, governance documents, risks or action items. The codes you send identify only the LINKS to remove — neither the control nor the mapped records are deleted — but this breaks compliance traceability with no undo, so echo the exact control and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update a control (HTTP PATCH). Only the properties you send change. Returns 200 with the updated record plus a message naming exactly which fields were applied (e.g. "Successfully patched: name, status."), which is the field to check rather than assuming the whole body took effect. Ordering is defined by the vendor: status is applied AFTER the other scalar changes, and when control_set_name and control_family_name are sent together the set is resolved before the family. Two replacement semantics to be careful with: tags and contributors REPLACE the current lists rather than appending, and an empty array clears them. Note the response echoes priority as a NUMBER even though the request takes the string enum.

[ScalePad] Register one or more documents against an EVIDENCE DEFINITION and get back vendor-minted pre-signed UPLOAD urls — an ordinary JSON POST, not a file transfer. SIDE EFFECT: because the target is the evidence rather than a specific request, ScalePad ALSO CREATES A NEW EVIDENCE REQUEST to hold the documents; the response's evidence_request_id is that new request. Returns 201 with {evidence_request_id, documents[{file_name, document_id, method, signed_url, expires_in_seconds}]} (300 seconds in the vendor example — note the relative expires_in_seconds here, versus the absolute expires_at on the DOWNLOAD tool). You then send each file's bytes yourself to its signed_url using the method the response names, before it expires; that URL is already authorized, so do NOT attach the ScalePad x-api-key to the storage request. ScalePad does not publish required storage headers, MIME restrictions, checksums, a maximum batch size or a completion callback — honor whatever the runtime response returns and invent nothing. Choose this over scalepad_cm_create_client_evidence_document for batches, for files near or above the 10 MB direct-upload cap, or when a human will do the uploading. To register against an EXISTING request instead, use scalepad_cm_create_client_evidence_request_document_signed_url.

[ScalePad] Register one or more documents against an EXISTING evidence request and get back vendor-minted pre-signed UPLOAD urls — an ordinary JSON POST, not a file transfer. Unlike the evidence-level variant this creates NO new request; the documents attach to the request you name. Returns 201 with {evidence_request_id, evidence_request_code, documents[{file_name, document_id, method, signed_url, expires_in_seconds}]} (300 seconds in the vendor example — a relative expiry, versus the absolute expires_at on the DOWNLOAD tool). You then send each file's bytes yourself to its signed_url using the method the response names, before it expires; that URL is already authorized, so do NOT attach the ScalePad x-api-key to the storage request. ScalePad does not publish required storage headers, MIME restrictions, checksums, a maximum batch size or a completion callback — honor whatever the runtime response returns and invent nothing. Choose this over scalepad_cm_create_client_evidence_request_document for batches, for files near or above the 10 MB direct-upload cap, or when a human will do the uploading.

[ScalePad] PERMANENTLY delete ONE stored document from a client's compliance record — the file itself, wherever it was attached (an evidence request, a policy, a procedure, a governance document or an action item). Succeeds with HTTP 204 and no body (this tool returns ); 404 if the document is not found. The parent record survives with the document removed from its documents[] array; ScalePad documents no soft delete, restore or undo, and this is the only ControlMap operation that removes a file without removing its parent. Confirm the exact client and the exact document with the user before calling — resolve the file NAME first, either from the parent record's documents[] array or from scalepad_cm_get_client_document_signed_url, so the user is confirming a filename rather than a bare integer.

[ScalePad] Get a short-lived DOWNLOAD url for ONE stored document belonging to ONE client. Returns the DocumentResponse as JSON — {document_id, file_name, signed_url, expires_at} — not the file bytes, and no StackJack blob storage is involved: signed_url points at ScalePad's own storage and expires_at is the vendor's absolute expiry timestamp (note the field name is expires_at here, whereas the UPLOAD signed-url tools return a relative expires_in_seconds). Fetch the file from signed_url before that time; the URL is already authorized, so do NOT attach the ScalePad x-api-key to the storage request. Document ids come from the documents[] arrays on the compliance records — scalepad_cm_list_client_evidence_requests, scalepad_cm_get_client_policy, scalepad_cm_get_client_procedure, scalepad_cm_get_client_governance and scalepad_cm_get_client_action_item all carry them.

[ScalePad] Create an evidence definition for ONE client. Returns 201 with EvidenceCreatedIdsResponse — just {id, evidence_request_id} — because creating an evidence also opens its first evidence request; read the full record back with scalepad_cm_get_client_evidence. An evidence can have only ONE schedule, and the PATCH tool cannot modify an existing one (it returns 409), so get the schedule right here or plan to delete and re-add it. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_evidences first.

[ScalePad] Attach ONE document you already hold to an EVIDENCE DEFINITION, uploading it through ScalePad in a single call (vendor multipart/form-data operation, one binary 'file' part). SIDE EFFECT: because the target is the evidence rather than a specific request, ScalePad CREATES A NEW EVIDENCE REQUEST and attaches the document to it — returns 201 with {evidence_request_id, documents[{file_name, document_id}]}. To attach to an EXISTING request instead, use scalepad_cm_create_client_evidence_request_document. The vendor caps each upload at 10 MB; because MCP has no binary parameter type the content is passed here as base64 and decoded into a real binary part before sending, so the base64 text is roughly a third larger than the file itself. Use THIS tool for a single modest file whose bytes you have; use scalepad_cm_create_client_evidence_document_signed_url instead for several files, a large file, or a file the end user will upload themselves — that tool returns pre-signed URLs and the bytes never pass through StackJack.

[ScalePad] Open a NEW evidence request against an existing evidence definition — an out-of-cycle ask for proof, on top of whatever the recurrence schedule generates. This operation takes NO request body at all: the client id and evidence id in the path are the entire input. Returns 201 with the created request's id (EvidenceResponse, e.g. {"id":101}); read the row back with scalepad_cm_list_client_evidence_requests for its code, status, owner and due date, then set assignee/status/due_date/notes with scalepad_cm_update_client_evidence_request. There is no documented idempotency key and nothing distinguishes two identical calls, so never blind-retry — a repeat creates a SECOND request.

[ScalePad] PERMANENTLY delete an evidence definition. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the evidence is not found. This removes the standing definition together with everything hanging off it — its recurrence schedule, every evidence request raised against it, and its mappings to objectives, controls and assessment questions — and ScalePad documents no soft delete, restore or undo. Confirm the exact client and the exact evidence (read it back with scalepad_cm_get_client_evidence, and check how many requests exist with scalepad_cm_list_client_evidence_requests) before calling. If the goal is only to stop FUTURE collection, use scalepad_cm_delete_client_evidence_schedule instead, which keeps the evidence record.

[ScalePad] Remove the RECURRING COLLECTION SCHEDULE from an evidence record — the evidence itself survives, but its recurrence configuration (frequency, interval, days, start/end) is gone and ScalePad will raise no further evidence requests from it. Succeeds with HTTP 204 and no body (this tool returns ). The required scheduleAction argument decides how far the deletion reaches, and one of its two values ALSO DELETES existing incomplete evidence requests, taking any partial collection work with them — always read the exact value back to the user before calling. There is no restore: re-establishing recurrence means PATCHing a fresh schedule with scalepad_cm_update_client_evidence (which is also the only way to CHANGE a schedule, since PATCH returns 409 while one still exists).

[ScalePad] Get ONE evidence definition in full for ONE client. Returns the EvidenceDetailResponse shape: id, code (e.g. EV-1), title, description, repeats, created_by and owner (each {id, name}), schedule, refresh_status, created_at/updated_at, plus the complete relationship set — controls[{id, code, title}], assessments[{id, code, question}] and objectives[{id, code, name, program_name}]. The codes in those arrays are exactly the values scalepad_cm_map_client_evidence and scalepad_cm_unmap_client_evidence accept (objective_codes, control_codes and assessment_question_codes respectively). To see the collection cycles instead of the definition, call scalepad_cm_list_client_evidence_requests.

[ScalePad] List every evidence REQUEST raised against ONE evidence definition for ONE client — the individual collection cycles behind an EV-nn record. Returns {client {id, name, tenant_id}, evidence_id, data[]} where each row is {id, code (e.g. EV-2-1), status, created_by, owner, documents[{id, file_name}], due_date, implementation_notes, created_at, updated_at}. This endpoint takes NO paging, sort or filter parameters at all — the full set for that evidence comes back in one response. The row id is the evidence_request_id the ControlMap Evidence Requests tools and the evidence-request signed-URL tool take.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated evidence-collection roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, evidence_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}}. Keep paging until next_cursor is null. This tool returns COUNTS ONLY — it never lists individual evidence records; use scalepad_cm_search_client_evidences with a client id for the evidence rows.

[ScalePad] LINK an evidence definition to the compliance entities it proves. For evidence the linkable entities are exactly three kinds: framework objectives (requirements), controls and assessment questions — each identified by its BUSINESS CODE, never by numeric id, and resolved server-side (objective_codes to requirement.reqid, control_codes to control.display_code, assessment_question_codes to the assessment question's external id). Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_evidence for that). Read current links from the objectives[], controls[] and assessments[] arrays of scalepad_cm_get_client_evidence. This tool sets EXPLICIT links; scalepad_cm_refresh_client_evidence_mappings re-derives the AUTOMATED ones.

[ScalePad] Re-evaluate ALL automated evidence mappings for ONE client — a command, not a query, and it acts on the whole client at once rather than a single evidence record. It takes NO request body: the client id in the path is the entire input. ScalePad uses it to re-sync mappings after configuration changes, pull updated mapping definitions and recompute mapping relationships for compliance workflows. Returns 200 with {status, code, clientId, message}, e.g. {"status":"SUCCESS","code":"EVIDENCE_MAPPINGS_REFRESHED","clientId":"...","message":"Evidence mappings refreshed successfully."}; note the response spells the client key clientId in camelCase, unlike the client_id path parameter. It recomputes DERIVED mappings — it does not add or remove the explicit links you set with scalepad_cm_map_client_evidence, and it is not needed after a manual map/unmap. Unusually for this connector the operation declares no 404, so a bad client id surfaces as 400 INVALID_CLIENT.

[ScalePad] For ONE client, by client id: search that client's evidence definitions. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted; it replaced the retired GET /evidences list route. Returns client {id, name, tenant_id}, evidence_summary {completed, review, in_progress, not_started, not_applicable, total, completion_percentage}, and evidences {total_count, next_cursor, data[]}. Each row carries id, code (e.g. EV-1), title, description, repeats, created_by and owner, schedule, refresh_status (e.g. Current, Somewhat Current), created_date/updated_date, an evidence_request_summary keyed by status, and — when the evidence_request flag is on — an evidence_requests[] array of {id, code, title, description, status, created_by, owner, documents[], due_date, implementation_notes, timestamps}. For the whole client base use scalepad_cm_list_clients_evidences_summary instead, which takes NO client id.

[ScalePad] UNLINK an evidence definition from objectives, controls or assessment questions. The codes you send identify only the LINKS to remove — neither the evidence nor the mapped entities are deleted — but the relationship removal is a real state change with no undo, and dropping a link can leave a requirement showing as unevidenced, so echo the exact evidence and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes, so reject an all-empty request rather than sending it. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update an evidence definition (HTTP PATCH). Only the properties you send change; everything else is left alone. Unusually for a PATCH this returns HTTP 204 with NO body (this tool returns ) — read the result back with scalepad_cm_get_client_evidence if you need the updated record. IMPORTANT: an evidence can have only ONE schedule and this call CANNOT modify an existing one — sending a schedule for an evidence that already has one returns the declared 409 conflict. To change a recurrence, first remove the old schedule with scalepad_cm_delete_client_evidence_schedule and then PATCH the new one. To change the evidence's LINKS to objectives, controls or assessment questions use scalepad_cm_map_client_evidence / scalepad_cm_unmap_client_evidence; relationships are not patchable here.

[ScalePad] ARCHIVE ONE evidence request — a ONE-WAY transition that removes it from the active collection workflow. ScalePad publishes no unarchive or restore operation on this API, so the request stops appearing as outstanding work and cannot be returned to the active queue through the API; that irreversibility is why this is treated as destructive even though nothing is deleted (the request, its documents and its history remain readable). This operation takes NO request body: the client id and request id in the path are the entire input. Returns 200 with {id, code, status, message}, e.g. {"id":102,"code":1,"status":true,"message":"Evidence request archived successfully."}. Archiving an already-archived request is a no-op in effect, though the vendor still records audit metadata for the call — so it is safe to retry, unlike the create. Prefer setting status to Completed or Not Applicable with scalepad_cm_update_client_evidence_request when the request should stay in the workflow.

[ScalePad] Attach ONE document you already hold to an EXISTING evidence request, uploading it through ScalePad in a single call (vendor multipart/form-data operation, one binary 'file' part). Unlike the evidence-level upload this creates NO new request — the document lands on the request you name. Returns 201 with {evidence_request_id, evidence_request_code, documents[{file_name, document_id}]}. The vendor caps each upload at 10 MB; because MCP has no binary parameter type the content is passed here as base64 and decoded into a real binary part before sending, so the base64 text is roughly a third larger than the file itself. Use THIS tool for a single modest file whose bytes you have. Use scalepad_cm_create_client_evidence_request_document_signed_url instead when you have several files, a large file, or a file the end user will upload themselves — that tool returns pre-signed URLs and the bytes never pass through StackJack. For a link rather than a file, use scalepad_cm_create_client_evidence_requests_links.

[ScalePad] Attach a HYPERLINK to an evidence request instead of uploading a file — for proof that lives elsewhere (a shared drive folder, a dashboard, a ticket). Returns 201 with a ResourceIdResponse (the new link's id). Note the path shape: this operation is scoped to the CLIENT, not to a request, so the target evidence request is identified by evidence_request_id INSIDE the body rather than in the URL. There is no documented idempotency key, so never blind-retry — a repeat adds a SECOND link. ScalePad publishes no update or delete operation for an evidence-request link on this API, so add them deliberately.

[ScalePad] PERMANENTLY delete ONE evidence request. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the request is not found. The parent evidence definition survives, but this request's status, due date, reviewer notes, uploaded documents and hyperlinks go with it, and ScalePad documents no soft delete, restore or undo. Confirm the exact client and the exact request (read the row back with scalepad_cm_list_client_evidence_requests, including its documents[] array) before calling. If the goal is only to take a request out of the active workflow while keeping its history, use scalepad_cm_archive_client_evidence_request instead; to mark it as not required, set status to Not Applicable with scalepad_cm_update_client_evidence_request.

[ScalePad] Partially update ONE evidence request for ONE client (HTTP PATCH). Only the properties you send change; everything else is left alone. Unusually for a PATCH this returns HTTP 204 with NO body (this tool returns ) — read the result back with scalepad_cm_list_client_evidence_requests if you need the updated row. This is the tool for reassigning a request, moving it through its status workflow, shifting its due date and recording reviewer notes. It does NOT attach evidence: use scalepad_cm_create_client_evidence_request_document (or the signed-URL sibling) for a file, or scalepad_cm_create_client_evidence_requests_links for a hyperlink.

[ScalePad] Get one framework objective (requirement) in full, for a single client and framework. Returns id, code, name, description (HTML), status, level1_code/level1_name and level2_code/level2_name (the requirement's place in the framework hierarchy), in_scope, type (clauses or controls), implementation_details (HTML), automated_test and automated_tested_on, current_maturity and target_maturity (each {id, name, description, score}), assessment_questions[] {id, code, title, answer}, audit_tests[] (each audit_name plus its evidence_requests[] with audit_result and a detailed_evaluation breakdown), plus created_at/updated_at. This fragment does not declare a 400, so an unknown id may surface as 404.

[ScalePad] For ONE client, by client id: the objective compliance roll-up for every framework that client has enabled. Returns client {id, name, tenant_id} and framework_stats[] where each entry is {id, name, objective_summary {compliant, not_compliant, partially_compliant, not_assessed, in_review, not_applicable, total, complaint_percentage}} — complaint_percentage is the vendor's own misspelling of compliant. There is no pagination envelope and no query surface. This is the tool that gives you the framework ids for scalepad_cm_search_client_framework_objectives. Use scalepad_cm_list_clients_framework_objectives_summary instead when you want the same roll-up for every client at once.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated objective roll-up for the whole client base, for partner-level compliance dashboards. Returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, framework_stats[] {id, name, objective_summary {compliant, not_compliant, partially_compliant, not_assessed, in_review, not_applicable, total, complaint_percentage}}}. Keep paging until next_cursor is null. For one client only, call scalepad_cm_get_client_framework_objectives_summary — it needs no paging.

[ScalePad] For ONE client and ONE framework: search that framework's objectives (requirements). This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted (vendor operationId 01_searchClientObjectives). Returns client {id, name, tenant_id}, framework {id, name}, objective_summary {compliant, not_compliant, partially_compliant, not_assessed, in_review, not_applicable, total, complaint_percentage — the misspelling is the vendor's own field name}, and objectives {total_count, next_cursor, data[]}. Each objective row carries id, code, name, description (HTML), status, level1_code/level1_name, level2_code/level2_name, in_scope, type (clauses or controls), created_at, updated_at and the linked documents/evidences. Use the row id with scalepad_cm_get_client_framework_objective for the full detail, and the row code as an objective_codes / objectives.codes value when mapping controls, policies, procedures, risks or action items.

[ScalePad] Create a governance document for ONE client. Returns 201 with the full ProcedureDetailResponse. ScalePad assigns the authenticated API user as both owner and creator, starts the document in status In Review, and sets the default review date one week after creation — you cannot override those in the create body; adjust them afterwards with scalepad_cm_update_client_governance. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_governance first. The create body takes no mappings you can rely on; link objectives, policies and controls afterwards with scalepad_cm_map_client_governance.

[ScalePad] PERMANENTLY delete a governance document. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the document is not found. ScalePad documents no soft delete, restore or undo for compliance documents, and the document's HTML body, attached files, hyperlinks, tags and its mappings to objectives/policies/controls go with it. Confirm the exact client and the exact document (read it back with scalepad_cm_get_client_governance first) before calling, and prefer moving it to a Draft status via scalepad_cm_update_client_governance when the goal is only to take it out of the active review workflow.

[ScalePad] Get ONE governance document in full for ONE client. Returns the ProcedureDetailResponse shape: id, code, title, description (the document's HTML body), source, status, frequency, owner and last_approved_by (each {id, name}), contributors[], data_classification, review_date, last_approved_date, created_at/updated_at, documents[{id, filename, signed_url, expires_at}], hyperlinks[{name, hyperlink}], tags[], controls[] and objectives[{id, title, code, program_name}]. The codes in controls[] and objectives[] are exactly the values scalepad_cm_map_client_governance and scalepad_cm_unmap_client_governance accept. Unlike policies there is NO sections[] array — a governance document's body is the single description field.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated governance-document roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}}. Keep paging until next_cursor is null. This tool returns COUNTS ONLY — it never lists individual governance documents; use scalepad_cm_search_client_governance with a client id for the document rows.

[ScalePad] LINK a governance document to the compliance entities it governs. For a governance document the linkable entities are framework objectives (requirements, scoped by compliance program), policies and controls — each identified by its BUSINESS CODE, never by numeric id, and resolved server-side. Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_governance for that). Read current links from the controls[] and objectives[] arrays of scalepad_cm_get_client_governance.

[ScalePad] For ONE client, by client id: search that client's governance documents. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted. Returns client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}, and governance {total_count, next_cursor, data[]}. Each row carries id, code (e.g. GOV-1), title, owner and created_by (each {id, name, email}), status, source (e.g. "html"), frequency, contributors[], data_classification, tags[], controls[{id, title, code}] and objectives[{id, title, code, program_name}]. For the whole client base use scalepad_cm_list_clients_governance_summary instead, which takes NO client id.

[ScalePad] UNLINK a governance document from objectives, policies or controls. The codes you send identify only the LINKS to remove — neither the governance document nor the mapped entities are deleted — but the relationship removal is a real state change with no undo, so echo the exact document and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes, so reject an all-empty request rather than sending it. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update a governance document (HTTP PATCH). Only the properties you send change; everything else is left alone. Returns 200 with the patched record (id, code, name, description, status, source, data_classification, frequency, owner and the rest of the document metadata). At least one field is required. When status is included the vendor applies it AFTER the other fields in the same request. tags and contributors REPLACE the current lists rather than appending — send an empty array to clear one. This is the tool for status transitions and for editing the HTML body. To change the document's LINKS to objectives, policies or controls use scalepad_cm_map_client_governance / scalepad_cm_unmap_client_governance instead; relationships are not patchable here.

[ScalePad] For ONE client, by client id: the full ControlMap compliance health snapshot. Returns a single object (no pagination envelope) carrying client {id, name, tenant_id}, compliance_score {overall_score, score_label, updated_at, trend {last_30_days, last_60_days, last_90_days}}, risk_score {overall_score, risk_level, updated_at, risk_breakdown {severe, high, medium, low}}, frameworks[] (each with framework_id, framework_name, compliance_score, score_label, compliance_breakdown {compliant, in_review, not_applicable, not_assessed, not_compliant, partially_compliant, compliance_achieved_percentage, total} and assessment_breakdown {yes, no, partially, not_answered, not_applicable, answering_percentage, total}), and work_progress {evidence {completed, review, in_progress, not_started, not_applicable, completion_percentage, total}, updated_at}. All scores reflect the most recently computed values, not a live recalculation. Use this when you need one client's complete snapshot; for several clients at once, scalepad_cm_list_clients_health with its fields parameter set returns the same components in a single paginated pass.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated compliance health for the whole client base: returns {data[], total_count, next_cursor} where next_cursor is null on the final page (keep paging until it is null, not until a page looks short). Each row carries client {id, name, tenant_id} plus that client's health metrics, and the client.id values are exactly what you pass to scalepad_cm_get_client_health and to every other per-client ControlMap tool. IMPORTANT: by default a row carries the client's OVERALL compliance health ONLY — the richer compliance_score, risk_score, frameworks and work_progress components are additive and must be requested through the fields parameter. Use fields to pull the metrics you need for the whole client base in one pass, rather than calling scalepad_cm_get_client_health once per client.

[ScalePad] Create a policy for ONE client, optionally with its initial sections in order. Returns 201 with the full PolicyDetailResponse. ScalePad assigns the authenticated API user as both owner and creator, starts the policy in status In Review, and sets the default review date one week after creation — you cannot override those in the create body; adjust them afterwards with scalepad_cm_update_client_policy. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_policies first. Link objectives and controls afterwards with scalepad_cm_map_client_policy; the create body takes no mappings.

[ScalePad] PERMANENTLY delete an entire policy, including ALL of its sections. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the policy is not found. ScalePad documents no soft delete, restore or undo for compliance documents, and the policy's sections, version history, attached files, hyperlinks, tags and its mappings to objectives/controls go with it. Confirm the exact client and the exact policy (read it back with scalepad_cm_get_client_policy first) before calling. If you only need to remove one part of the body use scalepad_cm_delete_client_policy_section instead; if you only need it out of the active review workflow, move it to a Draft status with scalepad_cm_update_client_policy.

[ScalePad] PERMANENTLY delete ONE section of a policy — the section's title and its entire HTML body are lost. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the policy or section is not found. The policy itself and its other sections survive; ScalePad documents no restore or undo for a deleted section, so read the section back with scalepad_cm_get_client_policy and echo its title (and, if the user may want it later, its description) before calling. To reword a section instead of losing it, update it in place with scalepad_cm_update_client_policy_sections.

[ScalePad] Get ONE policy in full for ONE client. Returns the PolicyDetailResponse shape: id, code, title, status, source, frequency, owner and last_approved_by (each {id, name}), policy_contributors[], data_classification, review_date, last_approved_date, created_at/updated_at, documents[{id, filename, signed_url, expires_at}], hyperlinks[{name, hyperlink}], tags[], versions[{major_version, minor_version}] plus the current major_version/minor_version, is_published, controls[{id, title, code}], objectives[{id, title, code, program_name}] and — uniquely for policies — sections[{id, title, description, section_order, created_at, updated_at}] holding the HTML body in order. sections[].id is the value scalepad_cm_update_client_policy_sections uses to update a section and scalepad_cm_delete_client_policy_section uses to remove one; the control and objective codes are what the mapping tools accept.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated policy roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}}. Keep paging until next_cursor is null. This tool returns COUNTS ONLY — it never lists individual policies; use scalepad_cm_search_client_policies with a client id for the document rows.

[ScalePad] LINK a policy to the compliance entities it satisfies. For a policy the linkable entities are exactly TWO kinds: framework objectives (requirements, scoped by compliance program) and controls — identified by BUSINESS CODE, never by numeric id, and resolved server-side. There is deliberately no policy_codes array here (policies do not map to other policies) even though the procedure and governance mapping bodies have one. Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_policy for that). Read current links from the controls[] and objectives[] arrays of scalepad_cm_get_client_policy.

[ScalePad] For ONE client, by client id: search that client's policies. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted. Returns client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}, and policies {total_count, next_cursor, data[]}. Each row carries id, code (e.g. POL-1), title, owner and created_by (each {id, name, email}), status, source (e.g. "html"), frequency, contributors[], data_classification, tags[], controls[{id, title, code}] and objectives[{id, title, code, program_name}]. The search rows do NOT include sections — fetch a single policy with scalepad_cm_get_client_policy for its section bodies. For the whole client base use scalepad_cm_list_clients_policies_summary instead, which takes NO client id.

[ScalePad] UNLINK a policy from objectives or controls. The codes you send identify only the LINKS to remove — neither the policy nor the mapped objectives/controls are deleted — but the relationship removal is a real state change with no undo, so echo the exact policy and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes, so reject an all-empty request rather than sending it. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update a policy's METADATA (HTTP PATCH). Only the properties you send change; everything else is left alone. Returns 200 with the patched record (id, code, name, status, source, data_classification, frequency, owner and the rest of the document metadata). When status is included the vendor applies it AFTER the other fields in the same request. tags and contributors REPLACE the current lists rather than appending — send an empty array to clear one. IMPORTANT: unlike procedures and governance documents the policy PATCH schema has NO description field — a policy's prose lives in its sections, so use scalepad_cm_update_client_policy_sections to change the body. Relationships are likewise not patchable here; use scalepad_cm_map_client_policy / scalepad_cm_unmap_client_policy.

[ScalePad] Create OR update a single section of a policy — an upsert (HTTP PUT on the sections collection), and the ONLY way to edit a policy's prose, because the policy PATCH schema has no description field. Which operation happens is decided by whether the body carries an id: omit id to CREATE a new section (returns 201) and include id to UPDATE an existing one (returns 200). Either way the response is the PolicySectionDetail for that one section (id, title, description, section_order, created_at, updated_at). Sections are the only sectioned record type in ControlMap — procedures and governance documents have none. This tool handles ONE section per call; loop for several. Read the current sections, their ids and their section_order from scalepad_cm_get_client_policy.

[ScalePad] Create a procedure for ONE client. Returns 201 with the full ProcedureDetailResponse. ScalePad assigns the authenticated API user as both owner and creator, starts the document in status In Review, and sets the default review date one week after creation — you cannot override those in the create body; adjust them afterwards with scalepad_cm_update_client_procedure. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_procedures first. Link objectives, policies and controls afterwards with scalepad_cm_map_client_procedure rather than trying to embed them here.

[ScalePad] PERMANENTLY delete a procedure. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the procedure is not found. ScalePad documents no soft delete, restore or undo for compliance documents, and the procedure's HTML body, attached files, hyperlinks, tags and its mappings to objectives/policies/controls go with it. Confirm the exact client and the exact procedure (read it back with scalepad_cm_get_client_procedure first) before calling, and prefer moving it to a Draft status via scalepad_cm_update_client_procedure when the goal is only to take it out of the active review workflow.

[ScalePad] Get ONE procedure in full for ONE client. Returns the ProcedureDetailResponse shape: id, code, title, description (the procedure's HTML body), source, status, frequency, owner and last_approved_by (each {id, name}), contributors[], data_classification, review_date, last_approved_date, created_at/updated_at, documents[{id, filename, signed_url, expires_at}], hyperlinks[{name, hyperlink}], tags[], controls[] and objectives[{id, title, code, program_name}]. The codes in controls[] and objectives[] are exactly the values scalepad_cm_map_client_procedure and scalepad_cm_unmap_client_procedure accept. Unlike policies there is NO sections[] array — a procedure's body is the single description field.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated procedure roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}}. Keep paging until next_cursor is null. This tool returns COUNTS ONLY — it never lists individual procedures; use scalepad_cm_search_client_procedures with a client id for the document rows.

[ScalePad] LINK a procedure to the compliance entities it implements. For a procedure the linkable entities are framework objectives (requirements, scoped by compliance program), policies and controls — each identified by its BUSINESS CODE, never by numeric id, and resolved server-side. Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_procedure for that). Read current links from the controls[] and objectives[] arrays of scalepad_cm_get_client_procedure.

[ScalePad] For ONE client, by client id: search that client's procedures. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted. Returns client {id, name, tenant_id}, documents_summary {approved, in_review, ready_for_approval, in_progress, draft, approved_percentage, total}, and procedures {total_count, next_cursor, data[]}. Each row carries id, code (e.g. PRO-1), title, owner and created_by (each {id, name, email}), status, source (e.g. "html"), frequency, contributors[], data_classification, tags[], controls[{id, title, code}] and objectives[{id, title, code, program_name}]. For the whole client base use scalepad_cm_list_clients_procedures_summary instead, which takes NO client id.

[ScalePad] UNLINK a procedure from objectives, policies or controls. The codes you send identify only the LINKS to remove — neither the procedure nor the mapped entities are deleted — but the relationship removal is a real state change with no undo, so echo the exact procedure and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes, so reject an all-empty request rather than sending it. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update a procedure (HTTP PATCH). Only the properties you send change; everything else is left alone. Returns 200 with the patched record (id, code, name, description, status, source, data_classification, frequency, owner and the rest of the document metadata). When status is included the vendor applies it AFTER the other fields in the same request. tags and contributors REPLACE the current lists rather than appending — send an empty array to clear one. This is the tool for status transitions and for editing the HTML body. To change the procedure's LINKS to objectives, policies or controls use scalepad_cm_map_client_procedure / scalepad_cm_unmap_client_procedure instead; relationships are not patchable here.

[ScalePad] Mint a short-lived DOWNLOAD url for one finished ControlMap report. Returns JSON only — {id, name, signed_url, expires_in_seconds} (3600 in the vendor example) — never the file bytes, and no StackJack blob storage is involved anywhere in ControlMap. Fetch signed_url directly before expires_in_seconds elapses; it is already authorized, so do NOT attach the ScalePad x-api-key to that request. The URL is single-purpose and time-limited: re-run this tool for a fresh one rather than caching it. A report still in Progress or Fail status has no downloadable document.

[ScalePad] For ONE client, by client id: list that client's generated ControlMap reports. This is a READ despite using HTTP POST — the verb only exists to carry the filter/paging body, and nothing is created (vendor operationId 01_listClientReports). Returns client {id, name, tenant_id}, report_summary {total, progress, completed, failed}, and reports {total_count, next_cursor, data[]} where each row carries id, report_name, program, created_by {id, name, email}, created_at and status. The row id is the report_id you pass to scalepad_cm_get_client_report_signed_url to obtain a download link.

[ScalePad] Create a risk in ONE client's register. Returns 201 with the full RiskResponse, including the code ScalePad assigns (RSK-nn) and the inherent/current/target scores it derives from impact and likelihood. name is the ONLY schema-required property. Watch the field vocabulary: create uses name and risk_category, whereas scalepad_cm_update_client_risk uses title and category for the same two values — do not carry names across. There is no documented idempotency key, so never blind-retry this call — re-check with scalepad_cm_search_client_risks first. Link assets, threats, vulnerabilities, vendors, objectives, controls or action items afterwards with scalepad_cm_map_client_risk; the create body takes no mappings.

[ScalePad] PERMANENTLY delete a risk from a client's register. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the risk is not found. ScalePad's own changelog states that risk deletion removes the record AND all associated data — its mappings to assets, threats, vulnerabilities, vendors, objectives, controls and action items go with it — and documents no soft delete, restore or undo. Confirm the exact client and the exact risk (read it back with scalepad_cm_get_client_risk first) before calling, and prefer setting status to Closed via scalepad_cm_update_client_risk when the goal is only to retire the risk while keeping its history.

[ScalePad] Get ONE risk in full for ONE client. Returns the RiskResponse shape: id, code (e.g. RSK-1), name, description, owner and created_by (each {id, name}), status, department, risk_category, treatment, business_impact, inherent_risk_score and inherent_risk_label, current_risk_score and current_risk_label, target_risk_score and target_risk_label, created_at and updated_at. The score labels are ControlMap's own bands (e.g. Severe, High, Medium, Low) derived from impact × likelihood — they are computed, not settable directly.

[ScalePad] Get ONE risk category by id for ONE client. Returns a minimal RiskCategoryResponse — exactly {id, name}, e.g. {"id":35,"name":"Access Control"} — and 404 NOT_FOUND ("No risk category exists with ID ...") when the id is unknown. ScalePad publishes NO list-categories endpoint on this API, so the only way to discover a category id is from a risk that already uses it: the risk_category NAME appears on every row of scalepad_cm_search_client_risks. Use this tool to resolve a category id you already hold back to its display name.

[ScalePad] For ONE client, by client id: list the departments available for risk assignment. Returns a bare JSON ARRAY of {id, name} objects (e.g. [{"id":1,"name":"IT"},{"id":2,"name":"Sales"}]) — not a paginated envelope, and this endpoint takes no page_size, cursor, sort or filter parameters at all. Call this first to get the exact department NAME string to send in the department field of scalepad_cm_create_client_risk or scalepad_cm_update_client_risk; ScalePad resolves that field by name, so a typo is rejected rather than created.

[ScalePad] Across EVERY client of the MSP — takes NO client id. Cursor-paginated risk-posture roll-up for the whole client base: returns {data[], total_count, next_cursor} where each row is {client {id, name, tenant_id}, risk_summary {overall_score, risk_level, updated_at, risk_breakdown {severe, high, medium, low}}}. Keep paging until next_cursor is null. This tool returns SCORES AND COUNTS ONLY — it never lists individual risks; use scalepad_cm_search_client_risks with a client id for the risk rows.

[ScalePad] LINK a risk to the entities that expose it or mitigate it. A risk has the widest set of linkable entities in ControlMap — eight arrays: assets and asset types, threats, vulnerabilities, vendors, framework objectives (requirements), controls and action items — each identified by its BUSINESS CODE (asset types by NAME), never by numeric id, and resolved server-side. Succeeds with HTTP 204 and no body (this tool returns ). Only the non-empty arrays you send are applied; empty or omitted arrays are ignored, so a body with no codes is accepted but does nothing — send at least one populated array. Mapping is additive: it never removes existing links (use scalepad_cm_unmap_client_risk for that).

[ScalePad] For ONE client, by client id: search that client's risk register. This is a READ despite using HTTP POST — the verb only carries the query body and nothing is persisted; it replaced the retired GET /risks list route. Returns client {id, name, tenant_id}, an aggregate risk_summary {overall_score, risk_level, updated_at, risk_breakdown {severe, high, medium, low}}, and risks {total_count, next_cursor, data[]}. Each row carries id, code (e.g. RSK-1), name, description, owner and created_by (each {id, name, email}), status, department, risk_category, treatment, business_impact, inherent_risk_score/label, current_risk_score/label, target_risk_score/label and timestamps. For the whole client base use scalepad_cm_list_clients_risks_summary instead, which takes NO client id.

[ScalePad] UNLINK a risk from assets, asset types, threats, vulnerabilities, vendors, objectives, controls or action items. The codes you send identify only the LINKS to remove — neither the risk nor the mapped entities are deleted — but the relationship removal is a real state change with no undo, so echo the exact risk and every code back to the user before calling. Succeeds with HTTP 204 and no body (this tool returns ); empty or omitted arrays make no changes, so reject an all-empty request rather than sending it. Despite the HTTP POST verb this is a removal: the vendor path is .../mappings/bulk-delete.

[ScalePad] Partially update a risk (HTTP PATCH). Only the properties you send change; everything else is left alone. Returns 200 with the patched RiskResponse. Every property is optional here — including name/title, which create requires. Watch the field vocabulary: PATCH spells the risk title title and the category category, whereas scalepad_cm_create_client_risk spells the same two values name and risk_category. The PATCH schema does NOT expose impact, likelihood, treatment or business_impact, so the derived risk scores cannot be changed through this tool. To change a risk's LINKS to assets, threats, vulnerabilities, vendors, objectives, controls or action items use scalepad_cm_map_client_risk / scalepad_cm_unmap_client_risk instead; relationships are not patchable here.

[ScalePad] Get one client organization by its ScalePad id (from scalepad_core_list_clients). Returns id, name, lifecycle, primary_domain, num_contacts, num_hardware_assets, address (ISO-standardized country/state plus geo-spatial coordinates where available), record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible — it does not by itself distinguish a source-system deletion from integration sync lag.

[ScalePad] List the MSP's active client organizations. Cursor-paginated: returns data[], total_count, and next_cursor (present and null on the final page — keep paging until it is null, not until a page is short). Each client carries id, name, lifecycle, primary_domain (derived from its contacts), num_contacts, num_hardware_assets, address, record_lineage[] (the source PSA/RMM integration and source_record_id behind the normalized record), record_created_at, and record_updated_at. The returned id is the value you pass to scalepad_core_get_client and to filter[client.id] on nearly every other Core list tool (hardware assets, SaaS assets, contacts, tickets, contracts, sites, opportunities).

[ScalePad] Get one client contact by its ScalePad id (from scalepad_core_list_contacts). Returns id, client (the owning client organization), title, contact_info (primary communication details), name, record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible.

[ScalePad] Get one MSP member by its ScalePad id (from scalepad_core_list_members). Returns id, name, hired_at, title, is_scalepad_user, contact_info, reports_to_member (including their email), work_roles[], hourly_cost, daily_capacity, address, record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible.

[ScalePad] Search the active contacts (individuals) at the MSP's client organizations. The HTTP verb is POST, but this is a SEARCH and changes nothing — ScalePad uses a request body only so the PII-sensitive filters stay out of the query string. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each contact carries id, client, title, contact_info, name, record_lineage[], record_created_at, and record_updated_at. Pass a returned id to scalepad_core_get_contact, or use it as filter[contact.id] on hardware assets, SaaS users, tickets, contracts, and opportunities.

[ScalePad] Search the MSP's own active members — employees, contractors, downstream IT. The HTTP verb is POST, but this is a SEARCH and changes nothing: ScalePad uses a request body only so the PII-sensitive filters (email, phone, full name, manager email) stay out of the query string. Cursor-paginated: returns data[], total_count, and next_cursor. Each member carries id, name, hired_at, title, is_scalepad_user (whether they are a ScalePad platform user), contact_info, reports_to_member, work_roles[], hourly_cost (the member's default cost per hour to the MSP), daily_capacity (available working hours per day), address, record_lineage[], record_created_at, and record_updated_at. Pass a returned id to scalepad_core_get_member, or use it as filter[owner_member.id] / filter[responsible_member.id] on tickets and opportunities.

[ScalePad] Get one hardware asset by its ScalePad id (from scalepad_core_list_hardware_assets). Returns the full record: name, client, contact, manufacturer, model, serial_number, type, last_login_user, location_name, mac_addresses[], configuration (cpu / ram_bytes / disks), software (operating_system, antivirus_info, office_suite_info), address (ISO-standardized country/state plus geo-spatial coordinates where available), record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List active hardware assets across the MSP's clients. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each asset carries id, name, client, contact (the assigned user), manufacturer (ScalePad-standardized), model, serial_number, type (WORKSTATION | IMAGING | SERVER | NETWORK | MOBILE | VIRTUAL), last_login_user, location_name, mac_addresses[], configuration (cpu name/manufacturer, ram_bytes, disks total_bytes/used_bytes), software (operating_system, antivirus_info status + definition_status, office_suite_info name/version), address, record_lineage[], record_created_at, and record_updated_at. Use filter[client.id] with an id from scalepad_core_list_clients to scope to one client; pass a returned asset id to scalepad_core_get_hardware_asset.

[ScalePad] List the MSP's configured integration instances — one entry per connected PSA/RMM/SaaS setup. Each carries id, vendor (the integration vendor it belongs to), nickname (the operator-facing label that distinguishes multiple instances of the same vendor), and primary[] (the datatypes for which this instance is the primary integration; empty when it is not primary for anything). The id here is what appears as record_lineage.integration_configuration.id on client, contact, asset, ticket, contract and site records, and is the value to pass as filter[record_lineage.integration_configuration.id] on those list tools. ScalePad documents NO parameters on this operation — no pagination, filtering or sorting — so it returns the full set in one response.

[ScalePad] List the catalogue of third-party vendors and platforms ScalePad can integrate with — the lookup behind record_lineage.integration_configuration.vendor on every Core record. Unlike the other Core list operations this one returns a BARE JSON ARRAY of vendors rather than the {data, total_count, next_cursor} envelope, so there is no cursor to follow even though page_size and cursor are accepted. Vendors are grouped by category: PSA, RMM, SaaS, Network, Documentation, Backup, Customer Satisfaction, Cybersecurity, PSA & RMM. Note that ScalePad removed filter[data_types_supported] in the 2026-07-21 Core release while keeping the response field — filter on it and expect a 400/422. This operation can return 422 for a semantically invalid filter in addition to the usual 400.

[ScalePad] Get one sales opportunity by its ScalePad id (from scalepad_core_list_opportunities). Returns id, title, description, source_status, source_stage, is_active, probability (0-100), client, contact, responsible_member, record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List sales opportunities for the MSP's active clients. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each opportunity carries id, title, description, source_status and source_stage (the ORIGINAL values from the source system, before any ScalePad standardization — so the valid values depend on the connected PSA/CRM), is_active, probability (percent 0-100 that it closes won), client, contact, responsible_member (the MSP member accountable for it), record_lineage[], record_created_at, and record_updated_at. Use filter[client.id] with an id from scalepad_core_list_clients, or filter[responsible_member.id] with an id from scalepad_core_list_members.

[ScalePad] Get one product catalog record by its ScalePad id (from scalepad_core_list_product_catalog). Returns id, source_system, source_product_id, source_product_identifier, name, description, category, subcategory, product_type, product_class, manufacturer_name, unit_cost, unit_price, is_active, updated_at, record_lineage[], record_created_at, and record_updated_at. Every field except id and source_system is nullable — PSAs expose different subsets. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List the product catalog records exported from the MSP's PSA integrations. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each record carries id, source_system (the PSA that supplied it), source_product_id, source_product_identifier (the human-facing product code/SKU, used to match related source records such as PSA contract additions), name, description, category, subcategory, product_type, product_class, manufacturer_name, unit_cost, unit_price, is_active, updated_at (the SOURCE product's last-updated timestamp, distinct from ScalePad's own record_updated_at), record_lineage[], record_created_at, and record_updated_at. The id is what appears as contract_pricings.items.product.id on contracts — see scalepad_core_list_contracts.

[ScalePad] Get one SaaS asset by its ScalePad id (from scalepad_core_list_saas_assets). Returns id, client, product, status, tenant_domain, term, subscriptions[], pool (type / capacity / utilized / suspended / grace_period_warning), record_lineage[], record_created_at, and record_updated_at. A 404 means the normalized record is missing or inaccessible.

[ScalePad] Get one SaaS user by its ScalePad id (from scalepad_core_list_saas_users). Returns id, client, contact, asset, product, term, subscription, activity (last_active_at, is_active), authentication (is_mfa_enabled, default_mfa_method), is_admin, record_lineage[], record_created_at, and record_updated_at. Activity fields are only populated when the SaaS vendor supplies them. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List the SaaS assets (cloud subscriptions and licence pools) tracked for the MSP's clients. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each asset carries id, client, product (manufacturer, name, category, manufacturer_sku), status (the raw source lifecycle/availability value), tenant_domain (the Microsoft 365 tenant's default verified domain), term (starts_at / ends_at / is_auto_renewed), subscriptions[] (per-subscription id, commerce_subscription_id, status, type, license_count, billing_cycle_name, friendly_name, provider_name, partner_tier, csp_tier and its own term), pool (type SEAT, capacity, utilized, suspended, grace_period_warning), record_lineage[], record_created_at, and record_updated_at. Note pool.active was REMOVED from the response, filters and sorting in the 2026-07-21 Core release. Pass a returned id to scalepad_core_get_saas_asset, or use it as filter[asset.id] on scalepad_core_list_saas_users to see who holds the licences.

[ScalePad] List the SaaS users — the individuals at client organizations who hold an assigned SaaS licence. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each user carries id, client, contact (the Core contact they map to), asset (id + status of the SaaS asset the licence belongs to), product, term, subscription (the selected Microsoft subscription for this SKU row), activity (last_active_at, is_active — only when the vendor supplies it), authentication (is_mfa_enabled, default_mfa_method), is_admin, record_lineage[], record_created_at, and record_updated_at. This is the surface for licence-waste and MFA-gap reporting: combine filter[activity.is_active]=eq:false with filter[asset.id], or filter[authentication.is_mfa_enabled]=eq:false with filter[is_admin]=eq:true.

[ScalePad] Get one service contract by its ScalePad id (from scalepad_core_list_contracts). Returns the full record including term, status, type, total_price / total_cost, pricing_item_total_price / pricing_item_total_cost, and contract_pricings[] with each line's product, term, unit_cost, unit_price, total_cost and total_price — ACTIVE pricing lines only. total_cost and is_addendum are populated only for ConnectWise-sourced contracts. A 404 means the normalized record is missing or inaccessible.

[ScalePad] Get one service ticket by its ScalePad id (from scalepad_core_list_tickets). Returns the full record including owner_member, responsible_member, client, contact, contract, board, summary, source, category, is_child_ticket, is_long_ticket, timeline, duration (per-stage minutes, excluding time-off / non-working days / wait time), sla, status (current plus transition history), priority (current plus change history with timestamps), impact, severity, num_notes, record_lineage[], record_created_at, and record_updated_at. Ticket note bodies are not part of this response — only num_notes. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List the service contracts between the MSP and its active clients. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each contract carries id, name, description, client, contact, is_recurring, type (MANAGED_SERVICES | BLOCK | 3RD_PARTY | UNASSIGNED), term (starts_at, ends_at, is_auto_renew, billing_period: NOT_BILLED | ONE_TIME | ANNUAL | SEMI_ANNUAL | QUARTERLY | BI_MONTHLY | MONTHLY | BI_WEEKLY | WEEKLY | OTHER), source_type (the raw pre-standardization type), is_addendum, parent_contract, status (SUSPENDED | EXPIRED | ACTIVE | DRAFT | SENT | SIGNED | NOT_EXECUTED | CANCELLED), total_price, total_cost, is_billable, pricing_item_total_price, pricing_item_total_cost, contract_pricings[] (ACTIVE pricing lines only — expired lines are not returned), record_lineage[], record_created_at, and record_updated_at. Vendor-specific caveats: for ConnectWise total_price is the Bill Amount plus Additions, and total_cost / is_addendum are supported ONLY by ConnectWise (null for every other source system). Pass a returned id to scalepad_core_get_contract, or use it as filter[contract.id] on scalepad_core_list_tickets.

[ScalePad] List normalized service tickets across the MSP's clients. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each ticket carries id, owner_member (accountable) and responsible_member (who resolved it), client, contact, contract, board (the workflow queue), summary, source (the channel it came in on), category (a large ScalePad-standardized enum spanning the INCIDENT and SERVICE_REQUEST families plus IT_MANAGEMENT, CYBERSECURITY_MANAGEMENT, DISASTER_RECOVERY, DOCUMENTATION_TRAINING, USER_MANAGEMENT, AUDIT and GENERAL_MANAGEMENT groups, falling back to the MSP's own unmapped categories and UNASSIGNED), is_child_ticket, is_long_ticket (resolved in more than one standard deviation above the account/category baseline), timeline (created_at, updated_at, responded_at, planned_at, resolved_at, closed_at), duration (per-stage metrics in MINUTES, already adjusted to exclude account time-off, non-working days and wait time), sla (is_response_in_sla, is_plan_in_sla, is_resolution_in_sla), status (current plus a full transition history), priority (current plus history), impact, severity, num_notes, record_lineage[], record_created_at, and record_updated_at.

[ScalePad] Get one client site by its ScalePad id (from scalepad_core_list_sites). Returns id, name, client, address, and record_lineage[] — a site record carries no created/updated timestamps. A 404 means the normalized record is missing or inaccessible.

[ScalePad] List client sites materialized from the source PSA's location data. Cursor-paginated: returns data[], total_count, and next_cursor (null on the final page). Each site carries only id, name, client (the owning client organization), address (the site's postal address), and record_lineage[] — unlike every other Core resource there are NO record_created_at / record_updated_at timestamps on a site, so incremental polling by timestamp is not possible here. Use filter[client.id] with an id from scalepad_core_list_clients to return one client's sites; pass a returned site id to scalepad_core_get_site. This operation documents no sort parameter.

[ScalePad] Get the AUTHENTICATED user behind the API key, together with that user's feature access and permissions — the practical way to find out what this credential can actually do before attempting a write. Takes no parameters. Returns {user, feature_access[], feature_permissions[]}: user is {id, label, email, is_deleted}; each feature_access entry is a discriminated union on its type field — NoAccess and FullAccess and LimitedAccess — carrying feature_key, is_feature_released, plus licensed_clients[] {id, label} on FullAccess or feature_access_client, number_of_unlocks, max_number_of_unlocks and action_needed_for_full_access on LimitedAccess. feature_permissions[] mirrors that union but renames the two leading fields: feature_permission_key and has_permission instead of feature_key and is_feature_released — read each array with its own field names. The public schema does not name granular roles, so treat a runtime 403 as authoritative rather than inferring permissions from UI role names.

[ScalePad] Read back one blob of persisted UI preferences for the AUTHENTICATED user, scoped to the current account, under a caller-chosen state key. This is opaque per-user interface state — column widths, collapsed groups, a saved roadmap layout — not business data and not shared with anyone else: it tells you nothing about clients, assets or entitlements. Returns {payload, updated_at}, where payload is the JSON document previously stored as a STRING. Alone among the responses in this pack this schema declares NO required fields, so treat both payload and updated_at as possibly absent; the vendor does not document how an unset key behaves, so handle an empty response and a 404 as equally plausible rather than assuming one. Written by scalepad_lm_set_user_ui_state.

[ScalePad] List ONE client's renewable warranty assets and the monthly pricing options available for each. Cursor-paginated: returns {data[], total_count, next_cursor}. Each row is {id, client {id, label}, hardware_asset_id, name, warranty_type, device_type, manufacturer, model, serial_number, is_warranty_information_blurred, warranty_expiration_date, age_in_years, renewal_start_date, is_continuous_renewal_policy_applied, pricing_options[]}, and each pricing option is {id, name, monthly_unit_price_usd_subunits, dynamic_monthly_unit_prices_by_total_coverage_years, is_preferred}. Two things to get right when quoting these numbers: prices are in US-dollar SUBUNITS, so 825 means $8.25 per month, and dynamic_monthly_unit_prices_by_total_coverage_years is a map from total coverage years to that same subunit price (e.g. {"1":825,"2":742,"3":658}); and for assets whose device_type is Server the vendor states the price is an ESTIMATE, not a firm quote. is_preferred marks the option matching the client's preferred service level for that device type, and is_warranty_information_blurred means the date and age fields are withheld for that asset.

[ScalePad] List the users belonging to the authenticated ScalePad account — the MSP's own staff, not client contacts (for those see scalepad_lm_list_contacts). Takes no parameters and returns {data[]} only: no paging envelope, no filters, no sort. Each user is {user_id, first_name, last_name, email, is_email_bouncing, status}, where the schema's documented status values are Confirmed, Invited, SignedUp, Disabled, Deleted and Canceled — note the vendor calls this the ACTIVE users list yet declares those inactive states on the field, so read status rather than assuming every row is usable. This is the lookup for any user_id a write needs: notably evaluate_user_id on scalepad_lm_create_assessment and scalepad_lm_update_assessment, and the assignee ids/emails on scalepad_lm_create_action_item and scalepad_lm_update_action_item.

[ScalePad] List the whole insights board for the account — every insight applicable to the caller, FLATTENED across its categories (the vendor names High-risk, Hardware modernization, Software modernization, Warranty coverage, Backup monitoring, Windows 11 upgrades, Security, and user-defined). Takes no parameters and returns {data[]} only: no total_count, no next_cursor, no filters, no sort. Each entry is {insight_id, title, description, affected_count, trend_value, risk_level, category, category_label, asset_scope, state, is_pro_insight}. affected_count is the current broken-asset count and trend_value the 30-day change in it — trend_value is NULL when trend data is unavailable OR the caller's plan does not include trend access, so a null there is not necessarily 'no change'. risk_level and category are documented only by example (risk_level e.g. High or Low; category e.g. HighRisk or HardwareModernization, with category_label the display form), as is asset_scope (e.g. Hardware, Software, Contact, DeviceBackup); state is explicitly one of normal, success, prerequisite or initializing. is_pro_insight flags an insight that requires a Pro plan. Do not treat the example values as a closed enum.

[ScalePad] Persist one blob of UI preferences for the AUTHENTICATED user under a state key, scoped to the current account. This stores opaque per-user interface state only — the vendor's example is a saved roadmap layout — and changes no business data whatsoever: it does not affect clients, assets, initiatives, permissions or what any other user sees. The PUT REPLACES any prior payload for the same key; it is not a merge, so read the current value with scalepad_lm_get_user_ui_state and resend the parts that should survive. Succeeds with HTTP 204 and no body (this tool returns ). ScalePad publishes no way to list or delete keys, so a key written with a typo is effectively permanent clutter — reuse a key you have already read back.

[ScalePad] LINK an existing ACTION ITEM to a GOAL, so the task counts toward that objective's progress. Parent = the goal; child = the action item. Both must already exist — this creates no records — and the action item MUST belong to the SAME CLIENT as the goal or the call is rejected. Succeeds with HTTP 200 and no body (this tool returns ). Confirm the resulting link with scalepad_lm_list_goal_action_items, and see the action item's own goal_links[] via scalepad_lm_get_action_item. This is the GOAL attach: use scalepad_lm_attach_initiative_action_item for an initiative and scalepad_lm_attach_meeting_action_item for a meeting.

[ScalePad] LINK an existing ACTION ITEM to an INITIATIVE, aligning the task with that implementation effort. Parent = the initiative; child = the action item. Both must already exist, and the action item should belong to the SAME CLIENT as the initiative. Succeeds with HTTP 200 and no body (this tool returns ). Verify with scalepad_lm_list_initiative_action_items; the action item's own view of the link is its initiative_links field on scalepad_lm_get_action_item — note that field is a single nullable object, not an array. This is the INITIATIVE attach: use scalepad_lm_attach_goal_action_item for a goal and scalepad_lm_attach_meeting_action_item for a meeting.

[ScalePad] LINK an existing ACTION ITEM to a MEETING, so the task appears as a discussion topic or tracked deliverable of that meeting. Parent = the meeting; child = the action item. Both must already exist, and the action item MUST belong to the SAME CLIENT as the meeting. Succeeds with HTTP 200 and no body (this tool returns ). Verify with scalepad_lm_list_meeting_action_items, or read the action item's meeting_links[] via scalepad_lm_get_action_item. This is the MEETING attach: use scalepad_lm_attach_goal_action_item for a goal and scalepad_lm_attach_initiative_action_item for an initiative.

[ScalePad] Create a new Lifecycle Manager action item for a client. Returns HTTP 200 with — that id is the same value the read tools expose as engagement_action_id. The create body takes NO link fields: to tie the new task to a goal, an initiative or a meeting, call scalepad_lm_attach_goal_action_item / _attach_initiative_action_item / _attach_meeting_action_item afterwards. ScalePad documents no idempotency-key header for this operation, so never blind-retry it — re-check with scalepad_lm_list_action_items filtered on the client first.

[ScalePad] PERMANENTLY delete an action item that is no longer relevant. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the item is missing or inaccessible. ScalePad documents no soft delete, restore or undo for this operation, so resolve and echo the exact item back to the user first — read it with scalepad_lm_get_action_item. When the intent is only to take a task out of the active workload, prefer scalepad_lm_update_action_item_completion_status with is_completed true, which keeps the record and its history. To break a task's link to a goal, initiative or meeting WITHOUT destroying the task, use the matching detach tool instead — those leave the action item intact.

[ScalePad] UNLINK an ACTION ITEM from a GOAL. This removes only the LINK — neither the goal nor the action item is deleted, and the action item stays in the system (it simply no longer appears under that goal). There is no undo for the relationship removal, so echo the exact goal and action item back to the user first; read the current links with scalepad_lm_list_goal_action_items. Succeeds with HTTP 204 and no body (this tool returns ). If the goal is that the TASK should cease to exist, that is scalepad_lm_delete_action_item, not this tool.

[ScalePad] UNLINK an ACTION ITEM from an INITIATIVE. This removes only the LINK — neither the initiative nor the action item is deleted, and the action item remains in the system, just no longer aligned to that initiative. The relationship removal has no undo, so echo the exact initiative and action item back to the user first; read the current links with scalepad_lm_list_initiative_action_items. Succeeds with HTTP 204 and no body (this tool returns ). To destroy the TASK itself use scalepad_lm_delete_action_item instead.

[ScalePad] UNLINK an ACTION ITEM from a MEETING. This removes only the LINK — neither the meeting nor the action item is deleted; the task continues to exist independently of the meeting. The relationship removal has no undo, so echo the exact meeting and action item back to the user first; read the current links with scalepad_lm_list_meeting_action_items. Succeeds with HTTP 204 and no body (this tool returns ). To destroy the TASK itself use scalepad_lm_delete_action_item; to remove a PERSON from the meeting use scalepad_lm_delete_meeting_attendee_contacts.

[ScalePad] Get ONE Lifecycle Manager action item in full by its id, including its linked entities. Returns the same record shape as scalepad_lm_list_action_items: client {id, label}, engagement_action_id, description, description_json, due_at, is_completed, is_pinned, created_at, completed_at, assigned_user_ids (user-id strings), ticket_link_state ({ticket_link_id, type} where type is Created | Pending | Error, plus ticket_link {ticket_number, external_url} once Created), initiative_links (one nullable object, not an array), meeting_links[] {meeting_link_id, meeting_id, meeting_title}, goal_links[] {link_id, goal_id, title, period, status}, created_by_user_id and sort_rank. Use this to hydrate the bare ids returned by scalepad_lm_list_goal_action_items, scalepad_lm_list_initiative_action_items and scalepad_lm_list_meeting_action_items.

[ScalePad] List Lifecycle Manager action items across every client the caller can access. Cursor-paginated: returns {data[], total_count, next_cursor} — keep paging until next_cursor is null, not until a page is short. Each row carries client {id, label}, engagement_action_id, description, description_json (the ProseMirror rich-text document), due_at, is_completed, is_pinned, created_at, completed_at, assigned_user_ids, ticket_link_state, initiative_links, meeting_links[], goal_links[], created_by_user_id and sort_rank. Two vendor shapes to expect: assigned_user_ids is an array of plain user-id STRINGS on read (the create body reuses that name for an array of {id|email} objects), and initiative_links is a SINGLE nullable OBJECT {initiative_link_id, initiative_id, initiative_name} despite its plural name, while meeting_links[] and goal_links[] are real arrays. The id to pass to scalepad_lm_get_action_item / update / delete is engagement_action_id (the create call, confusingly, returns it as ). This is the only action-item read that returns full records: the goal/initiative/meeting list tools return ids only.

[ScalePad] For ONE GOAL, list the ACTION ITEMS linked to it — the tasks that contribute toward achieving that objective. Takes a GOAL id, not an initiative or meeting id. Returns {action_item_ids: [...]} — bare ids ONLY, with no titles, assignees, due dates or paging envelope; hydrate each one with scalepad_lm_get_action_item, or list full records for the whole client with scalepad_lm_list_action_items. This is the goal family: the initiative and meeting equivalents are scalepad_lm_list_initiative_action_items and scalepad_lm_list_meeting_action_items.

[ScalePad] For ONE INITIATIVE, list the ACTION ITEMS aligned to it — the tasks required to carry that implementation effort out. Takes an INITIATIVE id, not a goal or meeting id. Returns {action_item_ids: [...]} — bare ids ONLY, no records and no paging envelope; hydrate each with scalepad_lm_get_action_item. This is the initiative family: the goal and meeting equivalents are scalepad_lm_list_goal_action_items and scalepad_lm_list_meeting_action_items.

[ScalePad] For ONE MEETING, list the ACTION ITEMS created during or linked to it — the follow-ups arising from that client discussion. Takes a MEETING id, not a goal or initiative id. Returns {action_item_ids: [...]} — bare ids ONLY, no records and no paging envelope; hydrate each with scalepad_lm_get_action_item. This is the meeting family: the goal and initiative equivalents are scalepad_lm_list_goal_action_items and scalepad_lm_list_initiative_action_items. (Meeting ATTENDEES are a different resource — see scalepad_lm_add_meeting_attendee_contacts.)

[ScalePad] Pin or unpin ONE action item so it sorts above the other open action items in task lists. Purely a presentation/priority flag — it does not complete, reschedule or reassign anything, and it is independent of the manual drag order managed by scalepad_lm_reposition_action_item. The current state is the is_pinned field on scalepad_lm_get_action_item. Succeeds with HTTP 204 and no body (this tool returns ).

[ScalePad] Move ONE action item within the account's MANUAL sort order (the sort_rank field, and the sort=sort_rank ordering on scalepad_lm_list_action_items). Position is expressed by naming the dragged item's new neighbours, and the vendor's convention is easy to invert — reproduce it exactly: before_id is the action item the dragged item should land BEFORE, i.e. the neighbour that ends up immediately BELOW it in the final list; after_id is the one it should land AFTER, i.e. the neighbour that ends up immediately ABOVE it. Succeeds with HTTP 201 and no body (this tool returns ). This changes only ordering — nothing about assignment, dates or completion.

[ScalePad] Update an existing action item's core fields — description, rich text, due date and assignees. The vendor calls the payload "replacement action item fields", so treat it as a REPLACEMENT rather than a merge: read the current record with scalepad_lm_get_action_item first and resend what should survive, in particular the nullable due_at. One documented exception to that rule: when description_json is omitted the server DERIVES the rich-text document from the plain description rather than clearing it. Succeeds with HTTP 204 and no body (this tool returns ) — call scalepad_lm_get_action_item to see the result. Completion, pin state and sort position are NOT editable here: use scalepad_lm_update_action_item_completion_status, scalepad_lm_pin_action_item and scalepad_lm_reposition_action_item. Links are not editable here either — use the attach/detach tools.

[ScalePad] Mark ONE action item complete or incomplete. This is the only way to move an action item's is_completed flag — scalepad_lm_update_action_item cannot touch it. Setting is_completed true is what populates the record's completed_at timestamp; sending false reopens the task. Succeeds with HTTP 204 and no body (this tool returns ). Not to be confused with the assessment-level scalepad_lm_update_assessment_completion_status, which is a different resource entirely.

[ScalePad] Create a new account-owned assessment template with its own categories, questions and criteria. Returns HTTP 200 with — note the vendor names the key assessment_template_id here, while scalepad_lm_create_assessment returns a bare . The whole structure goes in one body; there is no per-category or per-question create endpoint. ScalePad documents no idempotency-key header, so never blind-retry — re-check with scalepad_lm_list_assessment_templates first. Instantiate the finished template for a client with scalepad_lm_create_assessment.

[ScalePad] PERMANENTLY remove an assessment template that is no longer needed, along with its categories, questions and criteria. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the template is missing or inaccessible. ScalePad documents no soft delete, restore or undo — read the template with scalepad_lm_get_assessment_template first, check its is_in_use flag, and echo the exact title and id back to the user before calling. This deletes the reusable BLUEPRINT, not the client assessments created from it; to delete one filled-in assessment use scalepad_lm_delete_assessment. The vendor does not document what happens to existing assessments that reference a deleted template, so do not assume they are unaffected.

[ScalePad] Get ONE assessment template in full — every category, question and criterion. Returns {assessment_template, should_promote_control_map} (the second flag is a vendor upsell hint for ScalePad ControlMap, not part of the template). The template carries assessment_template_id, scope, title, description, created_at, updated_at, is_in_use, is_category_weight_evenly_distributed and categories[]. Each category is {assessment_template_category_id, title, description, is_question_weight_evenly_distributed, weight_in_percentage, questions[]}; each question is {assessment_template_question_id, title, description, remediation_tips, scoring_instructions, criterion_label_type_enum, weight_in_percentage, criteria[]}; each criterion is {assessment_template_criterion_id, label_enum, description}. Note two asymmetries: the read does NOT return the per-question tag_ids that create and update require, and the criterion is label_enum here while a filled-in assessment's criterion exposes label_key plus display_label. Check is_in_use before deleting, and use this response as the starting point for scalepad_lm_update_assessment_template, which replaces the whole structure.

[ScalePad] List every assessment template OVERVIEW visible to the account. Unusually for this API the operation declares NO parameters at all — no page_size, no cursor, no sort, no filters — and returns {data[]} with no total_count or next_cursor, i.e. the complete set in one unpaginated response. Each row is {assessment_template_id, scope, title, description, created_at, updated_at}; the vendor documents scope only by example ("Application") and publishes no value list, so treat it as an opaque string. Overviews carry no categories, questions or criteria — call scalepad_lm_get_assessment_template for the structure. The assessment_template_id here is what scalepad_lm_create_assessment instantiates and what filter[assessment_template_id] on scalepad_lm_list_assessments accepts.

[ScalePad] Modify an existing assessment template, including its structure — categories, questions and criteria. Treat it as a STRUCTURAL REPLACEMENT rather than a patch: the body carries the entire template, and each category/question you want to keep must be resent WITH its existing id (an id updates that child, null creates a new one), so always start from scalepad_lm_get_assessment_template and edit that structure. The vendor does not document what happens to an existing category or question you leave out of the body, so never rely on omission to remove one — and never omit a child you intend to keep. Succeeds with HTTP 204 and no body (this tool returns ); read the result back with scalepad_lm_get_assessment_template. Changing a template that is already in use (is_in_use on the read) alters the blueprint for future assessments — it is not a way to retro-edit assessments already created from it.

[ScalePad] Create a new assessment for a client FROM an existing assessment template — the template supplies the categories, questions and criteria, so there is no way to create a free-form assessment here. Returns HTTP 200 with . Answer the questions afterwards with scalepad_lm_evaluate_assessment. Pick the template with scalepad_lm_list_assessment_templates and the evaluating user with scalepad_lm_list_active_users. ScalePad documents no idempotency-key header, so never blind-retry — re-check with scalepad_lm_list_assessments filtered on the client and template first.

[ScalePad] PERMANENTLY delete an assessment that is no longer relevant. Succeeds with HTTP 204 and no body (this tool returns ); 404 if the assessment is missing or inaccessible. ScalePad documents no soft delete, restore or undo, and the assessment carries its whole evaluation — answers, scores, and both the internal and public commentary — so resolve and echo the exact assessment back to the user first with scalepad_lm_get_assessment. This deletes ONE completed/in-progress assessment, not the reusable template it came from: for that, see scalepad_lm_delete_assessment_template.

[ScalePad] ANSWER an assessment: submit the criterion selected for each question, which is what makes ScalePad RECOMPUTE the assessment's scores (overall_score and each category_score). Send one entry per question you are answering — the batch is the unit of work. This is NOT the same as scalepad_lm_update_assessment_completion_status, which only flips the complete/incomplete flag and recomputes nothing. Succeeds with HTTP 204 and no body (this tool returns ); read the new scores back with scalepad_lm_get_assessment. Note the response field is_previously_selected on each criterion, which shows what the prior answer was.

[ScalePad] Get ONE assessment in full, including its evaluation. Returns where the assessment carries id, assessment_template_id, client {id, label}, title, description, internal_comment (the MSP-private assessment-level note), evaluate_user_id, record_created_at, evaluated_at, updated_at, status, overall_score and category_list[]. Each category is {assessment_category_id, assessment_template_category_id, title, description, category_score, question_list[]}; each question is {assessment_question_id, assessment_template_question_id, title, description, remediation_tips, scoring_instructions, criteria_list[], public_comment, internal_comments}; each criterion is {assessment_criterion_id, assessment_template_criterion_id, label_key, display_label, description, is_selected, is_previously_selected}. Two vendor shapes to expect: public_comment is SINGULAR while internal_comments is PLURAL, yet both are a single comment object of the same schema {assessment_question_comment_id, assessment_question_id, comment_plain_text, comment_json, record_created_at, updated_user_id, updated_at}; and comment_json arrives here as a nested ProseMirror OBJECT even though the write tools take it as a JSON-encoded STRING. The assessment_question_id values in question_list are exactly what scalepad_lm_evaluate_assessment and the two question-comment tools accept, and the assessment_criterion_id values are what evaluate selects.

[ScalePad] List assessment OVERVIEWS across the account. Cursor-paginated: returns {data[], total_count, next_cursor} — keep paging until next_cursor is null, not until a page is short. Each overview row carries id, assessment_template_id, client {id, label}, title, description, evaluate_user_id, record_created_at, evaluated_at, updated_at, status, overall_score, question_count and question_answered_count. Overviews do NOT include the questions, criteria or comments — call scalepad_lm_get_assessment for the full nested structure. This endpoint documents page_size and cursor but NO sort parameter, so results come back in the server's own order.

[ScalePad] Update an assessment's header fields — title, evaluating user and evaluation date-time. All three are required by the schema, so this is a replacement of that trio rather than a patch: read the current values with scalepad_lm_get_assessment and resend the ones that should not change. Succeeds with HTTP 204 and no body (this tool returns ). This tool cannot change answers (that is scalepad_lm_evaluate_assessment), the completion flag (scalepad_lm_update_assessment_completion_status), the internal comment (scalepad_lm_upsert_assessment_internal_comment), or the client and template the assessment was created from.

[ScalePad] Toggle ONE assessment between complete and incomplete. This changes only the completion flag — it does NOT score anything, does not answer any question, and does not validate that every question has been answered; scoring is scalepad_lm_evaluate_assessment. Succeeds with HTTP 204 and no body (this tool returns ); the resulting state shows up as the status field on scalepad_lm_list_assessments / scalepad_lm_get_assessment (documented values Completed and InProgress). Distinct from scalepad_lm_update_action_item_completion_status, which is a different resource.

[ScalePad] Create or replace the ASSESSMENT-LEVEL INTERNAL comment — the vendor states these are private notes visible ONLY to the MSP, never to the client. Scope and format both differ from the question-level tools: this one covers the whole assessment (not a single question) and takes a required PLAIN-TEXT string, with no ProseMirror rich-text field at all. It is an upsert, so the value REPLACES any previous internal comment; read the current text from the assessment's internal_comment field via scalepad_lm_get_assessment before overwriting. Succeeds with HTTP 204 and no body (this tool returns ). For a client-visible note use scalepad_lm_upsert_assessment_question_comment_public — never this tool.

[ScalePad] Create or replace the INTERNAL comment on ONE QUESTION of an assessment — staff-only commentary that is NOT client-visible (vendor path .../questions//comment/internal). This is the per-question sibling of the assessment-wide scalepad_lm_upsert_assessment_internal_comment, and the internal counterpart of scalepad_lm_upsert_assessment_question_comment_public: the two question tools take identical bodies and differ ONLY in the final path segment, so confirm you want internal before calling — sending staff notes to the public endpoint exposes them to the client. Upsert semantics: the value REPLACES the question's existing internal comment. Succeeds with HTTP 204 and no body (this tool returns ); the stored result appears as internal_comments (the vendor's plural name for a single object) on the question in scalepad_lm_get_assessment.

[ScalePad] Create or replace the PUBLIC comment on ONE QUESTION of an assessment (vendor path .../questions//comment/public). This is the ONLY comment tool in this group whose content is CLIENT-VISIBLE — it is the narrative the client reads next to that question, so write it for that audience and never put staff-only notes here. The internal counterpart is scalepad_lm_upsert_assessment_question_comment_internal, which takes an identical body and differs only in the final path segment. Upsert semantics: the value REPLACES the question's existing public comment. Succeeds with HTTP 204 and no body (this tool returns ); the stored result appears as public_comment on the question in scalepad_lm_get_assessment.