Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add instructions/david3xu/azure-dev-server/claude-mdgit clone --depth 1 https://github.com/david3xu/azure-dev-serverWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/instructions/david3xu/azure-dev-server/claude-md)<a href="https://agentmods.dev/instructions/david3xu/azure-dev-server/claude-md"><img src="https://agentmods.dev/badge/instructions/david3xu/azure-dev-server/claude-md.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.01749 | $0.01749 |
| Opus 5 | $0.00874 | $0.00874 |
| Sonnet 5 | $0.00350 | $0.00350 |
| Haiku 4.5 | $0.00175 | $0.00175 |
Grade A, and why
azure-dev-server CLAUDE.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
azure-dev-server — Agent Guidelines
Updated: March 29, 2026 Canonical source for all azure-dev-server metrics, commands, and gotchas.
Project overview
Remote MCP server that exposes filesystem and shell access over Streamable HTTP transport. A cloud-hosted Desktop Commander for Claude Desktop. Designed to run on Azure (Container Apps or Functions) so Claude Desktop can read, write, build, and test on a remote machine.
Build & test commands
pnpm run build # TypeScript → dist/
pnpm run lint # ESLint strict checks
pnpm run format:check # Prettier formatting check
pnpm run format # Auto-format all files
pnpm run type-check # TypeScript type checking
pnpm run test # Node.js built-in test runner (25 tests, 8 suites)
pnpm run check # All of the above in sequence
pnpm run start # Run compiled server (dist/server.js)
Architecture
src/
server.ts → How does the HTTP server start and route requests?
tools.ts → What tools can Claude Desktop use remotely?
fs-ops.ts → How are filesystem read and search operations implemented?
auth.ts → How are requests authenticated?
types.ts → What shapes exist?
tests/
server.test.mjs → Does the HTTP server start and respond correctly?
tools.test.mjs → Do the phase-2 tools (edit_file, search_files) behave correctly?
fs-ops.test.mjs → Do the filesystem read and search operations work correctly?
Dockerfile → Multi-stage build: builder (compile) → runner (prod deps + dist/)
docker-compose.yml → Local testing with /workspace volume mount
.dockerignore → Excludes node_modules, dist, .git, tests from build context
Each source file answers ONE question. No file has two jobs.
Source is TypeScript (strict mode). Compiled to dist/ via pnpm run build.
Tests import from dist/. Entry point: dist/server.js.
Azure deployment
| Resource | Name |
|---|---|
| Resource Group | rg-datacore (australiaeast) |
| Container Registry | acrdevserver.azurecr.io |
| Container App | ca-dev-server |
| FQDN | ca-dev-server.purplegrass-77b8c839.australiaeast.azurecontainerapps.io |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 149 lines · 1,749 tokens per session scan A 9616ff1ae840
azure-dev-server CLAUDE.md is an instructions file published in the GitHub repository david3xu/azure-dev-server (0 stars, last pushed 2mo ago), licensed MIT. It adds 1,749 tokens to every session, about $0.0087 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other instructions, from other repositories
AppClaw CLAUDE.md
Claude Code instructions for appclawhq/AppClaw, covering claude.md, what is appclaw?, build & run commands, architecture and entry point & cli modes (src/index.ts).
awsmux AGENTS.md
Instructions for 0hardik1/awsmux, covering agents.md, what awsmux is, build, test, verify, layout and the safety model — invariants you must not weaken.
gcnv-mcp-server AGENTS.md
Instructions for NetApp/gcnv-mcp-server, covering assistant briefing, non-negotiable code policy, session startup — ontap audit logging (must do), userintent parameter (when audit logging is enabled) and operating principles.
EpesiCRM CLAUDE.md
Claude Code instructions for jtylek/EpesiCRM, covering claude.md, project, environment quirks (this machine), commands and architecture.
cron-mcp CLAUDE.md
Claude Code instructions for Shreyas-Profile/cron-mcp, covering deploying cron-mcp to hetzner + regiq.in, server (shared with the rest of the globalion mcp fleet), deploy a new version, first-time subdomain wiring (cron.regiq.in) and env vars.
devex AGENTS.md
Instructions for ParthKapoor-dev/devex: Summary Devex is a cloud development IDE with sandboxed “repl” sessions. The system is split into services. The core service handles auth and session orchestration, while the runner provides the interactive sandbox (WebSocket + PTY). Session data is persisted to S3-compatible…