tres-settings-management
Manage Organization Settings and Platform Settings via the TRES MCP GraphQL API. Use when users ask about org settings, platform settings, configuration, feature flags, enable/disable platforms, balance diff, commit strategy, cost basis, ERP, pricing, sync boundaries, or any setting read/write operation. Trigger phrases include "get settings", "show settings", "update settings", "change settings", "enable platform", "disable platform", "balance diff", "commit strategy", "cost basis strategy", "set min sync date", "configure", "turn on", "turn off".
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-12
- Stars
- ★ 4.9k
- Forks
- 363
01 前言 Front Matter
- name
- tres-settings-management
- description
- Manage Organization Settings and Platform Settings via the TRES MCP GraphQL API. Use when users ask about org settings, platform settings, configuration, feature flags, enable/disable platforms, balance diff, commit strategy, cost basis, ERP, pricing, sync boundaries, or any setting read/write operation. Trigger phrases include "get settings", "show settings", "update settings", "change settings", "enable platform", "disable platform", "balance diff", "commit strategy", "cost basis strategy", "set min sync date", "configure", "turn on", "turn off".
03 SKILL.md 正文
TRES MCP - Organization & Platform Settings
How This Skill Works
This skill lets users view and modify configuration for their TRES Finance organization and individual blockchain/exchange platforms. There are two levels:
- Organization Settings — Apply to the entire org: how cost basis is calculated, which features are enabled, ERP behavior, pricing sources, commit scheduling, etc.
- Platform Settings — Apply per-platform (e.g., Ethereum, Arbitrum) and optionally per-wallet: commit strategy, sync date boundaries, balance diff, asset filtering, etc.
Ground Rules
1. Always Start by Identifying the Org
Before doing anything, confirm which organization the user is connected to:
query { admin { orgName } }
Tell the user: "You're connected to {orgName}."
2. Read Before Write
Before any mutation, ALWAYS fetch the current value of the setting(s) being changed. Show a clear before/after comparison.
3. Mutations Require Explicit Approval
Before executing ANY mutation, you MUST:
- Show a clear summary table with Setting, Current Value, and New Value
- Explicitly ask: "Shall I apply these changes to {orgName}?"
- Only proceed after the user confirms
- After execution, show the confirmed result from the mutation response
4. Warn About High-Risk Changes
Flag these settings as potentially dangerous and add a warning:
costBasisStrategy— Changing mid-period can cause recalculations across the entire orgdisableAutoCommit— Stops all automatic data processingskipCostBasis— Disables cost basis entirelycommitStrategy: SKIP_ALL— Fully disables a platform's data pipelineenableMultiEntity— Structural change, hard to reverseallowShort— Enables short positions in cost basis
5. Use Schema Introspection for Field Discovery
Do NOT rely on hardcoded field lists. Use the MCP introspect tool to discover available fields and their types dynamically:
introspect("OrganizationSettingsObjectType")— all readable org settingsintrospect("setOrganizationSettings")— all writable org settings with descriptionsintrospect("PlatformSettingsObjectType")— all readable platform settingsintrospect("setPlatformSettings")— all writable platform settings with descriptions
When a user asks "what can I configure?" or you need to verify a field name or enum values, introspect first.
Setting Categories (use when users ask vaguely)
If the user says "show me the settings" without specifics, offer these categories with plain-language explanations:
| Category | What It Controls |
|---|---|
| Cost Basis | How gains/losses are calculated (FIFO, LIFO, etc.), per-wallet vs org-wide, impairment |
| Commit Pipeline | Automatic data processing schedule, priority, stuck detection, sync hours |
| Internal Transfers | How transfers between the org's own wallets are detected and matched |
| Pricing | Where asset prices come from, stablecoin pegging, swap alignment |
| ERP Integration | How data syncs to accounting systems (NetSuite, Xero, QuickBooks) |
| Dashboard & Features | Which UI features are enabled (pivot tables, vesting, payments, multi-entity) |
| Staking | Staking rewards tracking and position management |
| Reconciliation | Cross-org and subsystem reconciliation behavior |
| Reports | Scheduled report timing, format, and content |
| Platform Collection | Which blockchains/exchanges are enabled, their sync boundaries and filters |
Reading Organization Settings
Query Structure
query {
admin {
orgName
organizationSettings {
# include only the fields relevant to the user's question
}
}
}
- Organization is resolved from the auth token — no org ID needed
- Never request all fields at once — pick the category relevant to the question
- Use
introspect("OrganizationSettingsObjectType")to discover available fields if needed
Nested Fields (must expand sub-fields when querying)
These fields return objects/lists, not scalars. Always include their sub-fields:
| Field | Sub-fields | What It Is |
|---|---|---|
peggedStableCoinsToFiat |
assetName, currency |
Stablecoins treated as equivalent to fiat |
pricingApiSourcePerAsset |
assetName, pricingApiSource |
Custom pricing source per asset |
netsuiteCurrencySymbolToInternalId |
currency, internalId |
NetSuite currency mapping |
simpleMatchingStrategies |
beforeRange, afterRange |
Reconciliation time windows |
proofOfFunds |
organizationName |
Proof of funds client config |
Additional Admin Fields
The admin query also provides:
orgName— the organization's display namedisabledPlatforms— quick list of platforms with collection fully disabledauth0Connections— available SSO login methods
Writing Organization Settings
Mutation Structure
Uses patch semantics — only include the fields you want to change. Everything else stays as-is.
mutation {
setOrganizationSettings(
costBasisStrategy: FIFO
) {
organizationSettings {
costBasisStrategy
}
}
}
Use introspect("setOrganizationSettings") to discover all mutable fields, their types, and descriptions.
Workflow for Changing Org Settings
- Read the current values of the setting(s) being changed
- Show the user a before/after comparison table
- Warn if any high-risk settings are involved
- Ask for approval
- Execute the mutation
- Confirm by showing the returned values
Reading Platform Settings
Query Structure (top-level query)
Returns only platforms/accounts with explicit overrides. Platforms using all defaults won't appear.
query {
platformSettings(platform: ETHEREUM) {
results {
settingsId
platform
internalAccountId
platformSettings {
commitStrategy
calculateBalanceDiff
minLastSyncedAt
maxToDate
# add fields as needed — use introspect("PlatformSettingsObjectType") for full list
}
}
}
}
Filtering Options
All arguments are optional — combine as needed:
| Argument | Type | Use Case |
|---|---|---|
platform |
Platform |
Show settings for a specific chain/exchange |
internalAccountId |
Int |
Show settings for a specific wallet |
settingsId |
String |
Exact match on storage key |
settingsId_Icontains |
String |
Partial match (e.g., "ethereum" matches "ethereum_714128") |
- No args → all stored platform settings
platformonly → platform-wide + all per-wallet overrides for that platformplatform+internalAccountId→ only the per-wallet overrideinternalAccountIdonly → all platforms for that wallet
Quick Check: Which Platforms Are Disabled?
query { admin { disabledPlatforms } }
Writing Platform Settings
Mutation Structure
Patch semantics — only included fields are merged. Existing values preserved.
mutation {
setPlatformSettings(
platform: ARBITRUM
internalAccountId: 714128 # omit for platform-wide
commitStrategy: FULL
minLastSyncedAt: "2025-01-01T00:00:00+00:00"
) {
settingsId
platformSettings {
commitStrategy
minLastSyncedAt
}
}
}
Use introspect("setPlatformSettings") to discover all available arguments.
Key Arguments
platform(required) — target blockchain or exchangeinternalAccountId(optional) — scope to a specific wallet. Omit for platform-wide- DateTime values must be ISO 8601 with timezone:
"2025-01-01T00:00:00+00:00"
Balance Rollup (Balance Diff)
To enable balance-diff-based activity tracking for specific assets:
mutation {
setPlatformSettings(
platform: ARBITRUM
internalAccountId: 714128
balanceRollupSettings: {
assetIdentifiers: ["native"]
interval: DAILY
}
) {
settingsId
platformSettings {
balanceRollupSettings { assetIdentifiers interval }
}
}
}
assetIdentifiers can be "native" for the chain's native asset, or contract addresses for tokens.
Enabling / Disabling Platforms
Use setPlatformCollectionStatus (not setPlatformSettings) for simple enable/disable.
mutation {
setPlatformCollectionStatus(
platformCollectionStatuses: [
{ platform: ARBITRUM, enabled: true }
{ platform: POLYGON, enabled: false }
]
) {
success
}
}
enabled: true→ platform will be collected in commits (FULL)enabled: false→ platform is fully skipped (SKIP_ALL)
Supports bulk operations — multiple platforms in one call.
Resolving Wallet Addresses to Internal Account IDs
When the user provides a wallet address, look up the internal account ID:
query {
internalAccount(identifier: "0x1887fa9edadeab7562b01cc3f4fa246ace2c3cdd") {
results {
id
name
identifier
parentPlatform
}
}
}
Use the returned id as internalAccountId in platform settings mutations.
Note: parentPlatform represents the top-level chain family (e.g., ethereum covers Ethereum, Arbitrum, Polygon, etc.). A single wallet address on ethereum parentPlatform can have platform-specific settings for each L2.
Common Workflows
"Change the cost basis method to LIFO"
- Query current:
admin { organizationSettings { costBasisStrategy } } - Show: "Current: FIFO → New: LIFO"
- Warn: "Changing the cost basis method will trigger recalculation. This affects all historical gain/loss calculations."
- Ask for approval
- Execute:
setOrganizationSettings(costBasisStrategy: LIFO)
"Enable Arbitrum"
- Query disabled:
admin { disabledPlatforms }— confirm ARBITRUM is in the list - Show: "ARBITRUM: Disabled → Enabled"
- Ask for approval
- Execute:
setPlatformCollectionStatus(platformCollectionStatuses: [{platform: ARBITRUM, enabled: true}])
"Set sync start date for wallet X on Polygon"
- Resolve wallet:
internalAccount(identifier: "0x...")→ getid - Read current:
platformSettings(platform: POLYGON, internalAccountId: {id})→ getminLastSyncedAt - Show: "Wallet {name} on POLYGON: minLastSyncedAt: 1970-01-01 → 2025-01-01"
- Ask for approval
- Execute:
setPlatformSettings(platform: POLYGON, internalAccountId: {id}, minLastSyncedAt: "2025-01-01T00:00:00+00:00")
"Add balance diff for native asset on a specific wallet"
- Resolve wallet:
internalAccount(identifier: "0x...")→ getid - Read current:
platformSettings(platform: ETHEREUM, internalAccountId: {id}) - Show: "Adding balance rollup for native asset (DAILY interval) on wallet {name} / ETHEREUM"
- Ask for approval
- Execute:
setPlatformSettings(platform: ETHEREUM, internalAccountId: {id}, balanceRollupSettings: {assetIdentifiers: ["native"], interval: DAILY})
"Show me which platforms are disabled"
- Execute:
admin { disabledPlatforms } - Present as a clean list grouped by chain family if many results
"What pricing source is configured?"
- Execute:
admin { organizationSettings { pricingApiSource peggedStableCoinsToFiat { assetName currency } pricingApiSourcePerAsset { assetName pricingApiSource } } } - Present: default source + any per-asset overrides + pegged stablecoins
Error Handling
| Error | Meaning | Resolution |
|---|---|---|
| 403 / Permission denied | User lacks admin:* permission |
Contact org admin to grant access |
Empty platformSettings results |
No custom overrides — platform uses defaults | This is normal; explain that defaults apply |
| "does not exist for organization" | Internal account ID not found in this org | Verify the wallet address and re-resolve |
| Invalid enum value | Wrong value for a setting | Use introspect on the enum type to show valid options |
| DateTime parse error | Wrong format | Must be ISO 8601 with timezone: "2025-01-01T00:00:00+00:00" |
04 同仓库更多 Skills
tres-wallets-upload
Upload and onboard multiple on-chain wallets or exchange accounts into Tres Finance. Use this skill whenever the user wants to add wallets, onboard wallets, import wallets, upload wallet addresses, ingest wallets, or connect exchanges into Tres — whether from a file (CSV/Excel) or by typing them manually. This skill guides Claude through the full flow: wallet type selection → input collection → validation → preview with editable HTML table → exchange credential collection (if exchange) → user confirmation → batch creation via the TRES MCP API. Always trigger this skill for wallet onboarding, wallet data ingestion, or any request to "add wallets to Tres".
tres-upload-tx-header-validation
The exact column header names required by the TRES Finance bulk transaction CSV upload. Use whenever building, fixing, or validating the header row of a TRES manual transaction or sub-transaction upload CSV — especially after an upload fails with "Missing required column(s): ...". Trigger phrases include: 'fix my CSV headers', 'bulk transaction upload failed', 'missing required columns', 'validate TRES upload CSV', 'transaction CSV template headers'. This skill is ONLY about the header naming convention; it does not cover row values or upload workflow. Do NOT trigger for contacts import CSV (use tres-import-contacts), wallet upload CSV (use tres-wallets-upload), or general CSV parsing unrelated to bulk TX upload headers.
tres-tx-story
Analyze a blockchain transaction by its hash using TRES Finance MCP and generate a visual flow diagram showing all asset movements, followed by a plain-language explanation of what happened. Use this skill whenever the user provides a transaction hash and asks to "analyze", "explain", "visualize", "diagram", "show me what happened in", or "tell the story of" a transaction. Also trigger when the user pastes a tx hash (long hex string starting with 0x) and asks anything about it. Always use this skill for transaction hash analysis — do not attempt to answer from memory alone.
tres-rollup-rules
Analyze an organization's sub-transaction patterns in TRES Finance, identify groups of repetitive transactions, and propose data-driven rollup rules that consolidate them into one aggregated entry per interval (daily or monthly) for cleaner ERP integration. Also lists and deletes rollup rules. Trigger this skill whenever the user asks about rollup rules, transaction aggregation, consolidating transactions, reducing transaction noise, rolling up gas fees, rolling up staking rewards, rolling up micro-transactions, or collapsing many small ledger entries into fewer summary entries. Also trigger on "create a rollup rule", "suggest rollup rules", "what should I roll up", "show my rollup rules", "delete a rollup rule", "aggregate transactions", "too many transactions", "reduce transaction count", "roll up fees", "daily rollup", "monthly rollup". If a wallet has too many transactions, high-frequency activity, or noisy ledger entries, proactively suggest rollup rules. For computing the EXACT impact of a single already-specified rule or reviewing submitted/pending rules, use the tres-rollup-review skill instead.
tres-rollup-review
Compute the EXACT sub-transaction impact of a rollup rule in TRES Finance — every filter applied — and flag genuine problems (zero matches, overlap, config mistakes) before the rule is created. Two modes. Mode A: a pre-create quality gate invoked by the tres-rollup-rules skill to vet proposed candidate rules. Mode B: standalone review of a rule someone submitted or of existing PENDING rules. Trigger this skill when the user says "review this rollup rule", "what would this rollup rule actually match", "preview the rollup impact", "how many transactions would this rule catch", "is this rollup rule valid", "validate my rollup rule", "check my pending rollup rules", or "review the rollup requests". Do NOT use this to design or propose new rollups — that is tres-rollup-rules. This skill only measures impact and flags issues; it never executes mutations.
tres-request-skill-update
Submit feedback about the TRES Claude plugin — bug reports, feature requests, skill improvements, new skill ideas, MCP issues, workflow friction, or positive feedback about what's working well. Use this skill whenever the user wants to share any kind of feedback about the plugin, its skills, or the TRES MCP. Trigger phrases include: "submit feedback", "report a bug", "request a feature", "suggest an improvement", "I have an idea", "something is broken", "the skill isn't working", "I love this skill", "this worked great", "the MCP is returning wrong data", "the flow is confusing", "can you fix the skill", "file a skill request", "give feedback", "this could be better". Also trigger proactively when the conversation appears to be wrapping up — e.g. the user says "thanks", "that's all", "looks good", "we're done", "nothing else", or any other signal that the task is complete. In that case, offer a brief feedback prompt instead of launching the full guided flow. Do NOT trigger for general questions about how a skill works — only when the user wants to submit feedback or the conversation is ending.