Skip to main content

MCP tools

Every tool the SpendOne MCP server can serve, generated from the server's own registry. The description is the text the assistant reads to decide when to call a tool, so it is written for the assistant and is quoted here unchanged.

Your deployment can serve fewer tools than this page lists. The ones your connection actually has are the ones your assistant shows you.

Every tool runs as the user who connected the assistant, with that user's roles and permissions. Access is what the tool declares to the client:

  • Reads never changes anything.
  • Changes data creates or changes a record, and can be walked back, for example by editing the draft again or releasing a claimed task.
  • Changes data, cannot be undone through the assistant is a terminal step, such as a decision on an approval. Clients are expected to ask for confirmation before these.

Reaches says whether the tool touches anything outside SpendOne.

ToolAccessReaches
accountant_task_assignChanges dataSpendOne only
accountant_task_getReadsSpendOne only
accountant_task_listReadsSpendOne only
approval_approveChanges data, cannot be undone through the assistantSpendOne only
approval_assignChanges dataSpendOne only
approval_listReadsSpendOne only
approval_rejectChanges data, cannot be undone through the assistantSpendOne only
cost_center_listReadsSpendOne only
invoice_getReadsSpendOne only
invoice_listReadsSpendOne only
notification_listReadsSpendOne only
notification_mark_readChanges dataSpendOne only
product_getReadsSpendOne only
product_listReadsSpendOne only
product_scrapeReadsPublic internet
purchase_flow_listReadsSpendOne only
purchase_order_getReadsSpendOne only
purchase_order_listReadsSpendOne only
purchase_order_mark_orderedChanges dataSpendOne only
purchase_request_cancelChanges data, cannot be undone through the assistantSpendOne only
purchase_request_createChanges dataSpendOne only
purchase_request_getReadsSpendOne only
purchase_request_listReadsSpendOne only
purchase_request_request_approvalChanges dataSpendOne only
purchase_request_updateChanges dataSpendOne only
supplier_getReadsSpendOne only
supplier_listReadsSpendOne only
user_get_meReadsSpendOne only

accountant_task_assign​

Access: Changes data. Reaches: SpendOne only.

Assign an accountant task, by a code from accountant_task_list, to a user. Omit assignee_code to claim it for the caller; pass unassign=true to release it back to the unassigned queue. Handing a task to somebody else requires the accountant-tasks assign-to-others permission, and a task cannot be held by the requester or the buyer of its own purchase. An assignee who is on vacation is redirected to their active stand-in, so the task can land on a different user than the one named. This is the only change this server makes to an accountant task: completing it, booking its invoice and commenting all happen on the task's url in SpendOne.

accountant_task_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single accountant task by its business code, as returned by accountant_task_list, with the purchase order, supplier, invoice and assignee it is about. A task outside the caller's legal-entity scope answers not found. The returned url opens the task in SpendOne, where it is worked and completed.

accountant_task_list​

Access: Reads. Reaches: SpendOne only.

List the accountant tasks the caller may see, narrowed to one queue by filter. An ACCOUNTANT sees the tasks in the legal entities their org units reach, an ADMIN the whole tenant. Use filter=my_tasks for the caller's own queue and filter=unassigned for the tasks anyone in scope may claim with accountant_task_assign; assigned_to_me says which rows of any other queue the caller already holds. Each task carries a url onto its page in SpendOne, which is where the work itself is done: this server can claim and release a task, and nothing else about it.

approval_approve​

Access: Changes data, cannot be undone through the assistant. Reaches: SpendOne only.

Approve the given purchase-request approval task, by a task_code from approval_list. Advances the approval plan and, when the plan completes, drives the purchase request forward. The caller must be the task's assigned approver (an admin may decide an unassigned task, and no one may decide a request they raised or receive). Only tasks at the current actionable step can be decided; limit-increase approvals are not supported via MCP.

approval_assign​

Access: Changes data. Reaches: SpendOne only.

Assign an approval task, by a task_code from approval_list, to a user. Omit assignee_code to claim the task for the caller, which a member of the group it was routed to does for an unclaimed task before deciding it. Assigning to another user requires assignment permission.

approval_list​

Access: Reads. Reaches: SpendOne only.

