autodesk-platform-services APS MCP Server Generator
This skill creates a fully working MCP server project that connects to Autodesk Platform Services (APS). Follow the steps below exactly.
Step 1 — Gather Requirements
Ask the user all three questions at once if they have not already answered:
- Language — Node.js/TypeScript, .NET/C#, or Python?
- Transport — Local (STDIO, for Claude Desktop or similar) or Cloud (Streamable HTTP, for web deployment)?
- Authentication — Which APS auth pattern?
- 2-legged OAuth — app accesses its own resources; no user sign-in (note: legacy, but still supported)
- Secure Service Accounts (SSA) — automated server-to-server; acts on behalf of a real user without interactive login
- 3-legged OAuth — user signs in via browser; server acts on their behalf
If the user's request already makes one of the choices clear (e.g., "Python FastMCP server"), skip that question.
Step 2 — Load Reference Docs
Before writing any files, load the appropriate references:
- Node.js → read
references/nodejs.md - .NET → read
references/dotnet.md - Python → read
references/python.md - 2-legged OAuth → read
references/auth-2lo.md - Secure Service Accounts → read
references/auth-ssa.md - 3-legged OAuth → read
references/auth-3lo.md - STDIO → read
references/transport-stdio.md - Streamable HTTP → read
references/transport-http.md - Always → read
references/testing.md
Step 3 — Confirm Output Directory
Ask or confirm where to create the project (default: ./aps-mcp-server in the current directory).
Step 4 — Scaffold the Project
Create every file needed for a working project. Do not leave placeholder TODOs — generate complete, runnable code. Use the patterns from the reference files exactly.
Files to create (all languages)
| File | Purpose |
|---|---|
.env.example |
All required env vars with placeholder values and comments |
README.md |
Setup, run, MCP client config, and test instructions |
| Main server file | Language-specific entry point |
| Tool file(s) | At least one example APS tool (e.g., list OSS buckets) |
| Auth helper | Token acquisition logic for the chosen auth type |
| Test file(s) | Unit tests with mocked APS calls (see testing.md) |
Language-specific additional files
- Node.js:
package.json,tsconfig.json(if TypeScript),vitestdev dependency - .NET:
.csproj,appsettings.json,*.Testsproject with xUnit + NSubstitute - Python:
pyproject.toml(uv-managed),pytest+pytest-asynciodev dependencies
Step 5 — Post-Scaffold Instructions
After creating files, tell the user:
- How to install dependencies (including test dependencies)
- How to fill in
.env(which APS portal pages to visit for each credential) - How to run the unit tests (no credentials required)
- How to run the server
- How to connect to it from an MCP client (Claude Desktop config or Inspector URL)
- How to run an interactive smoke test with MCP Inspector
Key Rules
- Never implement token passthrough. The MCP server must authenticate with APS itself — it must never accept APS tokens from the MCP client and forward them.
- Always cache tokens. Check expiry before every APS call; refresh proactively (≥60 s before expiry).
- STDIO ↔ Stateless HTTP distinction. STDIO servers are inherently single-session. Streamable HTTP servers should default to stateless (no session ID) unless 3-legged OAuth is chosen, which requires stateful sessions to track per-user tokens.
- Tool descriptions matter. Write clear docstrings/descriptions for every tool — the LLM uses them to decide when to call each tool.
- Return both
contentandstructuredContentin Node.js tools when the data could be consumed programmatically (e.g., by a UI component). Python FastMCP infers structured output automatically from return types.