mcp-uof

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.7
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.6/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 44 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-uof MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-uof/badges/card.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-uof)

Score Badge

Copy to your README.md:

[![mcp-uof MCP server](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-uof/badges/score.svg)](https://glama.ai/mcp/servers/asgard-ai-platform/mcp-uof)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/asgard-ai-platform/mcp-uof'

If you have feedback or need assistance with the MCP directory API, please join our Discord server