List the purchase-request approval tasks the caller can see. Scope depends on the caller's role: an ADMIN or ACCOUNTANT sees every approval task in the tenant, anyone else sees only tasks routed to them (assigned to them by rule, via an approver tag they belong to, or from an org unit they lead). By default only tasks at the current actionable step are returned, which means the task is waiting on a decision now, NOT that the caller is the one who may decide it. Who may decide a task is read off two fields. assigned_to_me=true: the caller is its approver and may approve or reject it. assigned_to_me=false WITH an approver_code: it belongs to that approver and is read-only for the caller, so report it rather than offering a decision. No approver_code at all: the task is unclaimed, a member of the group it was routed to takes it with approval_assign, and an ADMIN may decide it directly as an escalation. Nobody may decide a request they raised or receive, whatever the fields say. Pass assigned_to_me=true for the caller's own queue alone. Every task carries a url onto its approval screen and the page carries a queue_url onto the approver list; offer those rather than a bare task code, and offer the url instead of a decision for a task the caller may not decide.

approval_reject​

Access: Changes data, cannot be undone through the assistant. Reaches: SpendOne only.

Reject the given purchase-request approval task, by a task_code from approval_list, with an optional structured decline reason and free-text comment. The caller must be the task's assigned approver (an admin may decide an unassigned task, and no one may decide a request they raised or receive). Only tasks at the current actionable step can be decided; limit-increase approvals are not supported via MCP.

cost_center_list​

Access: Reads. Reaches: SpendOne only.

List the cost centers configured for the caller's tenant, the same list for every role. Use it to find the codes purchase_request_create takes in cost_center_splits. Supports pagination and an optional substring search on name or code.

invoice_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single invoice by its business code, as returned by invoice_list or named on an accountant task. An invoice the caller may not see answers not found. The returned url opens it in SpendOne.

invoice_list​

Access: Reads. Reaches: SpendOne only.

List the invoices the caller may see. Scope depends on the caller's role: an ADMIN or ACCOUNTANT sees every invoice in the tenant, anyone else only invoices tied to them (as recipient or assignee, or as requester or buyer of the purchase). Supports pagination and an optional substring search. Each invoice carries a url onto its page in SpendOne.

notification_list​

Access: Reads. Reaches: SpendOne only.

List the caller's own in-app notifications (recent activity), whatever their role. Supports the inbox, unread, and archived filters plus keyset pagination: pass a page's next_cursor back for the next one.

notification_mark_read​

Access: Changes data. Reaches: SpendOne only.

Mark one of the caller's own notifications as read, by the id notification_list returned.

product_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single product by its business code, as returned by product_list.

product_list​

Access: Reads. Reaches: SpendOne only.

List the products in the caller's tenant catalog, the same list for every role. Use it to find the product_code a purchase_request_create line item takes. Supports pagination and an optional substring search on the product name.

product_scrape​

Access: Reads. Reaches: Public internet.

Read a public product page and return its title, price, image, and vendor as structured fields, so a purchase request can be drafted from a link the requester pasted. The vendor is resolved against the tenant's suppliers: supplier_code is filled only on an exact name match. Fetches the given URL over the internet; it reads nothing of the tenant's data beyond the supplier list. Only a public http(s) address is fetched; a refused address answers that it is not permitted.

purchase_flow_list​

Access: Reads. Reaches: SpendOne only.

List the purchase flows available to the caller. CALL THIS FIRST when creating a purchase request: purchase_request_create requires a purchase_flow_code, and the flow decides the request's legal entity, which payment methods it may use, whether a rationale is mandatory, and which approval rule it will be evaluated against. Returns an empty list when the caller's org units carry no legal entity, in which case the caller cannot create a purchase request at all.

purchase_order_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single purchase order by its business code, as returned by purchase_order_list, with what placing it needs: the supplier, the line items (description, quantity, unit price, line total, product link), the total amount and currency, the payment method (credit_card or invoice), and invoice_email, the address the supplier must send the invoice to. Give the supplier the purchase order code as the order number and invoice_email as the invoice address. An order paid by virtual card also returns that card's last four digits, its expiry date and a link the person can open to see the full card details in SpendOne; the card number, expiry and CVV are never returned here and cannot be read through this tool. Only the person who raised the request or was named as its buyer gets the card, so an administrator or accountant reading the same order sees no card and is not being denied one in error. Placing the order and marking it ordered happen on that screen, not through this server. next_step says what happens next, actor who does it ("you" when it is the caller), and next_step_url the screen it happens on.

