MolTrust MCP Server

ads_mandate_template

Build an ads profile and its AAE mandate for one or more Amazon Ads accounts.

    Pure: nothing is stored. Returns `profile` (pass it to ads_check) and `mandate`
    (what /enforce/check evaluates).

    Args:
        account_ids: advertiserAccountId / profileId values the agent may act on
        brands: brands the agent may touch
        daily_budget_cap_usd: largest daily campaign budget; above it: forbid
        hold_threshold_usd: above it a person named in `approvers` must approve
        total_daily_budget_cap_usd: sum of daily budgets on the account after a change
        period_budget_cap_usd: largest lifetime or monthly budget
        max_bid_usd: largest bid
        max_bid_change_percent: largest bid change per step, in percent
        valid_from: RFC 3339 UTC second
        valid_until: RFC 3339 UTC second; after it every call is forbidden
        tools: allowed tool names (default: all documented in ads_onboard)
        mandate_id: your identifier for this mandate
        principal_did: the agency's DID
        principal_public_key: the agency's Ed25519 public key, hex
        approvers: [{"did", "public_key", "role"}] who may approve a hold

Input Schema

Name	Required	Default
`tools`	No
`brands`	Yes
`approvers`	No
`mandate_id`	No	ads-mandate-1
`valid_from`	No	2026-10-01T00:00:00Z
`account_ids`	Yes
`max_bid_usd`	No
`valid_until`	No	2026-12-31T23:59:59Z
`principal_did`	No	did:moltrust:<your agency DID>
`hold_threshold_usd`	No
`daily_budget_cap_usd`	No
`principal_public_key`	No	<ed25519 public key, hex>
`period_budget_cap_usd`	No
`max_bid_change_percent`	No
`total_daily_budget_cap_usd`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose a key behavioral trait: 'Pure: nothing is stored.' It also explains enforcement consequences ('valid_until ... after it every call is forbidden'; budget caps mean 'forbid'; hold threshold requires a named approver). It does not cover failure modes or whether signing credentials are mandatory, keeping it below a 5.

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

Conciseness4/5

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

Purpose and purity lead, returns follow, and the parameter list closes — a sensible front-loaded order. The block is long, but with 0% schema coverage the Args enumeration is largely load-bearing rather than padding.

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?

For a 15-parameter tool with no annotations, the description covers purpose, side-effect profile, outputs, and every parameter, and an output schema exists so return-shape detail is not required. It stops short of describing authentication requirements (implied by principal_did/principal_public_key) or error behavior.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it documents every one of the 15 args with units and semantics the schema lacks (USD caps, percent for max_bid_change_percent, RFC 3339 UTC for validity dates, enforcement behavior for caps and hold thresholds). It adds genuine meaning rather than restating field names.

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 opening sentence names a specific verb and compound resource: 'Build an ads profile and its AAE mandate for one or more Amazon Ads accounts.' It also scopes the operation ('for one or more accounts') and distinguishes itself from siblings by naming ads_check and ads_onboard as the downstream/upstream counterparts.

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

Usage Guidelines4/5

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

The description establishes the workflow context clearly: the returned `profile` is 'pass[ed] to ads_check' and `mandate` is 'what /enforce/check evaluates', and the `tools` default references what is 'documented in ads_onboard'. It never states an explicit when-not-to-use or a hard exclusion, so it stops short of a 5.

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

All MolTrust MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.