Skip to main content
Glama
trustos-trustfolio

Trust OS MCP Server

Official
by trustos-trustfolio
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Trust OS MCP Server

Official MCP Server for AI decision verification with Trust OS.

What is Trust OS?

Trust OS is a Decision Verification Platform that helps organizations verify high-impact decisions before execution.

  • Decision verification

  • Risk evaluation

  • Policy enforcement

  • Auditability

  • Explainability

  • API-first integration

Related MCP server: io.github.yugantm/hvtracker-mcp

Features

  • MCP-compatible tool for any MCP client

  • verify_decision tool with structured input/output

  • Claude Desktop integration

  • Automatic risk assessment and cryptographic proof

Quick Start

git clone https://github.com/trustos-trustfolio/trustos-mcp-server.git
cd trustos-mcp-server
npm install
npm run build

Set your API key:

cp .env.example .env
# Edit .env and set TRUSTOS_API_KEY=your_api_key_here

Add to Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "trustos": {
      "command": "node",
      "args": ["C:/trustos-mcp-server/dist/index.js"],
      "env": {
        "TRUSTOS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Config file locations:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Tool Reference

verify_decision

Verify a high-impact decision before execution.

Field

Type

Required

Description

action

string

Yes

The action to verify

amount

number

No

Monetary amount

currency

string

No

Currency code (e.g. USDC)

destination

string

No

Destination identifier

source

string

No

Source system

priority

string

No

Priority level

metadata

object

No

Additional context

Example prompt:

Use Trust OS to verify this decision before execution:
action stablecoin_transfer, amount 50000, currency USDC, destination wallet_abc.

Example response:

Trust OS Decision Verification Result
════════════════════════════════════════
decision_id   : dec_a1b2c3d4
recommendation: APPROVE
risk_score    : 0.18
risk_level    : LOW
policy        : Stablecoin Settlement Policy v1.0
proof_hash    : SHA-256: 0xabc123...
verified      : true
latency_ms    : 142

Documentation

License

MIT

Available Tools

2 tools
create_decisionA

Create and verify a decision via the Trust OS Decision API. Returns decision_id, recommendation, risk assessment, proof_hash, and a trace_url for Dashboard inspection.

ParametersJSON Schema
NameRequiredDescriptionDefault
policyNoPolicy identifier to apply. Defaults to server policy.
approverNoEntity requesting the decision (e.g. treasury_bot, payment_service)
decisionYesDecision type to verify (e.g. stablecoin_transfer, payment_approval)
metadataNoContextual data: amount, currency, region, etc.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that the tool both creates and verifies, and returns several artifacts, but does not detail side effects, permissions needed, or what verification entails beyond returning data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that front-loads the action and outcome, listing key return values. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the schema fully documents parameters and the description enumerates meaningful return values, the tool is adequately described for an agent to select and invoke it. It lacks explicit guidance on prerequisites or failure modes but remains complete enough for straightforward usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the purpose of the tool (creating a decision) and example output fields, complementing the schema without needing to repeat parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Create and verify') and resource ('decision via the Trust OS Decision API'), and lists concrete outputs. It distinguishes clearly from the sibling 'verify_decision' by emphasizing creation and returning identifiers like decision_id and trace_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for creating a decision, but it does not explicitly state when to use it versus the sibling 'verify_decision'. It provides context about verifying via the API but lacks clear alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_decisionB

Verify a high-impact decision before execution using Trust OS.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesThe action or decision to verify (e.g. stablecoin_transfer)
amountNoMonetary amount involved
sourceNoSource address or identifier
currencyNoCurrency code (e.g. USDC, USD)
metadataNoAdditional context as key-value pairs
priorityNoPriority level (e.g. high, critical)
destinationNoDestination address or identifier

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'using Trust OS' but does not explain what verification entails, whether it is a read-only operation, whether it requires permissions, or what happens after verification (e.g., returns a result, blocks execution). This lack of transparency is a significant gap for a decision-related tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the core purpose. There is no redundancy or filler. It earns its place by communicating the essential action and context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters, one nested object, and no output schema or annotations. The description is far too minimal to cover the behavioral aspects, verification process, return values, or edge cases. It provides only a high-level purpose and leaves the agent guessing about how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all parameters have descriptions), so the baseline is 3. The description adds no extra meaning beyond the schema, but it does not need to since the schema already documents each parameter. The description does not clarify relationships between parameters or provide usage examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Verify a high-impact decision before execution.' The verb 'verify' is specific, and 'high-impact decision' identifies the resource. It also distinguishes from the sibling tool 'create_decision' by implying this tool is for verification, not creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before execution' implies when to use the tool, but there is no explicit mention of alternatives, exclusions, or when not to use it. The sibling tool 'create_decision' is not referenced, leaving room for ambiguity about the relation between creating and verifying decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation4/5

The two tools have distinct primary purposes—create_decision creates a new decision while verify_decision checks an existing one—but create_decision also includes verification, creating slight overlap. Descriptions are clear enough to guide correct selection in most cases.

Naming Consistency5/5

Both tools follow the consistent verb_noun pattern: create_decision and verify_decision. The naming is uniform, predictable, and easy to extend.

Tool Count3/5

With only two tools, the server feels thin for its domain, though the narrow scope may justify it. This is borderline and could benefit from additional tools to round out the functionality.

Completeness2/5

The server covers creation and verification but lacks essential operations like retrieving, listing, or updating decisions. This is a significant gap because agents cannot reference or manage existing decisions beyond their initial creation, making the surface incomplete for typical workflows.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/trustos-trustfolio/trustos-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server