purchase_order_list​

Access: Reads. Reaches: SpendOne only.

List the purchase orders the caller may see. Scope depends on the caller's role: an ADMIN or ACCOUNTANT sees every order in the tenant, anyone else only orders on their own purchase requests. An approved request's order waits in READY_TO_ORDER until it is placed. Supports an optional status filter and bounded pagination. Each order carries a url onto its Order step in SpendOne, which is where an approved order is actually placed; offer that link rather than describing the order alone. Each order also names its purchase_request_code, which purchase_request_get takes; call purchase_order_get for the supplier, line items, amount, payment method and invoice address. next_step says what happens next, actor who does it ("you" when it is the caller), and next_step_url the screen it happens on.

purchase_order_mark_ordered​

Access: Changes data. Reaches: SpendOne only.

Record that an approved purchase order (status READY_TO_ORDER) has been placed with the supplier, moving it to ORDERED. This does NOT place the order: the person places it with the supplier first (for a card-paid order, with the virtual card opened from purchase_order_get's credit_card.reveal_url), and only then is this tool called to record it. Only the purchase request's buyer may call it, as in SpendOne; anyone else is refused. purchase_order_get's buyer_is_me says whether that is the caller. A card-paid order is refused until its card has been issued.

purchase_request_cancel​

Access: Changes data, cannot be undone through the assistant. Reaches: SpendOne only.

Cancel a purchase request, by a code from purchase_request_list or purchase_request_create. Only its requester or buyer, or an ADMIN, may cancel it. Fails with a conflict when the request is in a state that cannot be canceled.

purchase_request_create​

Access: Changes data. Reaches: SpendOne only.

Create a draft purchase request for the caller's tenant. REQUIRES purchase_flow_code: call purchase_flow_list first and pick a flow, which fixes the request's legal entity, its permitted payment methods and whether a rationale is mandatory. Look up the other coded fields before calling: supplier_list for supplier_code, cost_center_list for cost_center_splits, product_list for line-item products. Creates a DRAFT and stops there; submit it separately with purchase_request_request_approval.

purchase_request_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single purchase request by its business code, as returned by purchase_request_list, purchase_request_create or an approval task. A request the caller may not see answers not found. The returned url opens its purchase case in SpendOne. next_step says what happens next, actor who does it ("you" when it is the caller), and next_step_url the screen it happens on.

purchase_request_list​

Access: Reads. Reaches: SpendOne only.

List the purchase requests the caller may see, newest first. Scope depends on the caller's role: an ADMIN or ACCOUNTANT sees every request in the tenant, anyone else the requests they raised, buy or receive, plus those under the org units they lead. Supports pagination. Each request carries a url onto its purchase case in SpendOne. next_step says what happens next, actor who does it ("you" when it is the caller), and next_step_url the screen it happens on.

purchase_request_request_approval​

Access: Changes data. Reaches: SpendOne only.

Submit a draft purchase request for approval, by the code purchase_request_create returned. Validates the draft, freezes the approval plan, and returns the resulting chain of approvers. Fails with validation_failed listing the offending fields when the draft is incomplete.

purchase_request_update​

Access: Changes data. Reaches: SpendOne only.

Update a purchase request while it is still in DRAFT status, by the code purchase_request_create returned. Only its requester or buyer, or an ADMIN, may edit it. Fields replace the draft's current values, so send every field that should survive, not only the changed ones.

supplier_get​

Access: Reads. Reaches: SpendOne only.

Retrieve a single supplier by its business code, as returned by supplier_list or product_scrape.

supplier_list​

Access: Reads. Reaches: SpendOne only.

List the suppliers configured for the caller's tenant, the same list for every role. Use it to find the supplier_code purchase_request_create takes. Supports pagination and an optional substring search on the name.

user_get_me​

Access: Reads. Reaches: SpendOne only.

Return the authenticated caller: their user code, name, email and language. Call it first in a session: it needs no input, and its code is what buyer_code, assignee_code and the approver and assignee codes in other results are compared against.

What changed in this surface over time: MCP tool changelog.