Skip to main content
Glama
deenesjakoruzh
Yunwcy

Portfolio MCP Server

by Yunwcy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Portfolio MCP 伺服器

一個 MCP（模型上下文協定）伺服器，將吳承運的作品集（專案、技能和履歷）以工具形式公開，讓任何相容 MCP 的 AI 助手（Claude Desktop、Claude.ai Connectors、MCP Inspector 等）可以直接呼叫，無需從網站擷取資料。

為何存在

我想真正了解 MCP 是如何端到端運作的，而不只是閱讀相關資料——因此我建立了一個小型伺服器，將我的作品集網站內容轉換為結構化工具。這也是一個刻意學習兩項我之前較少觸及技術的理由：Docker 和基本的 CI/CD 流程，這兩者在我鎖定的求職資訊中反覆出現。

Related MCP server: Bijon Portfolio MCP Server

MCP 簡介

MCP 是一個開放協定（來自 Anthropic），讓 AI 助手可以呼叫外部「工具」——具有名稱、描述和綱要的型別化函式——以取得即時資訊或執行操作，而不僅依賴訓練資料或貼上的文件。伺服器宣告其工具；任何支援 MCP 的用戶端都可以發現並呼叫它們。此專案就是這樣一個伺服器：它宣告了四個由我自己的作品集資料支援的工具。

工具

工具

功能

list_projects()

每個作品集項目——已上線系統、競賽作品、研究專案、已發表論文和課程報告，不限於旗艦案例研究——包含 ID、名稱、標語、類別、年份、一行摘要，以及其清單中的連結（線上系統、GitHub、報告、展示影片等）

get_project_details(name)

一個項目的完整記錄。對於旗艦專案：角色、技術棧、問題、挑戰與解決方案、成果、連結。對於較輕量的項目：檔案中有的所有資料——至少包含描述和連結。比對有容錯性且支援別名（"lab handover" → ifit-lab-handover；"NTPU OPE Assistant" → 它實際上的論文系統）

search_skills(keyword)

在技能分類中進行關鍵字搜尋，按相關性排序，每個結果列出展示該技能的專案

get_resume_summary(length)

自我介紹（"short" / "medium" / "long"），以及聯絡資訊

每個工具的 docstring 就是 AI 助手實際閱讀以決定何時呼叫的內容——請參閱 src/portfolio_mcp/server.py。

涵蓋範圍： data/projects.json 包含全部 31 個作品集項目——7 個深度案例研究（已上線系統、論文、NSTC 研究專案、獲獎論文）加上 24 個較輕量的條目（其他競賽作品、課程報告、會議論文）。每個項目都至少包含一個連結。課程階段報告和附屬論文包含一個 related_project ID，指向其歸屬的完整案例研究，讓助手可以從報告深入探索完整故事。

架構

