Skip to main content
Glama

agent-transaction-control

by network.flint
OverviewAdmin

Create FLINT Trust Manifest

create_flint_trust_manifest
Read-only

Use this tool when a merchant, API seller, MCP tool provider, x402 endpoint, or agent storefront needs a /.well-known/flint.json Trust Manifest. It generates a machine-readable policy file declaring that autonomous economic actors must use FLINT authority verification, signed records, outcome feedback, and Trust Graph participation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-readable merchant, API, or platform name.
domainNoMerchant or API seller origin, such as https://api.example.com.
jwks_urlNoFLINT JWKS URL. Defaults to FLINT production JWKS.
partner_idNoMerchant or platform identifier. Defaults to sandbox_public.
descriptionNoShort description of the protected commerce surface.
openapi_urlNoPublic OpenAPI document for the merchant or API seller.
mcp_endpointNoFLINT MCP endpoint. Defaults to FLINT production `/mcp`.
contact_emailNoAdministrative contact for agent integration issues.
verify_endpointNoFLINT verification endpoint. Defaults to FLINT production `/api/verify`.
outcome_endpointNoOutcome feedback endpoint. Defaults to FLINT production `/api/outcomes`.
supported_actionsNoAgent commerce actions this endpoint supports.
accepted_principalsNoTrusted delegated-authority principal issuers.
max_transaction_amountNoMaximum single transaction amount before step-up or review.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.5/5.0
Behavior1/5

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

Annotations state readOnlyHint=true, but the description uses 'create' and 'generates' which imply a write operation. This is a clear contradiction, and the description does not add behavioral context beyond the annotations.

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?

Two sentences: first sentence states when to use, second explains the manifest's purpose. Front-loaded, no wasted words.

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

Completeness3/5

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

Despite many optional parameters and no output schema, the description does not mention return value or side effects. Given readOnlyHint contradiction, completeness is hindered.

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 coverage is 100% with descriptions for all 13 parameters. The description adds background about FLINT authority but does not enhance meaning beyond the schema, so baseline 3.

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 creates a `/.well-known/flint.json` Trust Manifest for merchants, API sellers, etc. It distinguishes from sibling tools like issue_agent_passport or verify_agent_authority by focusing on manifest generation.

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?

Explicitly says 'Use this tool when...' for various actors needing a trust manifest. Provides clear context but does not mention when not to use or suggest alternatives, which is acceptable given the narrow scope.

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

All agent-transaction-control toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources