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 skills/futuresearch/futuresearch-python/deploy-mcpnpx skills add futuresearch/futuresearch-python --skill deploy-mcpgit clone --depth 1 https://github.com/futuresearch/futuresearch-pythonWhat 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.00058 | $0.01409 |
| Opus 5 | $0.00029 | $0.00705 |
| Sonnet 5 | $0.00012 | $0.00282 |
| Haiku 4.5 | $0.00006 | $0.00141 |
Grade A, and why
deploy-mcp 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 2d 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 — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deploying the MCP Server
Deploying more than just the MCP server? Start from the
deploy-to-stagingskill (repo root.claude/skills/) — it routes a change through every layer of the stack in dependency order. This skill owns only the MCP layer.
Quick Deploy
Staging (from main)
gh workflow run "Deploy MCP Server" -f branch=main -f deploy_staging=true
Production (from main)
gh workflow run "Deploy MCP Server" -f branch=main -f deploy_production=true
Both environments
gh workflow run "Deploy MCP Server" -f branch=main -f deploy_staging=true -f deploy_production=true
From a feature branch
gh workflow run "Deploy MCP Server" -f branch=feat/my-branch -f deploy_staging=true
Monitoring a Deploy
# Watch the workflow run
gh run list --workflow="Deploy MCP Server" --limit 3
gh run watch <run-id>
# Check pod rollout
kubectl rollout status deploy/futuresearch-mcp-staging -n futuresearch-mcp-staging --timeout=5m
# Verify pods are running
kubectl get pods -n futuresearch-mcp-staging -o wide
How It Works
The GitHub Actions workflow (.github/workflows/deploy-mcp.yaml) does:
- Checks — ruff lint + pytest on the target branch
- Build & push — Docker image to GAR, tagged with short SHA (+
lateston main) - Deploy — Helm upgrade with layered values:
values.yaml— base configvalues.staging.yaml— staging overrides (MCP_SERVER_URL, REDIS_DB, replicaCount, host)values.secrets.staging.yaml— SOPS-decrypted secrets (Supabase, API keys)
The deploy uses --atomic so it auto-rolls back on failure.
Scaling Replicas
Via Helm values (persistent)
Edit futuresearch-mcp/deploy/chart/values.staging.yaml:
replicaCount: 2 # Change this
Commit, push, and redeploy.
Via kubectl (temporary, resets on next deploy)
# Staging
kubectl scale deploy futuresearch-mcp-staging -n futuresearch-mcp-staging --replicas=3
# Take offline
kubectl scale deploy futuresearch-mcp-staging -n futuresearch-mcp-staging --replicas=0
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.
- 2d ago First seen · 143 lines · 58 tokens per session scan A 36d444280669
deploy-mcp is a skill published in the GitHub repository futuresearch/futuresearch-python (54 stars, last pushed 5d ago), licensed MIT. It adds 58 tokens to every session and 1,409 once invoked, about $0.0003 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-30.
Other skills, from other repositories
agent-harness-fault-injection
Use when an agent workflow needs deterministic recovery evidence for sandbox, MCP/tool, worker, checkpoint, memory, or orchestration failures.
foundry-config-setup
Resolve missing setup caused by a hardcoded Foundry project endpoint or model in a sample. Use when a sample fails because it uses a placeholder/hardcoded projectendpoint (for example "https://your-project.services.ai.azure.com") or a hardcoded model instead of reading them from the environment.
azure-mgmt-apicenter-dotnet
Azure API Center SDK for .NET. Centralized API inventory management with governance, versioning, and discovery. Use for creating API services, workspaces, APIs, versions, definitions, environments, deployments, and metadata schemas. Triggers: "API Center", "ApiCenterService", "ApiCenterWorkspace", "ApiCenterApi", "API…
azure-mgmt-botservice-dotnet
Azure Resource Manager SDK for Bot Service in .NET. Management plane operations for creating and managing Azure Bot resources, channels (Teams, DirectLine, Slack), and connection settings. Triggers: "Bot Service", "BotResource", "Azure Bot", "DirectLine channel", "Teams channel", "bot management .NET", "create bot".
azure-communication-chat-java
Build real-time chat applications with Azure Communication Services Chat Java SDK. Use when implementing chat threads, messaging, participants, read receipts, typing notifications, or real-time chat features.
bf-to-agents-sdk-dotnet-migration
Use when migrating a Bot Framework .NET SDK bot to Microsoft 365 Agents SDK. Triggered by projects that depend on packages: Microsoft.Bot.Builder or Microsoft.Bot.Builder.Integration.AspNet.Core that want to migrate to Agents SDK.