Claude Desktop / Claude.ai / MCP Inspector
              │  (stdio locally, or Streamable HTTP remotely)
              ▼
      MCPServer instance (server.py)
              │  registers 4 tools
              ▼
       tools.py  (pure, unit-tested logic)
              │
              ▼
   data_loader.py  →  data/*.json  (projects, skills, resume)

  • 傳輸方式： Streamable HTTP，而非 stdio——重點是遠端用戶端（例如 Claude.ai 的 Connectors）可以透過公開 URL 連線到此伺服器，而不僅是本地啟動的進程。為了本地 Claude Desktop / MCP Inspector 測試，仍支援 Stdio。

  • 資料層： data/ 下的三個平面 JSON 檔案，載入一次後快取（functools.lru_cache）。無資料庫——資料量小、公開且極少變更。

  • 工具邏輯 vs. MCP 佈線： 刻意分開（tools.py vs. server.py），讓邏輯可以在沒有執行中 MCP 伺服器或傳輸方式的情況下進行單元測試。

  • SDK 說明： 官方的 mcp Python SDK 在 v2.0.0 將其高階伺服器 API 從 FastMCP 遷移至 mcp.server.mcpserver.MCPServer——此專案針對 mcp>=2.0.0 和該當前 API。如果您看過使用 from mcp.server.fastmcp import FastMCP 的舊版 MCP 教學，那是 2.0 前的 API，無法針對 pip install mcp 目前提供的內容進行匯入。

專案結構

portfolio-mcp-server/
├── data/                      # projects.json, skills.json, resume.json
├── src/portfolio_mcp/
│   ├── server.py              # MCPServer app: registers tools, stdio/HTTP entrypoints, /chat route
│   ├── tools.py                # MCP tool logic (testable, no MCP dependency)
│   ├── chat.py                  # /chat: Claude + Tool Runner over the same data, for the site's Q&A widget
│   └── data_loader.py          # cached JSON loading
├── tests/                      # pytest suite run in CI (tools, server security, chat, chat route)
├── Dockerfile                  # python:3.12-slim + uvicorn, Streamable HTTP
├── .github/workflows/ci.yml    # lint (ruff) + test (pytest) on every push
└── claude_desktop_config.json  # example config for local stdio testing

本地執行

# from the repo root
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

選項 A——stdio，搭配 MCP Inspector

npx @modelcontextprotocol/inspector python -m portfolio_mcp.server

開啟一個本地網頁 UI，您可以在其中直接呼叫每個工具並檢查請求/回應。

選項 B——stdio，搭配 Claude Desktop

將 claude_desktop_config.json 中的 mcpServers 條目合併到您自己的 Claude Desktop 設定中（設定 → 開發者 → 編輯設定），修正您機器上的路徑，然後重新啟動 Claude Desktop 並詢問類似 "這個人做過哪些專案？" 的問題。

選項 C——Streamable HTTP，本地執行

TRANSPORT=http python -m portfolio_mcp.server
# equivalent — both serve the exact same ASGI app, /chat included:
uvicorn portfolio_mcp.server:app --host 0.0.0.0 --port 8000

測試

pytest -v
ruff check .

使用 Docker 執行

docker build -t portfolio-mcp-server .
docker run -p 8000:8000 portfolio-mcp-server

容器始終提供 Streamable HTTP（這就是容器化的重點——一個可攜帶、可公開服務的單元，而非綁定於單一機器的 stdio 進程）。

部署（Render）

選擇的部署目標：Render，免費方案——它執行長生命週期容器（非具有執行時間限制的無伺服器函式），這是 Streamable HTTP 持續連線所需的條件，且開始使用無需信用卡。

  1. 將此儲存庫推送到 GitHub。

  2. 在 render.com 上：新建 → Web 服務 → 連接此儲存庫。

  3. Render 會自動偵測 Dockerfile 並將其建置/執行為容器。

  4. 選擇 免費 方案類型 → 您會獲得一個 https://<something>.onrender.com 的 URL。

  5. 驗證它是否在線：

    npx @modelcontextprotocol/inspector https://<something>.onrender.com/mcp

  6. （可選）啟用 Render 的 GitHub 自動部署，讓 git push 到 main 時自動重新部署——配合下方的 CI 流程，這就是完整的 CI/CD 故事。

免費方案說明： Render 的免費 Web 服務在閒置約 15 分鐘後會休眠，並在下次請求時需要 30-60 秒喚醒。對於作品集展示來說沒問題；如果被問到，值得提一下這是一個刻意的成本/延遲權衡。

即時部署： https://yun-portfolio-mcp.onrender.com/mcp——將 MCP 用戶端連接到此 URL（注意 /mcp 路徑；裸域名會回傳 404，這是預期的——Streamable HTTP 僅服務該一個路徑）。使用 npx @modelcontextprotocol/inspector https://yun-portfolio-mcp.onrender.com/mcp 自行驗證。

如果您 fork 此專案： server.py 中的 Host 標頭允許清單預設為 yun-portfolio-mcp.onrender.com（DNS 重新綁定保護會拒絕任何其他 Host 標頭並回傳 421）。將 MCP_ALLOWED_HOSTS 環境變數設定為您自己部署的主機名稱，或直接編輯 ALLOWED_HOSTS。

聊天端點（/chat）——作品集網站的問答小工具

同一個 Render 服務上的第二個獨立入口，用於嵌入在 yunwcy.github.io 上的純聊天小工具——不屬於上述的 MCP 協定範圍。 瀏覽器將 {"message": "..."} POST 到 /chat；伺服器使用 Anthropic Tool Runner 讓 Claude 決定呼叫哪一個相同的四個工具（透過直接呼叫 tools.py——不涉及 MCP 握手），然後回傳 {"reply": "..."}。完整實作請參閱 src/portfolio_mcp/chat.py。

為何這需要真實後端，而僅 GitHub Pages 無法做到： 用自然語言回答需要 LLM 看到問題並決定要呼叫哪個工具，這需要 Anthropic API 金鑰——而金鑰絕不能放在靜態網站的用戶端 JS 中，因為任何人都可以檢視原始碼並消耗帳戶額度。/chat 將金鑰保持在伺服器端（Render 環境變數，從不發送到瀏覽器），並且只將瀏覽器需要的小工具發送到 GitHub Pages。

設定（此端點運作前的必要條件）：

  1. 從 Anthropic Console 取得 API 金鑰，並將其作為 ANTHROPIC_API_KEY 環境變數新增到 Render（Render 儀表板 → 此服務 → 環境）。沒有它，/chat 會回傳 503 {"error": "not_configured"} 而非使伺服器崩潰。

  2. CHAT_ALLOWED_ORIGINS（逗號分隔）控制 CORS——預設為 https://yunwcy.github.io。如果小工具位於其他地方，請進行設定。

  3. ANTHROPIC_CHAT_MODEL（預設 claude-opus-5）——最強大的通用選擇，但這是一個簡單、可能高流量、成本敏感的公開小工具，因此 claude-haiku-4-5 在此特別值得考慮。這是一個刻意留給執行伺服器的人決定的選擇，而非寫死。

  4. CHAT_RATE_LIMIT_PER_HOUR（預設 30）——一個簡單的記憶體內每 IP 限制，使單一訪客無法獨自耗盡帳戶額度。每次重新啟動/重新部署時會重設，且不會在實例間共享——對於低流量的個人網站來說足夠，而非通用的濫用防禦。

CI/CD

.github/workflows/ci.yml 在每次推送/PR 到 main 時執行：安裝套件、使用 ruff 進行 lint，並執行 pytest 套件。Render 的 GitHub 自動部署（見上方）處理 CD 部分。

安全性/成本說明

  • MCP 工具範圍（/mcp）本身不呼叫任何 LLM——它僅讀取本地 JSON 並回傳。連接的使用者（他們的 Claude、他們的 token）承擔該成本，而非此伺服器。

  • /chat 端點會呼叫 LLM，使用此伺服器自己的 Anthropic API 金鑰——這就是重點（瀏覽器無法安全地持有金鑰）。成本受每 IP 速率限制、effort: "low" 和較小的 max_tokens 約束；請參閱上方的聊天端點章節了解控制選項。

  • 所有資料已經在我的作品集網站上公開——兩個端點均未實作驗證，因為沒有需要保護的私有內容。/chat 的 CORS 允許清單存在是為了控制誰可以花費 API 預算，而非保護資料。

更新資料

直接編輯 data/ 下的 JSON 檔案——id 是 get_project_details 比對的穩定識別碼；其他所有欄位均為自由格式。內容更新無需程式碼變更。

Available Tools

4 tools
get_project_detailsA

Get the full record for one portfolio item. For a flagship project this includes role, tech stack, the problem it solved, challenges and how they were solved, outcomes, and links; for a lighter item (a course report, a smaller competition entry) it returns whatever is on file — at minimum a description and its links.

Args: name: A project name, id, or known alias/alternate name — e.g. "IM Your Buddy", "knovyra", "lab handover", "NTPU OPE Assistant", or a competition name like "North Taiwan University Alliance AI Agent Competition". Matching is forgiving (case-insensitive, partial, alias-aware), so you don't need the exact id from list_projects — but calling list_projects first helps pick the right one when unsure.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully bears the burden of behavioral disclosure. It clearly conveys the tool's non-destructive, read-only nature by stating it retrieves records. However, it does not disclose potential side effects like logging, or rate limits, which slightly limits transparency. The indication that matching is forgiving and alias-aware adds valuable behavioral context, justifying a 4.

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 efficiently structured, front-loading the tool's purpose in the first sentence, then elaborating on behavioral nuance (flagship vs lighter items) in a natural flow. Every sentence adds value, and the Args section is clearly separated and self-contained. There is no wasted 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 only one parameter, no annotations, and no output schema, the description provides sufficient context for an AI agent to select and invoke the tool correctly. It covers input semantics, matching behavior, variation in returned data, and even suggests a complementary sibling tool (list_projects). The description is complete for this single-param retrieval 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 schema has 0% description coverage and only one parameter ('name'), so the description must fully compensate. It excels by describing acceptable inputs (project name, id, alias, or competition name), provides concrete examples, and explains matching behavior (case-insensitive, partial, alias-aware). This adds rich semantics far beyond the schema's bare type declaration.

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 explicitly states the tool retrieves the full record for one portfolio item, differentiating between flagship projects (returns detailed fields like role, tech stack, outcomes) and lighter items (returns description and links). This clear verb+resource+variation makes the purpose highly specific and distinct from siblings like list_projects.

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 provides explicit guidance on when to use this tool (to get full details of a single portfolio item) and includes a clear when-not alternative: it advises calling list_projects first to select the right item when unsure about the name. This pre-emptive guidance prevents misuse and clarifies the tool's role in a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_resume_summaryA

Get a self-introduction / resume summary, plus name, title, and contact info. Use this to answer "tell me about yourself" or "give me a summary of this person's background" style questions.

Args: length: "short" for 1-2 sentences, "medium" for a paragraph, or "long" for a full narrative summary covering research, shipped projects, publications, and certifications. Defaults to "short".

ParametersJSON Schema
NameRequiredDescriptionDefault
lengthNoshort

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It explains what the tool returns (self-introduction, name, title, contact info) and the length parameter's effect. However, it does not mention whether the operation is read-only, any authentication requirements, or rate limits. For a simple get operation, this is adequate but not exceptional.

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 and front-loaded: two sentences of purpose followed by a clear parameter definition. Every sentence adds value, and there is no redundancy or filler.

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 simplicity (one parameter, no output schema), the description is largely complete. It covers what the tool returns and how to use the length parameter. It could be slightly more explicit about the return format or structure, but it is sufficient for an agent to invoke correctly.

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?

Schema description coverage is 0%, so the description must compensate for the lack of parameter info. It does so excellently by explaining the 'length' parameter with three concrete options ('short', 'medium', 'long') and their meanings. This adds significant value beyond the schema's bare type and default.

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's purpose: 'Get a self-introduction / resume summary, plus name, title, and contact info.' It also provides concrete use cases ('tell me about yourself' or 'give me a summary of this person's background'). This distinguishes it from sibling tools like list_projects and search_skills.

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 tells when to use the tool: 'Use this to answer... style questions.' This gives clear context. However, it does not explicitly state when not to use it or point to alternative tools, which would be a minor improvement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsA

List every item in the portfolio — shipped systems, competition entries, research projects, published papers, and course reports, not just the flagship case studies — with id, name, tagline, category, year, a one-sentence summary, and its links (live system, GitHub, report, demo video, etc., whichever apply). Links are included right here, so a system or report can be pointed to without a second call. An entry's related_project (when present) is the id of a fuller case study it's a stage or companion piece of — pass that id to get_project_details for the deep-dive version. Call this first for any broad question like "what has this person worked on?" or "does a system exist for X?".

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It explains that links are included to avoid a second call, and describes the related_project field and its purpose. It does not mention any side effects (none expected), but could be more explicit about the read-only nature. Still, it provides useful behavioral context beyond a simple list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear topic sentence, then enumeration of fields, an explanation of related_project, and usage guidance. Every sentence adds value. It is slightly long but not verbose; it could be tightened slightly (e.g., remove 'whichever apply' as it's implied).

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 the tool has no parameters and an output schema exists, the description is quite complete. It explains the output fields, the role of related_project, and when to use it. However, it does not mention ordering or limiting of results, and the portfolio size is assumed small. For most use cases, this is sufficient.

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 schema coverage is 100% trivially. The baseline for no parameters is 4, as the description does not need to add parameter semantics. However, it does describe the output fields, which is beneficial for understanding the tool's result but not directly about input parameters.

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 every item in the portfolio with specific fields, and distinguishes itself from the sibling 'get_project_details' by emphasizing that links and related_project are included for a comprehensive overview. The verb 'List' and resource 'projects' are specific, and the mention of 'not just the flagship case studies' clarifies scope.

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 usage guidance is provided: 'Call this first for any broad question like "what has this person worked on?" or "does a system exist for X?".' This tells the agent when to use this tool and implicitly when not to (e.g., deep-dive should use get_project_details). No exclusions or alternatives needed beyond the sibling context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_skillsA

Search the skills/technology taxonomy by keyword and return matches ranked by relevance, each with the projects that demonstrate it. Use this to answer questions like "does this person know RAG / Docker / vector databases / iOS development?".

Args: keyword: A skill, technology, or category to search for, e.g. "RAG", "Docker", "vector database", "iOS", "Next.js".

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

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 discloses that results are ranked by relevance and include projects, but does not explicitly state that the tool is read-only, mention any authentication needs, rate limits, or edge cases like no matches. It is adequate but lacks depth.

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 paragraphs: the main purpose and the args section. Every sentence adds value, and the examples are front-loaded. There is no waste, and the structure is efficient.

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's simplicity (single parameter, output schema exists), the description is complete. It explains the search behavior, relevance ranking, and inclusion of projects. Since an output schema is present, there is no need to detail return values.

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 has a single parameter 'keyword' with 0% description coverage. The description compensates fully by providing clear examples ('e.g., "RAG", "Docker", "vector database", "iOS", "Next.js"') and explaining the expected format, which adds significant meaning 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 uses a specific verb ('search') and resource ('skills/technology taxonomy'), states it returns matches ranked by relevance with projects, and provides example questions like 'does this person know RAG / Docker / vector databases / iOS development?' This clearly distinguishes it from sibling tools (list_projects, get_project_details, get_resume_summary).

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 says 'Use this to answer questions like...' which gives clear context for when to use the tool. While it does not mention when not to use it or name alternatives, the sibling tools are not related to skills search, so the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedget_project_details
    • First observedget_resume_summary
    • First observedlist_projects
    • First observedsearch_skills
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct, well-defined purpose. list_projects provides an overview, get_project_details provides deep dives on individual entries, search_skills queries the technology taxonomy, and get_resume_summary returns background info. There is no overlap or ambiguity between any of these tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_projects, get_project_details, search_skills, get_resume_summary). The naming clearly indicates what action is being taken and on what resource, making the API predictable and easy to navigate.

Tool Count5/5

With exactly 4 tools covering portfolio browsing, detail retrieval, skill search, and resume summary, the number is well-scoped for a personal portfolio MCP server. No tools are missing, and every tool serves a distinct, necessary function without redundancy.

Completeness5/5

The tool set provides a complete coverage of the portfolio domain: listing all entries, retrieving full details for any entry, searching across skills/tags, and providing a professional summary. There are no obvious gaps—a user can explore projects, drill into details, assess expertise, and get background information.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • personal-mcp

    gauransh18
    F
    license
    Not graded
    quality
    D
    maintenance
    Exposes personal portfolio data as tools for Claude to answer questions about the developer, including profile, skills, experience, projects, and contact information.
    -

  • Resume MCP Server

    Adarshcharjan
    A
    license
    Not graded
    quality
    D
    maintenance
    Exposes a structured professional resume as a set of AI-queryable tools, enabling AI clients like Claude Desktop to query summary, experience, skills, projects, and tailor resumes to job descriptions.
    1
    MIT

  • resume-mcp

    suryakapila
    F
    license
    A
    quality
    B
    maintenance
    MCP server that exposes a resume as callable tools and resources, enabling AI agents to query experience, skills, projects, and contact information via natural language.
    3
    -