Skip to content

Use tuples for tools/resources in plain.mcp docs - #100

Draft
davegaeddert wants to merge 1 commit into
masterfrom
claude/plain-mcp-readme-types-y10w13
Draft

Use tuples for tools/resources in plain.mcp docs#100
davegaeddert wants to merge 1 commit into
masterfrom
claude/plain-mcp-readme-types-y10w13

Conversation

@davegaeddert

Copy link
Copy Markdown
Member

MCPView.tools and MCPView.resources are annotated tuple[type[MCPTool], ...] / tuple[type[MCPResource], ...], and the framework convention is that declarative class attributes are tuples. The plain-mcp README examples and the MCPView / OAuthResourceServer docstrings still assigned lists.

Docs only — no runtime behavior changes.

Changes

  • plain-mcp/plain/mcp/README.md — every tools = [...] / resources = [...] example (and the two prose mentions) now uses tuple syntax, e.g. tools = (Greet,), resources = (AppVersion, AppReadme).
  • The two tools = [...] ellipsis placeholders in the OAuth section become a real one-element tuple tools = (MyTool,), so the snippet is valid as written.
  • The get_tools() override example returns list(self.tools) instead of self.tools, matching the documented list[type[MCPTool]] return type of get_tools().
  • plain-mcp/plain/mcp/views.py, plain-mcp/plain/mcp/oauth.py — same fix in the class docstrings.

Notes on the type-checking claim

The list form is a real type error under pyright (reportAssignmentType), which is what surfaced this. Worth noting for accuracy: ty — the checker ./scripts/type-check and plain check use — does not currently flag it. I verified this: even tools = 5 on an MCPView subclass passes ty today, so it doesn't validate assignments that override an inherited annotated attribute. So the shipped examples were not failing plain check; they were inconsistent with the documented convention and would fail for users on pyright/mypy.

Testing

  • ./scripts/fix — ruff check and ruff format pass. Its oxlint step could not run in this environment (TLS failure downloading the binary); no JS/CSS was touched.
  • ./scripts/test plain-mcp could not run here — no Postgres available in the sandbox. The change is markdown and docstrings only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MwkxmxUXppGucqgS7HGZnM


Generated by Claude Code

MCPView.tools and MCPView.resources are annotated
tuple[type[...], ...], and the framework convention is that
declarative class attributes are tuples. The README examples and the
MCPView/OAuthResourceServer docstrings still assigned lists, which
works at runtime but is a type error for anyone type checking their
app with a checker that validates inherited-attribute overrides.

Also replaces the `tools = [...]` ellipsis placeholders with a real
one-element tuple, and makes the get_tools() override example return
list(self.tools) so it matches the documented list return type.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MwkxmxUXppGucqgS7HGZnM
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants