Taiwan government tender search and intelligence: 14M+ notices, vendor and agency reports.
兩家廠商的同場對戰紀錄：交手幾次、各贏幾次。 兩個名稱都要是正式全名（先用 find_entity 查）。 適合回答「A 跟 B 誰比較強」「我常輸給誰」。
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_a | Yes | ||
| vendor_b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations，描述描述主要行為（回傳交手次數、勝負數量），但未揭露輸出格式、資料來源、是否為唯讀操作或錯誤處理方式。對簡單查詢工具而言，基本行為已表達，但缺乏更深入的行為細節。
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、無 annotations），描述已涵蓋功能、參數前置條件、適用情境。缺少回傳格式或失敗情境的說明，但對一個簡單比較工具來說整體已足夠完整。
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 參數僅有標題，無描述。描述補充了參數的重要語義：兩個名稱都必須是正式全名，且需先透過 find_entity 查詢。這對於正確使用參數有實質幫助，但未逐一說明每個參數的具體格式。
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?
描述清楚說明工具功能：比較兩家廠商對戰紀錄（交手次數、勝負），動詞「比較」搭配資源「廠商」，並與兄弟工具如 vendor_report、price_analysis 區分。明確指出適用問題類型，有助於 agent 選擇。
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?
描述明確指出使用情境（回答誰比較強、常輸給誰），且提供重要前置條件：名稱必須是正式全名，需先使用 find_entity 查詢。雖未明說何時不使用此工具，但已提供足夠的使用指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用不完整的名稱找機關或廠商的正式名稱與代碼。 例：輸入「台電」找台灣電力公司相關、「北市府」找臺北市政府相關。 vendor_report / unit_report / compare_vendors 需要正式名稱，先用這個查。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior — fuzzy/incomplete-name matching and returning official name plus code — but does not disclose result-set behavior (single vs multiple matches), failure behavior when no match is found, or any matching constraints. Adequate but with 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?
Three compact sentences with no waste: purpose is front-loaded, examples follow, and usage guidance closes. Each sentence earns its place and the overall length is appropriate for the tool's simplicity.
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 single-parameter lookup tool with no output schema and no annotations, the description is nearly complete: it states purpose, parameter semantics via examples, return content (official name and code), and pre-conditions for related tools. Only edge-case behavior (no match, multiple matches) is unaddressed.
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 0% and the parameter is only titled 'Q', so the description must compensate. It does so via examples like '輸入「台電」找台灣電力公司相關', clarifying that q is an incomplete name fragment of an agency or vendor. This meaningfully fills the schema gap, though it stops short of specifying format constraints.
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 a specific verb and resource: '用不完整的名稱找機關或廠商的正式名稱與代碼' (use incomplete names to find official names and codes of agencies/vendors), with concrete examples. This makes clear it is a name-resolution/lookup tool and distinguishes it from siblings like search_tenders (tender search) and vendor_report (report generation).
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 says 'vendor_report / unit_report / compare_vendors 需要正式名稱，先用這個查' — telling the agent to use this tool first when those siblings need an official name but only an incomplete one is available. This names the dependent alternatives and provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
單一標案的完整歷程：招標→決標的每則公告、預算與決標金額、 得標廠商、競爭態勢（幾家投標／是否單一投標）、是否為續約案。 unit_id 與 job_number 來自 search_tenders 的結果列。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無任何 annotations，描述承擔行為揭露責任。描述列舉了回傳內容的組成，但未說明操作是否為唯讀、潛在的權限需求、錯誤情境或速率限制，行為面的透明程度不足。
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 對參數的描述覆蓋率為 0%，描述僅說明 unit_id 與 job_number 來自 search_tenders 的結果列，未實際定義每個參數的語意或格式，無法充分補償 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?
描述明確指出工具是取得「單一標案的完整歷程」，並列出具體包含的內容（每則公告、金額、得標廠商、競爭態勢、續約與否），動詞與資源清楚，且與兄弟工具 search_tenders（搜尋）明顯區隔。
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?
描述說明參數來源來自 search_tenders 的結果列，隱含應在搜尋後使用，但未明確說明何時不該用或相對於其他兄弟工具的選擇條件，僅屬暗示層級。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
流標機會：反覆流標、至今未決標的案子——競爭者少、機關急著發包， 是新廠商切入的好標的。回傳最新 10 筆。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無任何 annotation，描述承擔全部行為揭露責任。描述說“回傳最新 10 筆”，透露了輸出數量限制，但未提及權限要求、只讀性、或返回欄位格式。作為一個具抓取操作（僅回傳）的工具，缺少對響應結構或異常行為的明確描述，但並未與任何註記矛盾。
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?
描述簡潔精簡，用一句話概括功能（回傳樣態與目的），並加上“回傳最新 10 筆”的行為關鍵數據，無多餘字詞，開頭即點明主題，結構良好。
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，且屬簡易列表回傳，描述提供了“最新 10 筆”這個數量限制，足以讓代理了解基本行為。但未指明回傳欄位（如投標編號、機關名稱等），雖然沒有輸出 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?
該工具沒有參數（參數數為0），schema 欄位說明覆蓋率為100%，因此描述無需補充參數語義。依規則，當無參數時基準分為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?
描述明确说明工具返回的是“流標機會”——反复流标、至今未決標的案子，動詞“回傳”清楚指向操作，資源名稱與內容相呼應。它與兄弟工具（search_tenders、get_tender）有明確區隔，因為它聚焦於特定狀態（流標）且無需參數。
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?
描述中“競爭者少、機關急著發包，是新廠商切入的好標的”提供了使用情境（適合新廠商尋找切入點），但沒有明確說明何時不該使用此工具，也沒有提到替代工具（如search_tenders）的比較。缺少具體的當用/不用條件，僅有隱含場景。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
底價分析：這個案子大概會以多少錢成交。 依歷史「決標／預算比」給三檔出價建議（保守／典型／積極）， 比較基準依樣本充足度自動選：相似案（標題關鍵詞比對）＞同機關＞同類別＞全庫。 適合在使用者問「這案該報多少」「值不值得投」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the key behavioral logic: the comparison baseline selection order (similar cases > same agency > same category > full database). However, it omits details such as whether the tool is read-only, output format, or any limitations, which are important for an agent to fully understand the tool's behavior.
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 and information-dense, covering the key aspects in a few lines. It is well-structured with a clear purpose, usage scenario, and methodology. It loses one point because the parameter explanations are absent, which is a structural gap.
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 annotations, no output schema, and zero parameter descriptions, the tool description is incomplete for an agent to fully utilize it. It explains the high-level analysis logic but lacks details about return values, error cases, or parameter constraints, leaving significant gaps in practical usage.
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 0%, and the description does not compensate by explaining what unit_id and job_number mean. While the parameter names give some hint (job_number likely a tender number), the description provides no explicit semantics, making it difficult for an agent to correctly fill in the parameters without additional knowledge.
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's function: price analysis for predicting likely winning prices, with three bid suggestions based on historical award/budget ratios. It distinguishes itself from sibling tools by focusing on pricing prediction, whereas siblings like compare_vendors or hot_opportunities serve different purposes.
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 mentions when to use it: when users ask 'how much should I bid' or 'is it worth bidding'. It provides clear context but does not mention exclusions or alternative tools, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋政府標案公告。
q: 關鍵字（比對標題與機關名，例「冷氣」「智慧路燈」）。
kind: tender=招標中 / award=已決標 / failed=流標，空=全部。
region: 縣市（例「台北市」「高雄市」，「臺」寫成「台」）。
year: 西元年（例 2026）。
unit_id: 機關代碼（用 find_entity 取得）——查「某機關發的案」用這個，
比 q 精確（q 是全文比對）。
vendor: 廠商名稱（正式全名）——查該廠商投標／得標過的案。
budget_min/budget_max: 預算金額範圍（新台幣元）。
回傳最新 10 筆與總數；需要更多用 page 翻頁。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| kind | No | ||
| page | No | ||
| year | No | ||
| region | No | ||
| vendor | No | ||
| unit_id | No | ||
| budget_max | No | ||
| budget_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations，描述承擔行為揭露責任。說明回傳「最新 10 筆與總數」及分頁機制，提供實際調用後的行為預期。雖未明說為唯讀操作，但由搜尋語意可合理推斷。
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?
9 個參數全數解釋，包含格式、範例及用途；同時說明回傳內容與分頁，無輸出 schema 的情況下已提供足夠資訊，使 agent 能正確呼叫。
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 為 0%，描述完全補償，對每個參數（q、kind、region、year、unit_id、vendor、budget_min/max）都給出具體語意與範例，讓 agent 能正確填值。
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?
描述明确說明「搜尋政府標案公告」，動詞+資源清晰。但未明確與兄弟工具（如 get_tender、find_entity）區分，不過本身功能已足以辨識。
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?
描述詳細說明每個參數的使用情境，例如 unit_id 用於查某機關的案且比 q 精確、vendor 查廠商投標紀錄，提供清晰的上下文與選擇依據。但未明確提及何時不該用此工具或替代工具，故未滿分。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
機關情報報告：發包規模與金額、主要供應商、供應商集中度、 競爭程度（平均投標家數／單一投標率／流標率）、發案旺月，以及 「固定週期標案」——每年重複招標的案與預估下次發案時間。 unit 可以是機關代碼（如 3.76.54）或機關全名（會自動查代碼）。 適合回答「這個機關好不好投」「它什麼時候會再發案」。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無任何 annotations，描述必須承擔行為說明責任。描述說明了 unit 可接受代碼或全名且會自動查代碼，但未揭露是否為唯讀操作、回傳格式、資料時效或潛在限制。以報告型工具而言，這些資訊對 AI 正確使用有幫助，但描述僅部分提供。
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 僅有 unit 的型別與欄位名，描述明顯補足了語意：說明 unit 可以是機關代碼或全名，並舉例（如 3.76.54）。因為 schema 覆蓋率 0%，描述成功補償參數意義，僅未給出完整格式規範，故給 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?
描述清楚指出工具的用途是產生機關情報報告，並具體列出報告涵蓋的資料類別（發包規模、供應商、競爭程度、發案旺月、固定週期標案等），與其他兄弟工具如 vendor_report、search_tenders 明顯區隔。參數 unit 的用法也有說明。
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?
描述明確指出「適合回答『這個機關好不好投』『它什麼時候會再發案』」，提供了清楚的使用情境，讓 AI 能判斷何時選用此工具。但未提及何時不該使用或明確的替代工具名稱，因此未達 5 分。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
廠商情報報告：得標率、已知得標總額、最大客戶、單一投標比例 （開標時只有它一家的案子占比，全庫平均 50.1%）、最常交手的對手與相對勝率、 近期得標與「近期輸給誰」。name 必須是正式全名（先用 find_entity 查）。 適合分析競爭對手或盡職調查。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains what data the report contains, defines the sole-bid ratio metric with a database average reference, and uses 'known' to caveat the awarded total amount. It does not explicitly state read-only behavior or error handling, but as a report tool the content list and metric definitions give the agent a strong behavioral picture.
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 compact and front-loaded: it opens with the report type, lists all included metrics in one efficient sentence, then adds a critical parameter instruction and use-case note. Every sentence earns its place, and the parenthetical definition of the sole-bid ratio adds real value without bloat.
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 there is no output schema, the description compensates well by enumerating the report's content, including win rate, total awarded amount, largest client, sole-bid ratio, competitors, and recent outcomes. It also covers the required input precondition. It could be more complete by describing the output format or behavior when the vendor is not found, but the listed metrics give an agent sufficient context to invoke and interpret 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?
Schema description coverage is 0%, so the description must compensate. It directly addresses the only parameter, name, by specifying it must be the formal full name and instructing the agent to look it up via find_entity. This is strong parameter guidance, though an example value or format hint would make it even clearer.
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 defines the tool as a vendor intelligence report, listing concrete metrics such as win rate, known total awarded amount, largest client, sole-bid ratio, main competitors, and recent wins/losses. This specific deliverable distinguishes it from sibling tools like compare_vendors, which compares vendors, and search_tenders, which searches tenders. The verb 'report' and the detailed metric list make the purpose unmistakable.
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 gives an explicit prerequisite: the name must be the formal full name, and find_entity should be used first. It also states the intended use case ('suitable for analyzing competitors or due diligence'). However, it does not explicitly say when not to use this tool or mention alternatives, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Taiwan Government Procurement MCP — 政府電子採購網 (PCC) tenders (keyless).
Taiwan legal research: court judgments, statutes, and interpretations. 台灣判決、法條、函釋、釋字搜尋。
Search U.S. federal, state, and local government procurement data and intelligence.
9.9M+ tenders, RFPs & grants. 60 countries with a national procurement source, 193 with any record.
Add one secure layer between your agents and this server.
每個工具都有明確且獨特的用途：搜尋、查詳情、找實體、分析價格、產生報告等，彼此之間幾乎沒有重疊。find_entity 明確定位為其他工具的前置查詢，不會與其他工具混淆。
所有工具名稱皆為全小寫加下劃線的風格，整體一致。雖然部分為動詞開頭（compare, find, get, search），部分為名詞短語（hot_opportunities, price_analysis, unit_report），但皆清晰可讀，無混用駝峰或不同風格。
8 個工具數量適中，既涵蓋搜尋、明細、分析、報告等核心功能，又不會過度冗餘。每個工具都有明確的存在價值，沒有多餘或過於精簡的情況。
以政府標案查詢與分析為目的，工具面覆蓋了搜尋標案、取得詳細歷程、價格預測、流標機會、機關與廠商報告，以及廠商對比。未涵蓋的操作如建立或修改標案並不屬於此類資訊服務的範圍，因此沒有明顯缺口。
