Skip to main content
Glama
teamsparta-biz

padlet-mcp

by teamsparta-biz
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

padlet-mcp

Padlet REST API를 감싸는 MCP 서버. Claude Code가 Padlet 보드를 읽을 수 있게 해준다. 읽기 전용 — 글쓰기/수정/삭제는 안 됨.

1. 설치

Python 3.10+ 만 있으면 된다 (uv 등 추가 도구 불필요):

pip install --user git+https://github.com/teamsparta-biz/padlet-mcp

새 버전이 올라온 뒤 갱신하려면:

pip install --user --upgrade git+https://github.com/teamsparta-biz/padlet-mcp

Related MCP server: AI Sticky Notes

2. API 키 받기

공용 biz 계정으로 로그인해서 https://padlet.com/settings/api 에서 키 값을 복사한다. 팀 전체가 공유하는 유일한 키이니 외부 공개 채널이나 커밋에는 올리지 말 것.

복사한 키는 Claude Code한테 그대로 던져주고 "이 키로 padlet-mcp 설정해줘"라고 하면 알아서 저장하고 연동까지 해준다.

3. 설치 확인 (테스트)

Claude Code에 등록하기 전에, 키 설정이 맞는지 먼저 확인하자.

가장 간단한 방법 — Padlet API를 직접 호출해서 실제 보드 목록이 나오는지 확인:

python -c "from padlet_mcp.server import list_boards; import json; print(json.dumps(list_boards(), indent=2))"

에러 없이 본인 보드 목록(JSON)이 출력되면 키 설정이 정상이라는 뜻이다. (한글은 \uXXXX로 이스케이프되어 나오는 게 정상 — Windows 콘솔 인코딩 때문이며 실제 값은 깨지지 않는다.)

MCP 프로토콜 그대로 테스트하고 싶다면 (MCP Inspector 사용, Node.js 필요):

npx @modelcontextprotocol/inspector python -m padlet_mcp

브라우저가 열리면 list_boards/get_board 툴을 직접 호출해볼 수 있다.

4. Claude Code에 등록

프로젝트 루트에서:

claude mcp add padlet --scope project -- python -m padlet_mcp

또는 .mcp.json에 직접 추가:

{
  "mcpServers": {
    "padlet": {
      "type": "stdio",
      "command": "python",
      "args": ["-m", "padlet_mcp"],
      "env": {}
    }
  }
}

claude mcp list로 padlet이 떠 있는지, 도구가 정상 등록됐는지 확인.

5. 문제 해결

  • "Padlet API 키를 찾을 수 없습니다" — 2단계의 키 저장이 안 된 것. Claude Code한테 다시 키를 주고 설정해달라고 하면 된다.

  • pip install 시 "script ... is not on PATH" 경고 — 무시해도 된다. python -m padlet_mcp로 실행하므로 Scripts 폴더가 PATH에 없어도 상관없다.

  • Claude Code에서 padlet 툴이 안 보임 — .mcp.json 등록 후 Claude Code를 재시작해야 반영된다.

로컬 개발 (기여자용)

이 저장소를 clone해서 직접 고칠 때는 uv를 쓰면 편하다 (필수는 아님, pip install -e .로도 가능):

uv sync
uv run padlet-mcp

Available Tools

2 tools
get_boardB

보드 하나의 섹션·게시물·댓글을 모두 가져와 정리된 형태로 반환한다.

board_id는 list_boards로 얻은 16자리 보드 ID다 (padlet.com URL의 슬러그가 아님).

ParametersJSON Schema
NameRequiredDescriptionDefault
board_idYes

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden. It states the tool returns all sections, posts, and comments, but provides no details on side effects, return structure, permissions, pagination, or error behavior. This is a significant gap for a read tool with complex output.

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 two concise sentences, front-loaded with the primary purpose and followed by a key parameter clarification. Every sentence earns its place, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description covers the essential purpose and parameter origin. However, it omits details on the return format (beyond 'organized form'), potential large result sets, or error cases, leaving gaps for an agent to fully understand invoking this 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 parameter board_id has zero schema description coverage, but the tool description compensates by explaining it is a 16-digit ID from list_boards, not the URL slug. This adds critical semantic meaning beyond the schema's minimal type/required fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches all sections, posts, and comments of a single board and returns them in an organized form. This is a specific verb+resource that distinguishes it from the sibling list_boards, though it does not explicitly contrast the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining that board_id is obtained from list_boards, suggesting a sequential workflow. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, so guidance is only implied.

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

list_boardsA

현재 API 키로 접근 가능한 보드(Padlet) 목록을 반환한다.

각 보드의 id(get_board에 쓰는 16자리 식별자), 제목, 공개 URL을 담는다. padlet.com URL만 알고 있을 때는 이 목록에서 web_url을 비교해 board_id를 찾는다.

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 transparency burden. It discloses that the tool lists boards accessible with the current API key, returns id, title, and public URL, and explains the URL-to-ID mapping utility. It does not explicitly state 'read-only' but the list semantics imply no side effects. Some detail like pagination or error cases is missing, but for a simple read operation this is adequate.

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 two sentences with no fluff. The first sentence states the core purpose, the second sentence explains the return fields and a practical use case. Every sentence earns its place and the structure is clear.

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 list tool with zero parameters and an existing output schema, the description covers the essential behavior (list boards, fields returned, and the URL-to-ID lookup scenario). It is complete for its complexity, though it omits edge cases like pagination, which are not critical for this 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, and the schema is empty. The description correctly avoids discussing parameters. The baseline for 0 params is 4, and no additional semantic value is needed since there are no inputs to explain.

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 ('반환한다' / returns) and resource ('보드(Padlet) 목록' / board list), and clearly states the scope ('현재 API 키로 접근 가능한' / accessible with current API key). It also distinguishes from the sibling tool by mentioning the 16-digit board ID used in get_board, showing this tool provides the mapping between URL and ID.

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 provides a clear use case: when you only know a padlet.com URL, use this list to compare web_url and find board_id. This implicitly tells the user when to use list_boards, though it does not explicitly say 'use get_board when you already have the ID'.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: list_boards returns a collection of boards, while get_board returns the full contents of a single board. There is no overlap in their functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: list_boards and get_board. The naming style is uniform and predictable.

Tool Count3/5

With only two tools, the server feels thin, but it may be intentionally scoped for read-only board access. The count is borderline, not clearly excessive or insufficient.

Completeness3/5

The tool surface covers listing boards and fetching full board contents, but lacks any create, update, or delete operations. This is a notable gap for a Padlet integration, though it may work for read-only use cases.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/teamsparta-biz/padlet-mcp'

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