Allows AI agents to manage Destiny 2 equipment, weapons, and builds through the Bungie API, including inventory transfer, weapon analysis, build recommendations, and activity history.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Destiny MCP show my highest stat roll for each armor slot on my hunter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
通过 AI 管理你的 Destiny 2 装备、武器和配装。
支持 Claude Code、Claude Desktop、Cursor 等任何 MCP 客户端。
# 1. 克隆项目
git clone <repo> && cd Destiny_MCP
# 2. 安装依赖 (需要 uv)
uv sync
# 3. 一键配置 (引导你完成所有设置)
uv run python scripts/setup.pysetup.py 会交互式引导你完成：
填入 Bungie API 凭证
完成 OAuth 授权
下载游戏数据库
完成后，在 Claude Code 中打开此项目即可使用。
Related MCP server: EVE ESI Tool
src/destiny_mcp/ MCP 后端和业务服务
webui/ 当前生产 React 前端和静态宿主
webui_new/ Hermes 兼容 API 后端和 legacy 回滚界面
tests/ MCP/服务聚焦测试
prompts/ 模型系统提示和截图提取提示
scripts/ 安装、检查、数据导入和运维脚本
deploy/ Docker/Nginx 检查与部署文件
docs/ 架构、运维、产品和参考文档
archive/ 不参与生产构建的历史原型/发布快照
data/ 本地 OAuth/会话运行数据（禁止删除，Git 忽略）
manifest/ 可重新下载的 Bungie Manifest（Git 忽略）完整说明见 仓库布局。
将多模态模型输出保存为 JSON，然后运行：
uv run python scripts/import_weapon_popularity.py /path/to/weapon.json导入器会严格校验结构、拒绝默认覆盖同名武器，在 data/backups/weapon-popularity/ 保留备份后原子更新内置数据。明确替换旧快照时使用 --replace。截图提取规则见 多模态提示词。
uv run python scripts/doctor.py检查所有配置是否就绪，包括 API 连通性测试。
如果一键脚本不适用，按以下步骤手动操作：
前往 Bungie 开发者门户 创建应用：
Redirect URL: https://localhost:8765/callback
Origin Header: *
Scope: 勾选 Read/Move/Equip
cp .env.example .env
# 编辑 .env 填入凭证uv run python scripts/oauth_setup.py浏览器会打开 Bungie 授权页面，授权后 token 自动保存到 ~/.destiny_mcp/tokens.json。
项目根目录的 .mcp.json 已为 Claude Code 配置好。
其他客户端参考 安装指南。
默认 DESTINY_MCP_TOOL_PROFILE=normal，只向模型暴露 8 个稳定的聚合入口：
工具 | 覆盖能力 |
| 玩家搜索、角色档案 |
| 背包、转移、批量装备、邮政官、锁定、任务追踪 |
| 武器分析、同名对比、perk 池、选取率、条件筛选 |
| 护甲配装推荐、诊断、确认后装备 |
| 本地配装和 Bungie 官方配装槽 |
| 子职业、碎片、神器 |
| 活动历史、PGCR、武器统计、排行榜 |
| 周常、商人、收藏品状态 |
expert 会增加常用只读工具，full 会暴露全部 76 个工具用于旧客户端兼容和调试。完整路由与确认规则见 工具文档。
浏览器提示「连接不安全」？ OAuth 回调用自签名证书，点「高级 → 继续前往」即可，仅本机使用无安全风险。
Token 过期了？
不会。tokens.json 含 refresh_token，启动时自动刷新。如改了 Bungie 密码需重新跑 OAuth。
首次启动很慢？ 首次会自动下载 Manifest (~50MB)，之后会缓存。
uv run pytest tests/ -v # 运行测试
uv run ruff check src/ tests/ # 代码检查
uv run ruff format src/ tests/ # 格式化架构文档见 docs/。
活动/战绩聚合入口：历史、PGCR、生涯统计、武器使用、排行榜。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| count | No | ||
| intent | No | history | |
| maxtop | No | ||
| statid | No | ||
| group_id | No | ||
| character | No | ||
| activity_id | No | ||
| player_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether it is read-only, requires authentication, or makes network calls. It only lists capabilities without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) but lacks structure. It is not front-loaded with key information and uses a comma-separated list, which is minimal but inadequate for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain parameter interactions, return values, or how to invoke different intents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and 9 parameters with no explanations. The description adds no meaning for parameters like 'intent', 'mode', or 'statid', leaving the agent to guess their roles based on names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's an entry for activity/performance data, listing history, PGCR, career stats, weapon usage, and leaderboards. It distinguishes from sibling tools by focusing on activities, but lacks a specific action verb like 'retrieve' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings. The description does not specify use cases or exclusions, leaving the agent to infer from the name and capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
配装聚合入口：推荐、查候选、失败诊断、确认后装备。
priority_stats 按从高到低严格排序；include_subclass_fragment=True 时使用目标角色当前已装备的子职业和碎片属性。
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| intent | No | recommend | |
| character | No | ||
| confirmed | No | ||
| exotic_name | No | ||
| player_name | No | ||
| class_target | No | ||
| melee_target | No | ||
| super_target | No | ||
| health_target | No | ||
| priority_stat | No | ||
| fragment_names | No | ||
| grenade_target | No | ||
| priority_stats | No | ||
| set_bonus_name | No | ||
| weapons_target | No | ||
| canonical_build | No | ||
| set_bonus_count | No | ||
| include_subclass_fragment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering behavior for 'priority_stats' and the conditional use of subclass fragment when 'include_subclass_fragment' is true. However, it does not address possible side effects, error conditions, or what 'fault diagnosis' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and includes key points. It is reasonably front-loaded with the overall purpose. However, the first sentence is somewhat vague ('配装聚合入口'), and more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, or the full workflow (e.g., what 'diagnosis' returns, how 'confirmed' equips, etc.). The tool is complex, yet the description covers only a fraction of the needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions are provided in the schema. The description explicitly explains only 'priority_stats' (strict ordering) and 'include_subclass_fragment' (uses current subclass/fragment). The remaining 17 parameters are undocumented in both schema and description, leaving the agent to infer their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a build aggregation entry covering recommendation, candidate checking, fault diagnosis, and equipping after confirmation. This clearly indicates the tool's domain and actions, distinguishing it from sibling assistants focused on other aspects (inventory, weapons, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for build-related tasks like recommending, checking candidates, and equipping. Sibling tools differ in domain (inventory, weapons, etc.), providing implicit context. However, no explicit when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
背包/仓库聚合入口：查物品、筛位置、移动/装备/锁定前统一确认。
| Name | Required | Description | Default |
|---|---|---|---|
| equip | No | ||
| limit | No | ||
| intent | No | summary | |
| locked | No | ||
| rarity | No | ||
| tracked | No | ||
| location | No | ||
| character | No | ||
| confirmed | No | ||
| item_name | No | ||
| item_type | No | ||
| type_name | No | ||
| armor_slot | No | ||
| destination | No | ||
| player_name | No | ||
| to_character | No | ||
| from_character | No | ||
| item_instance_id | No | ||
| item_instance_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the full burden. It mentions 'unified confirmation' but does not disclose behavioral traits such as what actions are destructive, authentication needs, or side effects of the many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence that front-loads the main purpose. However, it is in Chinese and could benefit from clearer structure or splitting into multiple points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (19 parameters, no schema descriptions, no output schema, broad capabilities), the description is severely incomplete. It fails to explain how to use parameters, what responses look like, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to any of the 19 parameters. The agent receives no help understanding what parameters like 'intent', 'confirmed', 'equip' do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's an inventory aggregation entry point with actions like check items, filter location, move/equip/lock. Distinguishes from sibling tools which are in different domains (activity, build, etc.), but the scope is broad and could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
配装槽聚合入口：本地/官方配装读取、保存、装备、官方槽位管理。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | all | |
| name | No | ||
| notes | No | ||
| query | No | ||
| intent | No | list | |
| character | No | ||
| confirmed | No | ||
| icon_hash | No | ||
| name_hash | No | ||
| color_hash | No | ||
| loadout_id | No | ||
| player_name | No | ||
| slot_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions saving and equipping, which imply write operations, but does not disclose behavioral traits such as destructive potential, authorization requirements, or side effects. This is minimal disclosure for a tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. It packs the essential purpose without unnecessary words. However, it borders on under-specification for the number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description is severely lacking. It does not explain what the tool does in sufficient detail, nor does it cover return values or usage context. The agent would struggle to invoke this tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and no parameter explanations are given in the description. With 13 parameters (all optional with defaults), the description must compensate, but it does not. Users have no guidance on how to use parameters like 'kind', 'intent', 'loadout_id', etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an aggregate entry for loadout slots, listing operations like reading, saving, equipping, and management. It distinguishes from sibling tools which cover different domains (e.g., activity, build, inventory). However, the term 'aggregate entry' is somewhat broad and could be more specific about the exact functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. Sibling tools cover distinct areas, so it is implied that this is for loadout-related operations, but there is no mention of prerequisites, exclusions, or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
玩家/账号聚合入口：搜索玩家、模糊找人、读取角色档案。
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | profile | |
| name_prefix | No | ||
| player_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist to indicate read-only or destructive nature. The description only lists functions but fails to disclose behavior like how the intent parameter routes operations, or any limitations or side effects. The tool is described as an 'aggregation entry' which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, using a single sentence to convey the core purpose. It is front-loaded with the main verb and resource. However, it could be more structured to list sub-functions clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters and no output schema or annotations, the description is insufficient to fully understand how to invoke it correctly. It omits critical details like the role of the intent parameter and how to perform each specific action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the purpose or usage of the three parameters (intent, name_prefix, player_name). There is no mapping from the listed functions to specific parameters, leaving the agent without essential semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for player/account operations, listing three specific actions (search, fuzzy find, read profiles). It distinguishes from siblings which focus on other aspects like activity or inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of sibling tools or when not to use it. The description does not address prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
子职业/碎片/神器聚合入口：读取配置、查选项、确认后修改。
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | get | |
| changes | No | ||
| element | No | ||
| character | No | ||
| component | No | ||
| confirmed | No | ||
| player_name | No | ||
| artifact_name | No | ||
| fragment_name | No | ||
| artifact_mod_hash | No | ||
| artifact_mod_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions modification but does not detail side effects, permissions, or steps. The description is insufficient for a tool that likely performs mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, front-loading the purpose. However, it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description is highly inadequate. It does not provide enough context for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. Parameter semantics are entirely missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is an entry point for subclasses, fragments, and artifacts, and mentions reading config, checking options, confirming, and modifying. However, it is somewhat vague ('aggregation entry') and does not clearly distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives like build_assistant or loadout_assistant. There is no explicit when/when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
武器聚合入口：分析、同名对比、perk 池、选取率、按 perk 筛选。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| intent | No | analyze | |
| location | No | ||
| any_perks | No | ||
| perk_name | No | ||
| player_name | No | ||
| weapon_name | No | ||
| weapon_type | No | ||
| excluded_perks | No | ||
| required_perks | No | ||
| item_instance_id | No | ||
| include_inventory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It doesn't mention whether the tool modifies data, is read-only, has rate limits, or any side effects. The term 'assistant' suggests querying but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is poorly structured – it lists capabilities without clear hierarchy or organization. While brevity is appreciated, it sacrifices clarity for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and zero annotations, the description is severely incomplete. It does not explain what the tool returns, how to specify intent, or how parameters interact. An AI agent cannot reliably use this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – no parameter descriptions exist in the schema. The tool description also fails to explain any of the 12 parameters (e.g., 'intent', 'location', 'any_perks'), leaving the AI agent without guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple vague functions ('analysis, same-name comparison, perk pool, selection rate, filter by perk') without a clear single action or resource. It's more a list of features than a concise purpose, and doesn't distinguish from sibling tools like 'build_assistant' or 'inventory_assistant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description implies it's a central entry but doesn't clarify context like when to use 'analyze' vs 'filter'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
世界/周常聚合入口：商人、周常、收藏品和进度查询。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| intent | No | weekly | |
| character | No | ||
| item_name | No | ||
| player_name | No | ||
| vendor_name | No | ||
| include_invisible | No | ||
| collectible_node_hash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only mentions it is an 'aggregation entry' for queries, implying read-only but not explicit. No details on destructive potential, authentication needs, or rate limits are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but insufficient given the complexity of 9 parameters. It front-loads purpose but omits necessary detail for effective usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero parameter descriptions, the description is severely incomplete. A tool with 9 parameters and no explanations is insufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 9 parameters. The agent has no information about what each parameter does, how to format values, or their constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is an aggregation entry for world/weekly content including merchants, weeklies, collectibles, and progress queries. It identifies the resource and purpose, but does not explicitly distinguish from sibling tools like activity_assistant or inventory_assistant, though the specific domains help narrow the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description lacks any context for appropriate usage, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0activity_assistantbuild_assistantinventory_assistantloadout_assistantplayer_assistantsubclass_assistantweapon_assistantworld_assistantScored across 8 tools
Each tool targets a distinct aspect of the Destiny game (activities, builds, inventory, loadouts, players, subclasses, weapons, world), with no overlapping purposes. The descriptions clearly differentiate their roles.
All tool names follow a consistent pattern of `[noun]_assistant`, making it easy to predict functionality from the name alone.
8 tools is an appropriate number for a Destiny game assistant, covering all major game systems without being overwhelming or sparse.
The tools cover all core player interactions: activities, character builds, inventory management, loadouts, player search, subclass modifications, weapon analysis, and world/weekly content. There are no obvious missing features for the domain.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
