Skip to main content
Glama
Sign In

MolTrust MCP Server

by io.github.MoltyCel
OverviewDiscussionsAdmin

ads_check

Allow / hold / forbid for one intended Amazon Ads MCP tool call, before it runs.

    Needs your MolTrust API key as the X-API-Key header of the MCP connection (free key:
    POST https://api.moltrust.ch/auth/signup). Counts against your plan like any check.
    Never send Amazon credentials: they are refused.

    Args:
        profile: the `profile` object from ads_mandate_template
        tool: the Amazon Ads MCP tool name, e.g. campaign_management-update_campaign_budget
        arguments: the tool arguments exactly as your agent would send them
        context: your view of the account — campaigns {id: {brand, daily_budget(cents)}},
                 targets {id: {brand, bid(cents)}}, ad_groups, account_daily_total(cents).
                 Values the check cannot derive count as unknown and end in forbid.

Input Schema

NameRequiredDescriptionDefault
toolYes
contextNo
profileYes
argumentsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so: auth requirement (X-API-Key header, free key signup URL), cost implication ('counts against your plan like any check'), and the critical fail-closed rule that values the check cannot derive count as unknown and end in forbid. It also states a refusal policy for Amazon credentials, which is exactly the kind of non-obvious context an agent needs.

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?

The decision semantics are front-loaded in the first sentence, and the Args block is terse and each line earns its place. The signup URL and the indented docstring layout add slight visual noise, but nothing is redundant prose.

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

Completeness5/5

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

An output schema exists, so return values need not be described. What an agent must know before calling is present: required inputs, auth mechanism, billing, credential refusal, and the fail-closed rule for under-specified context. Nothing material is missing for a pre-flight policy check.

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 coverage is 0% and the schema gives bare types only, yet the description documents all four parameters: profile (the object from ads_mandate_template), tool (with a concrete example name), arguments (exactly as the agent would send them), and context (with the expected shape and units — campaigns {id: {brand, daily_budget(cents)}}, account_daily_total(cents)). This fully compensates for the undocumented schema and explains the unknown→forbid consequence of incomplete context.

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 first line states a specific verb-and-object: adjudicating Allow/hold/forbid for one intended Amazon Ads MCP tool call before execution. It is clearly distinguishable from sibling ads_mandate_template (which produces the profile this tool consumes) and from unrelated moltrust_* checks. An agent can tell what this returns (a decision) and when it is invoked (pre-flight).

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?

Usage timing is explicit ('before it runs') and prerequisites are named: the MolTrust API key must ride as the X-API-Key header, obtainable via a signup POST. It does not explicitly state when NOT to use it or name a competing alternative beyond referencing ads_mandate_template for the profile, so it stops short of full routing guidance.

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 toolsInspect
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.

Resources