The mcp-uof server exposes UOF (U-Office Force) workflow operations as AI-callable tools, enabling AI agents to manage enterprise workflow forms end-to-end through natural language via HTTPS requests against UOF endpoints.
Authentication & Session Management
uof_custom_check_auth: Verify the current UOF account identity and session validity; supports browser sign-in or credential-based login/logout.
Form Discovery
uof_custom_get_form_list: Browse all form categories, IDs, and version codes needed for submission.
uof_custom_get_external_form_list: Query forms marked as "not for online use".
Form Schema Inspection
uof_custom_get_form_structure: Retrieve field structure (IDs and names) using a form version ID.
uof_custom_get_form_structure_by_id: Retrieve full field structure including field types and filling instructions — recommended before submitting.
Get dialog field structures and search dialog options.
Workflow Initiation
uof_custom_preview_workflow: Simulate a form submission to validate the signing route before submitting.
uof_custom_apply_form: Officially submit a new workflow task; returns a TaskId for all subsequent operations.
Task Tracking
uof_custom_get_task_data: Quickly check a task's status (applicant, current result, close date).
uof_custom_get_task_result: View the full step-by-step signing history — who signed, what decision, comments, and timestamps.
uof_custom_query_forms: Search submitted or signed forms by date range and keyword to retrieve TaskIds.
Signing & Approval
uof_custom_sign_next: Advance a fixed-flow form to the next signing step and designate the next signer.
uof_custom_terminate_task: Close a task by voiding it (Cancel), approving (Adopt), or rejecting (Reject).
Get pending sign list.
User Lookup
uof_custom_search_users: Look up UOF users by name or account keyword to get correct account IDs for routing forms.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-uof query my pending forms"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An open-source MCP (Model Context Protocol) server that turns UOF (U-Office Force) workflow operations into AI-callable tools, driven entirely through httpx web automation.
Built for Claude Code, Claude Desktop, VS Code, and any MCP-compatible client. It lets AI agents query workflow forms, inspect form schemas, submit forms, track workflow progress, sign off, and close workflow tasks through natural language.
19 exposed tools for UOF workflow operations. preview_workflow and get_external_form_list currently return capability guidance rather than live data.
MCP server over stdio for local AI clients.
Tool-first interface: users call the same tools without ever choosing a mechanism — how each tool talks to UOF is an internal, developer-time decision.
Browser sign-in: uof_custom_login opens the real UOF login page in the user's own browser and captures the session. The local MCP proxy relays the login form to UOF, so the password transits the server process in memory but is never parsed, logged, persisted, written to a config file, or returned to the AI. An unattended username/password fallback stays available for CI.
Single identity model: one server process represents one UOF identity, and the session persists across restarts.
httpx web automation: operations use HTTPS requests (httpx + lxml) against UOF's aspx/ashx endpoints, without a browser runtime. On Alpine Linux or musl, ensure binary wheels or native build dependencies are available.
Related MCP server: mcp2ws
This project targets UOF first-generation web flows, driven over httpx.
Authentication: a Login.aspx cookie session, obtained either through browser sign-in or the credential fallback.
Base URL: configured with UOF_BASE_URL, for example https://your-uof-domain.com/VirtualPath.
Required UOF settings: see docs/configuration.md.
Install from PyPI:
pip install mcp-uofOr run without installing:
uvx --from mcp-uof mcp-uofTo install and run the current source instead:
git clone https://github.com/asgard-ai-platform/mcp-uof.git
cd mcp-uof
uv sync
cp .env.example .envSet the connection URL — that is the only required variable:
export UOF_BASE_URL=https://your-uof-domain.com/VirtualPathSign in by calling the uof_custom_login tool in your chat: it opens the real UOF login page in
your default browser, and the session is handed back to the server once you log in. Credentials
are relayed as-is by the local proxy — never parsed, logged, persisted, or returned to the AI, and
never written to a config file. See docs/configuration.md
for the unattended (username/password) fallback used by CI.
Add the server via the Claude CLI:
claude mcp add --transport stdio uof -- mcp-uofOr with environment variables inline:
claude mcp add --transport stdio uof \
-e UOF_BASE_URL=https://your-uof-domain.com/VirtualPath \
-- mcp-uofIf you clone the repo locally, run it through uv:
claude mcp add --transport stdio uof -- uv --directory /absolute/path/to/mcp-uof run mcp-uofAdd to your claude_desktop_config.json:
{
"mcpServers": {
"uof": {
"command": "mcp-uof",
"env": {
"UOF_BASE_URL": "https://your-uof-domain.com/VirtualPath"
}
}
}
}Or with a local checkout:
{
"mcpServers": {
"uof": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/mcp-uof", "run", "mcp-uof"],
"env": {
"UOF_BASE_URL": "https://your-uof-domain.com/VirtualPath"
}
}
}
}See docs/integration.md and examples/ for more client configuration examples.
All tool names use the uof_custom_ prefix.
Domain | Tools |
System |
|
WKF Workflow |
|
Important behavior and constraints:
get_pending_sign_list returns every form awaiting the current identity's signature (with TaskId/SiteId/NodeSeq), sourced from the Homepage pending-sign widget. query_forms is a different set — the forms you submitted or signed, by date range (query_mode = apply/sign). Ask "what do I need to sign?" → get_pending_sign_list.
Composite fields (line items, vendor pickers, expense details) live inside dialogs. Use get_dialog_structure to see a dialog field's inner controls, search_dialog_options to look up real picker candidates (never fabricate codes), and pass them into apply_form via the _lookups / _fill_before / _press_after / _rows reserved keys. operate_dialog is a probe only — it cannot accumulate rows.
sign_next performs approval for the current pending step and can close the flow or route to a designated next signer. It does not accept a signing comment; return, parallel/countersign, and fixed-flow stepping still require the Web UI.
terminate_task closes a task: Cancel voids an in-flight form (via the web recall page), Adopt/Reject approve/reject through the web sign flow. It checks task status first and blocks repeated closure of an already-closed task.
preview_workflow (flow simulation) is not available over httpx and directs the user to the Web UI; you can still submit directly with apply_form and inspect the real signing route afterward with get_task_result.
apply_form always submits as the identity this server process is signed in as (the browser-login user, or the configured UOF_ACCOUNT when the credential fallback is used). Its applicant_account and first_signer_account parameters are currently retained for interface compatibility but do not change the submitted identity or routing.
See docs/tools.md for full tool specs, role model, examples, and operational boundaries.
mcp-uof/
├── src/mcp_uof/ # MCP server, auth (web session), routing, httpx web backend
├── docs/ # Architecture, configuration, integration, tools, testing
├── examples/ # Claude Desktop and VS Code MCP config examples
├── tests/ # smoke / mounted test layers
├── .env.example # Environment variable template
├── README.zh-TW.md # Traditional Chinese README
└── pyproject.tomluv sync
uv run python tests/run.py smoke
uv run python -m compileall src testsTests that connect to a real UOF test environment require .env:
uv run python tests/run.py mountedSee CONTRIBUTING.md and docs/testing.md for development and testing guidelines.
MIT
正式起單，成功回傳 TaskId（後續查詢與結案都要用到，務必保存）。
何時使用：已用 get_form_structure_by_id 確認這張表單要帶哪些欄位後，要正式送出時。 呼叫端只要挑表單、填內容即可——這張表單背後怎麼起（系統內部用哪種方式）不需要你管。
限制：起單不會驗證網頁必填欄位，缺欄位仍可能起單成功但內容不完整；附檔、多站/並簽會簽尚未支援。
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | 起單內容，**形狀依該表單而定，請先用 get_form_structure_by_id 查**：一般表單帶 {fieldId: 值}（明細欄位帶列清單 {"004":[{"004_1":"品名","004_3":5}]}）；少數客製表單（如採購單）帶該表單說明的內容（主旨/供應商/明細…）。 | |
| comment | No | 申請者意見（選填） | |
| urgent_level | No | 緊急程度：0 緊急 / 1 急 / 2 普通 | 2 |
| form_version_id | Yes | 表單版本代號，由 get_form_list 取得 | |
| applicant_account | Yes | 申請者帳號；web 起單表單必須等於目前 MCP 的 UOF_ACCOUNT | |
| first_signer_account | Yes | 第一站簽核者帳號（SOAP 自由流程必填，請先向使用者確認送給誰簽）；網頁起單的表單(如採購單)由表單自身流程決定簽核者，此參數會被略過 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that submission does not validate required fields, attachments are unsupported, and first_signer_account is ignored for web forms. However, it does not detail authentication requirements or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the critical output (TaskId), followed by usage context and limitations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested object) and the presence of an output schema, the description covers prerequisites, parameter usage, and limitations. It lacks explicit error handling details but is otherwise comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds significant context: explains fields parameter shape depends on form, clarifies first_signer_account behavior for SOAP vs web forms, and notes applicant_account must equal UOF_ACCOUNT for web forms—all beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and result ('正式起單，成功回傳 TaskId'), distinguishing it from sibling tools like get_form_structure and query_forms. It specifies the resource (form submission) and the key output (TaskId).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('已用 get_form_structure_by_id 確認...後，要正式送出時') and provides limitations ('不驗證必填欄位','附檔、多站/並簽會簽尚未支援'), which serve as guidance for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
確認目前以哪個 UOF 帳號身份操作，並檢查 Token / Session 是否有效。
何時使用：對話開始時、或任何工具回報認證錯誤時，用來確認身份與連線。 每個 Server 程序只代表一個固定帳號（由設定綁定）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only behavior and token/session check. It mentions fixed account binding. However, it does not specify what happens on invalid token (e.g., error return).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus usage guidance. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description adequately covers the tool's purpose and usage. It provides necessary context for an authentication check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds no parameter info but is not needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms the current UOF account and checks Token/Session validity. It distinguishes from sibling tools (form/task operations) by focusing on authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use: at conversation start or when auth errors occur. Also explains that each server process represents a fixed account, providing context for identity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出被標記為「非線上使用」的表單。
何時使用：少數需要查詢非線上表單的情況。注意：此清單不等於可外部起單的表單 （採購單就不在其中卻能起單）。要判斷能否起單，請改看 get_form_list 的 recentVersionId。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the purpose. It lacks information about side effects, authentication requirements, or other behavioral aspects that would help the agent understand the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first for purpose, second for usage context, third for critical distinction. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, an output schema exists (context signal), and the description covers purpose, usage, and distinction from sibling, it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so there is nothing to document. According to guidelines, 0 params gets a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists forms marked as '非線上使用' (not for online use), with a specific verb and resource. It also distinguishes from sibling tool get_form_list by clarifying that this list does not equal forms that can be submitted externally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (rare cases needing to query non-online forms) and when not to use (not for determining external submission capability). Provides an alternative: use get_form_list's recentVersionId for that purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有表單類別與表單，含 formId 與表單版本代號（recentVersionId）。
何時使用：使用者問「系統有哪些表單」，或要起單但還不知道目標表單的 formId / formVersionId 時。這是起單流程的第一步。有 recentVersionId 的表單才可外部起單。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that only forms with recentVersionId can be externally initiated, which is a useful behavioral trait. However, it does not mention authentication requirements, rate limits, or any other behavioral aspects, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear parts: function and usage. Every sentence adds value, and there is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description provides sufficient context: what is returned, when to use, and a key condition (recentVersionId for external initiation). It is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter information; it focuses on the output, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all form categories and forms with formId and recentVersionId. It uses a specific verb-resource combination and distinguishes from siblings like uof_custom_get_external_form_list and uof_custom_query_forms, which are for external forms and searching respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance: when user asks what forms exist or when initiating a form without knowing formId. It also states this is the first step in the initiation process. However, it does not mention when not to use or alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以表單版本代號取得欄位結構（只有 fieldId 與名稱，無型別）。
何時使用：手上只有 formVersionId 時。一般建議改用 get_form_structure_by_id（資訊較完整）。
| Name | Required | Description | Default |
|---|---|---|---|
| form_version_id | Yes | 表單版本代號，由 get_form_list 的 recentVersionId 取得 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations，但描述自行揭露輸出限制（只有 fieldId 與名稱，無型別），雖未提及權限或副作用，但對於唯讀查詢已足夠。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
兩句話完成目的、使用時機與差異說明，無冗餘字詞，結構簡潔。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
對於單參數的查詢工具，已涵蓋目的、使用指引與輸出限制，配合輸出 schema 即可達成完整性。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
僅一個參數，schema 已覆蓋 100%，描述補充了參數來源（由 get_form_list 的 recentVersionId 取得），增加實用語意。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
明確指出動詞「取得」、資源「欄位結構」，並強調只含 fieldId 與名稱無型別，與 siblings 中的 get_form_structure_by_id 區分開來。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
明確指示何時使用（只有 formVersionId 時），並建議替代工具（get_form_structure_by_id）以獲取更完整資訊。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
以表單代號取得欄位結構，含每個欄位的型別與填寫方式，並附上起單提示。
何時使用：要起單前，先用本工具查清楚這張表單要填哪些欄位、怎麼填。 建議優先用本工具（比 get_form_structure 多回 fieldType 與填寫指引）。 注意：回傳的是表單對外開放的「中介欄位」，可能少於 UOF 網頁上的完整表單。
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | 表單代號 formId，由 get_form_list 取得 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: it returns field structure with types, filling guidance, and start order hints. It also warns that returned fields are intermediate and may be incomplete. This is thorough, though minor details about error scenarios are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences plus a note, each adding unique value. Front-loaded with the core purpose, followed by usage guidance and a behavioral note. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description provides sufficient summary of return values. It covers usage timing, comparative advantage over a sibling, and a critical limitation (intermediate fields). The single parameter is well-contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'form_id' stating it comes from get_form_list. The description adds value by reiterating this source context and emphasizing its origin, exceeding the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves field structure by form ID, including types, filling methods, and start order hints. It also distinguishes itself from the sibling 'get_form_structure' by noting it returns additional field type and guidance information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use before starting a form to check fields and filling methods. Recommends this tool over 'get_form_structure' for richer output. Also includes a caveat about the returned fields being intermediate and potentially fewer than the full form, providing important usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查詢一張單的摘要：申請者、目前結果（簽核中/同意/否決/作廢）、結案日期。
何時使用：想快速知道某張單目前的狀態時。需要逐站簽核歷程請改用 get_task_result。 系統沒有待簽清單 API，TaskId 必須由使用者提供。
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 表單工作代號 TaskId，由 apply_form 回傳或使用者自 UOF 網頁/通知信取得 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output fields and that task_id is required from user. Lacks details on error handling (e.g., invalid task_id) but is sufficient for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: first defines action, second gives usage guidance. No redundant sentences, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one param, has output schema. Description covers purpose, usage, and important context (task_id source). No gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (task_id) with 100% schema coverage. Description repeats the schema's info about where task_id comes from, adding minimal extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a summary of a task, listing specific fields (applicant, current result, closure date). It differentiates from sibling get_task_result by noting that tool provides step-by-step signing history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit '何時使用' section tells when to use this tool ('想快速知道某張單目前的狀態時') and when to use alternative ('需要逐站簽核歷程請改用 get_task_result'). Also notes that task_id must be provided by user since system has no pending list API.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查詢一張單的逐站簽核歷程（每一站的簽核者、結果、意見、時間）。
何時使用：想看簽核走到哪一站、誰簽了什麼意見時。站點顯示「待簽」代表表單停在該站。 只要摘要狀態用 get_task_data 即可。
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 表單工作代號 TaskId | |
| include_form_data | No | 是否一併回傳表單欄位內容 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return content and the meaning of 'pending sign', but does not explicitly state read-only nature or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, structured, and front-loaded with purpose. Every sentence adds value, and it fits within a short paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the context signals, the description is mostly complete. Minor gap: no mention of whether all stations are returned or only up to the current status, but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameter descriptions already present. The tool description does not add significant extra semantics beyond the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries per-station signing history (signer, result, opinion, time) and differentiates itself from the sibling tool get_task_data, which is for summary status only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: '想看簽核走到哪一站、誰簽了什麼意見時' and explicitly advises to use get_task_data for summary status, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
模擬簽核流程走向，不會真的起單。參數與 apply_form 完全相同。
何時使用：呼叫 apply_form 正式起單之前，用相同參數先驗證流程與簽核路徑是否正確。 註：網頁起單的表單(如採購單)改以「試填到送出前」的填寫驗證代替（其簽核路徑於送出時的確認視窗呈現）。
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | 欄位值對應 {fieldId: 值}，可留空 | |
| comment | No | 申請者意見（選填） | |
| urgent_level | No | 緊急程度：0 緊急 / 1 急 / 2 普通 | 2 |
| form_version_id | Yes | 表單版本代號，由 get_form_list 取得 | |
| applicant_account | Yes | 申請者帳號；web 起單表單必須等於目前 MCP 的 UOF_ACCOUNT | |
| first_signer_account | Yes | 第一站簽核者帳號（自由流程必填） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the non-destructive simulation behavior and that it does not actually submit. With no annotations, the description carries full burden and adequately explains behavioral traits. Could be improved by mentioning the output or return format, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two main sentences plus a note. Front-loaded with primary purpose and usage. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description adequately covers the tool's purpose, usage, and parameter equivalence. The note about web form validation adds useful context. Slightly incomplete regarding what the tool returns, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are described in the schema (100% coverage). The description adds value by stating that parameters are exactly the same as apply_form, which clarifies equivalence. This contextual insight raises the score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates the approval workflow without actual submission ('模擬簽核流程走向，不會真的起單'), specifying verb (simulate) and resource (workflow preview). It distinguishes itself from sibling uof_custom_apply_form by noting identical parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: '呼叫 apply_form 正式起單**之前**，用相同參數先驗證流程與簽核路徑是否正確' (before calling apply_form to verify the workflow and approval path). Provides clear usage context and alternative (apply_form for actual submission).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋 UOF 表單（依日期範圍 + 關鍵字），回傳含 TaskId 的清單。
何時使用：使用者沒有 TaskId、但想列出自己最近的單或搜尋特定關鍵字時。 本工具是補上「UOF 一代沒有待簽清單 API」這個缺口最直接的入口； 取得 TaskId 後可丟給 get_task_data / get_task_result 看單張詳情。
限制：
範圍是「目前帳號可看到的單」，等同於使用者在 UOF 網頁「查詢表單」頁所看到的範圍。
只取第一頁結果；極端情況需要更精確過濾請縮日期範圍或加關鍵字。
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | 申請日期迄 (yyyy/mm/dd)；留空則預設為「今天」 | |
| keyword | No | 關鍵字（可查表單編號、標題、申請者、內容）；留空則只用日期過濾 | |
| date_from | No | 申請日期起 (yyyy/mm/dd)；留空則預設為「今天往前 7 天」 | |
| max_results | No | 最多回幾筆（只看第一頁；預設 50，UOF 一頁通常 10–20 筆） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses scope (visible to current account), pagination (first page only), and default behavior. Does not explicitly state read-only or auth requirements, but given the context, the behavioral traits are adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences efficiently cover purpose, usage, and limitations. Front-loaded with the core action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with output schema, the description covers purpose, usage, parameter behavior, and limitations. It provides sufficient context for an AI to select and invoke correctly, especially given sibling tool context and output schema existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds valuable context: default date ranges (today, last 7 days), keyword fields, max_results default and practical limit. This exceeds the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches UOF forms by date range and keyword, returning a list with TaskId. It distinguishes from siblings by positioning itself as the entry point to obtain TaskId for use with get_task_data/get_task_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user lacks TaskId and wants to list recent forms or search keywords). Provides alternative, mentions it fills a gap, and gives limitation about only first page, suggesting narrowing date/keyword for precision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
依姓名或帳號關鍵字查詢 UOF 人員，回傳姓名、帳號與 UserGuid。
何時使用：需要指定 apply_form 的 first_signer_account（第一簽核者帳號）時， 先用本工具確認對方在 UOF 的正確帳號，避免帳號輸錯導致起單失敗。
限制：回傳範圍為目前帳號可看到的 UOF 人員（同 ChoiceCenter 選人清單）。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 查詢關鍵字：輸入姓名或帳號的一部分即可，例如「asgard」「王小明」 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns name, account, and UserGuid, and notes visibility restrictions. It does not mention behavior on empty results or any side effects, but since it's a search operation, this is mostly sufficient. A mention of no-results handling would elevate it to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short paragraphs (three sentences in total) that front-load the main action and then provide usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema (as indicated), the description adequately explains the return fields (name, account, UserGuid) and usage context. It covers the necessary information for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema for the single parameter 'keyword' includes a description with examples (e.g., 'asgard', '王小明') and usage hints. The tool's description reinforces the purpose, adding meaning beyond schema alone. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action '依姓名或帳號關鍵字查詢 UOF 人員' (query UOF personnel by name or account keyword) and the return fields (name, account, UserGuid). It clearly distinguishes itself from sibling tools, which are for form manipulation and task management, not user search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: when specifying first_signer_account for apply_form, to ensure correct account. It also notes the limitation that results are limited to personnel visible to the current account, providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
將固定流程的表單推進到下一站並指定簽核者。
何時使用：僅適用於後台設計好的固定流程表單。 自由流程（如採購單）不支援本工具；要在自由流程上同意/否決請改用 terminate_task。 site_id/node_seq/signer_guid 無法由查詢 API 取得，需由表單流程設計提供。
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | 目前站點代號（僅固定流程的後台設計才有） | |
| task_id | Yes | 表單工作代號 TaskId | |
| node_seq | Yes | 節點順序 | |
| signer_guid | Yes | 預計簽核者 Guid |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that site_id/node_seq/signer_guid cannot be obtained from query APIs and must come from form workflow design. This adds valuable behavioral context beyond the schema. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, followed by usage guidelines, and a note about parameter source. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (4 required) and the presence of an output schema (though not shown), the description covers the essential information. It could mention expected outcomes or error conditions, but overall it is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that site_id/node_seq/signer_guid are from backend design and not queryable, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('push the fixed-process form to the next station and specify the approver') and resource. It distinguishes from the sibling tool 'terminate_task' by specifying that this tool is only for fixed-flow forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (only for backend-designed fixed-flow forms) and when not to (free-flow forms), and provides an alternative tool ('terminate_task').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
結案一張單。可作為申請人撤單(Cancel)、或主管/管理員核准否決(Adopt/Reject)。
何時使用：
申請人要撤回自己的單 → result=Cancel
主管要同意/否決停在自己這站的單 → result=Adopt/Reject（單站自由流程中等同簽核）
管理員要強制結案卡住的單 → 任一動作 操作者固定為本 Server 綁定的身份（UOF_ACCOUNT），不由呼叫端指定。 注意：這是「整張單終結」，多站流程會跳過後續站點；對已結案的單會被擋下。
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | 結案原因（不會寫入簽核歷程意見欄） | |
| result | Yes | 結案動作：Adopt 同意 / Reject 否決 / Cancel 作廢 | |
| task_id | Yes | 表單工作代號 TaskId |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: terminates the entire task (skipping subsequent steps), blocks if already terminated, and clarifies that the reason field is not written to the sign-off history. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured using bullet points for usage scenarios. Every sentence adds value with no redundancy. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and an output schema, the description covers purpose, when to use, parameter nuances, and behavioral impacts. It is fully self-contained for an agent to understand correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: reason is not stored in opinion fields, result enum is explained with usage scenarios, and task_id is simply the task work ID. This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool terminates a task with specific actions (Cancel, Adopt, Reject). It distinguishes from sibling tools like uof_custom_sign_next which handles sequential signing, not termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use each result: Cancel for applicant withdrawal, Adopt/Reject for supervisor approval/rejection, and Admin for stuck tasks. Also notes the operator is fixed to the server's identity, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.7uof_custom_apply_formuof_custom_check_authuof_custom_get_external_form_listuof_custom_get_form_listuof_custom_get_form_structureuof_custom_get_form_structure_by_iduof_custom_get_task_datauof_custom_get_task_resultuof_custom_preview_workflowuof_custom_query_formsuof_custom_search_usersuof_custom_sign_nextuof_custom_terminate_taskScored across 13 tools
Each tool has a clearly distinct purpose. Overlaps like get_form_structure vs get_form_structure_by_id are clarified by descriptions, and get_task_data vs get_task_result serve different detail levels. No ambiguity.
All tools follow a consistent pattern: 'uof_custom_' prefix + verb_noun in snake_case (e.g., apply_form, check_auth, sign_next). The naming is uniform and predictable.
13 tools cover the necessary operations for a form/approval system without being excessive. Each tool serves a logical need in the workflow, from listing forms to applying, querying, and managing tasks.
The tool set covers core form lifecycle (list, get structure, apply, preview, query, task details, termination). Minor gaps exist: no pending task list API (acknowledged limitation) and no file attachment support, but the essential operations are present.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
