Synpareia Trust Toolkitofficial
A
licenseA
qualityA
maintenanceVerifiable dealings with other agents: prove what you did, vet who you deal with, bind agreements
36
Apache 2.0
agent-transaction-control
Server Details
Issue Agent Passports and verify agent authority before value moves. Signed verification records.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- thefraudfather/flint-plugin
- GitHub Stars
- 0
- Server Listing
- FLINT Agent Passport
Available Tools
10 toolscreate_flint_trust_manifestCreate FLINT Trust ManifestARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Human-readable merchant, API, or platform name. | |
| domain | No | Merchant or API seller origin, such as https://api.example.com. | |
| jwks_url | No | FLINT JWKS URL. Defaults to FLINT production JWKS. | |
| partner_id | No | Merchant or platform identifier. Defaults to sandbox_public. | |
| description | No | Short description of the protected commerce surface. | |
| openapi_url | No | Public OpenAPI document for the merchant or API seller. | |
| mcp_endpoint | No | FLINT MCP endpoint. Defaults to FLINT production `/mcp`. | |
| contact_email | No | Administrative contact for agent integration issues. | |
| verify_endpoint | No | FLINT verification endpoint. Defaults to FLINT production `/api/verify`. | |
| outcome_endpoint | No | Outcome feedback endpoint. Defaults to FLINT production `/api/outcomes`. | |
| supported_actions | No | Agent commerce actions this endpoint supports. | |
| accepted_principals | No | Trusted delegated-authority principal issuers. | |
| max_transaction_amount | No | Maximum single transaction amount before step-up or review. |
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.
generate_authorization_scopeGenerate Authorization ScopeARead-onlyInspect
Use this tool when an agent commerce workflow needs a well-formed delegated authorization scope before issuing a signed verification record. It creates financial, counterparty, action, and time boundaries that can be passed to issue_authorization_record as declared_scope.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Asset or unit, such as USD, USDC, or credits. Defaults to USD. | |
| purpose | No | Business purpose or task label for the delegated authority. | |
| principal_id | No | Accountable principal granting delegated authority. | |
| allowed_actions | No | Permitted actions, such as checkout, paid_api_access, x402_request, or stablecoin_transfer. | |
| time_window_end | Yes | ISO-8601 timestamp for scope expiration. | |
| max_amount_per_tx | Yes | Maximum amount allowed per transaction. | |
| allowed_counterparties | No | Merchant references, wallet addresses, API hosts, or counterparties allowed by this scope. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so no contradiction. Description adds that it 'creates boundaries' but does not elaborate on side effects or idempotency beyond what annotations imply.
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, front-loaded with usage context, no redundant words. Efficient.
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 tool with 7 parameters and no output schema, the description adequately explains when and why to use it and how it relates to issue_authorization_record, though it could briefly note the return value.
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%, so all parameters are described in schema. The description mentions categories (financial, counterparty, action, time boundaries) that loosely map to parameters but adds no new semantics beyond schema.
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 verb 'generate' and resource 'authorization scope', specifies when to use (agent commerce workflow before issuing a signed verification record), and distinguishes it from siblings by mentioning it produces input for issue_authorization_record.
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 states when to use ('before issuing a signed verification record') and identifies the sibling tool that consumes the output, but does not provide when-not-to-use or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_passportGet Agent PassportARead-onlyInspect
Use this tool to resolve a public FLINT Agent Passport by passport_id. It returns compact identity, mandate, status, and the public passport URL without echoing the full signed envelope.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| passport_id | Yes | FLINT Agent Passport id, beginning with kya_. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds value by specifying the returned data (compact identity, mandate, status, URL) without echoing the full envelope, which goes beyond 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?
The description is a single, well-structured sentence with no wasted words. It efficiently conveys purpose, input, and output characteristics.
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?
Given no output schema, the description adequately explains what is returned (identity, mandate, status, URL). For a simple read-only lookup with clear annotations, this is fully sufficient.
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 one parameter that has a pattern and description. The description does not add additional semantic meaning to the parameter beyond what is in the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'resolve' and the resource 'FLINT Agent Passport by passport_id'. It distinguishes from siblings by implying a read-only lookup, though it does not explicitly contrast with issue or update tools.
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 indicates when to use (to resolve a passport by ID), but lacks guidance on when not to use or alternatives among sibling tools like issue_agent_passport or update_agent_mandate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
issue_agent_passportIssue Agent PassportAInspect
Use this tool to issue a free FLINT Agent Passport: a hybrid-signed, verifiable identity credential for an autonomous agent. The zero-config mint path only needs agent.agent_name or agent.agent_id. Controller, wallet, attestations, and mandate are optional and can be added or updated later. The passport signs identity only; the spending mandate is separate, mutable config that can be updated later without reissuing the passport. Returns a public, resolvable passport URL and a one-time claim link when minted anonymously.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, wallet_address, and attestations. | |
| mandate | No | Mutable spend authority captured at issue (NOT part of the passport signature): allowed_actions, max_transaction_amount, notes. Update later without reissuing the passport. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, openWorldHint=true) indicate a non-idempotent write. The description adds transparency: it specifies that the passport signs identity only, the mandate is separate and mutable, and returns a public URL and one-time claim link when minted anonymously. No contradictions with 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?
The description is concise yet complete, with each sentence adding value: purpose, minimal requirements, optional fields, behavior, and return values. It is front-loaded with the core action, and no information is redundant.
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 complexity (2 params, no output schema), the description provides adequate context: return values (URL, claim link), the nature of the credential, and the mutable mandate. However, it does not mention any prerequisites or side effects beyond what annotations imply, leaving minor gaps.
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 100%, and the description adds significant meaning beyond the schema. For the 'agent' parameter, it explains required vs optional fields. For 'mandate', it clarifies it is mutable and not part of the passport signature, providing actionable semantic context for the agent.
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: 'issue a free FLINT Agent Passport: a hybrid-signed, verifiable identity credential for an autonomous agent.' It uses a specific verb (issue) and resource (Agent Passport), differentiating from sibling tools like get_agent_passport (read) and update_agent_mandate (update).
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 provides guidance on minimal requirements: 'The zero-config mint path only needs agent.agent_name or agent.agent_id.' It also clarifies optional fields and that mandate can be updated later, distinguishing it from update_agent_mandate. However, it lacks an explicit 'when not to use' statement for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
issue_authorization_recordIssue Signed Verification RecordAInspect
Use this tool before an AI agent initiates a payment, paid API call, checkout action, stablecoin transfer, x402 request, or delegated commercial transaction. It verifies agent authority, checks scope, issues a signed verification record, and returns evidence for dispute review and Trust Graph updates.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | No | Replay-protection nonce. Generated automatically if omitted. | |
| timestamp | No | ISO timestamp. Generated automatically if omitted. | |
| partner_id | No | Merchant or platform identifier. Defaults to sandbox_public. | |
| agent_claim | No | Agent identity, principal hint, runtime hint, optional act_chain delegation lineage, optional spiffe_svid workload identity, optional tool_manifest capabilities, and related claims. | |
| transaction | Yes | Intended transaction or paid access request. Must include amount_display. | |
| declared_scope | No | Financial, temporal, and counterparty limits for delegated authority. | |
| merchant_reference | No | Merchant order, invoice, or API request reference. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the multi-step process: verifying authority, checking scope, issuing a record, and returning evidence for dispute review and Trust Graph updates. It does not contradict any annotation.
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 two sentences, front-loaded with usage context, and every phrase adds value with no redundancy.
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?
The tool has 7 parameters and nested objects, but no output schema. The description explains actions but omits the return structure (e.g., what the signed record contains), leaving a gap for a complex tool.
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?
With 100% schema coverage, the baseline is 3. The description references agent_claim and declared_scope in context but adds little specific meaning beyond the schema's already descriptive property descriptions.
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 explicitly states the tool issues a signed verification record and lists specific use cases (payment, paid API call, checkout, etc.), differentiating it from siblings like verify_agent_authority by emphasizing issuance over mere verification.
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 clearly directs when to use the tool (before initiating commercial actions), providing strong context. However, it lacks explicit when-not-to-use guidance or alternative tool references beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_agent_reputationLookup Agent ReputationARead-onlyInspect
Use this tool to query the FLINT Trust Graph for a partner-scoped agent's historical reputation before permitting a payment, paid API call, checkout action, x402 request, or delegated commercial transaction. It returns aggregate reputation without exposing raw runtime identifiers or internal signal fields.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flint_agent_id | Yes | Partner-scoped FLINT agent identifier. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by stating that it returns 'aggregate reputation without exposing raw runtime identifiers or internal signal fields,' which clarifies data privacy behavior beyond the annotations. No contradictions.
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 with no wasted words. The purpose and usage are front-loaded. Every sentence earns its place.
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 one parameter and no output schema, the description adequately covers what the tool does and what it returns (aggregate reputation without raw identifiers). A minor gap is the lack of detail on the return structure, but it's sufficient for an agent to understand the tool's role.
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?
The input schema provides full coverage (pattern and description for flint_agent_id). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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: to query historical reputation from the FLINT Trust Graph. It specifies the verb 'query' and resource 'reputation', and lists specific use cases (payment, paid API call, etc.), making it distinct from sibling tools like create_flint_trust_manifest or get_agent_passport.
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 provides explicit when-to-use scenarios (before permitting various commercial actions). However, it does not mention when not to use or alternative tools, leaving the agent to infer from sibling names. Clear context but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_flint_scoutFLINT Scout: Pre-Transaction Fraud PreventionADestructiveInspect
Use this tool to scan an intended agent transaction before execution. The first call returns a $0.01 x402 payment challenge without running the scan. A wallet-enabled client signs that challenge and retries with payment_signature. After settlement, FLINT returns a signed authority decision. When receipt issuance succeeds, it also returns a separately signed settlement receipt and durable receipt URL; otherwise it reports receipt unavailability without inviting a paid retry. Payment to FLINT is distinct from the transaction being scanned and is not proof of agent authority.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | No | Replay-protection nonce. Generated automatically if omitted. | |
| timestamp | No | ISO-8601 request timestamp. Generated automatically if omitted. | |
| agent_claim | No | Optional bounded agent hints. Self-asserted values do not establish authority. | |
| passport_id | No | Optional FLINT Agent Passport. Verified payer-wallet and mandate bindings may strengthen the decision. | |
| transaction | Yes | ||
| payment_signature | No | Opaque caller-signed x402 PAYMENT-SIGNATURE value from a wallet-enabled client. Never provide a private key or seed phrase. | |
| merchant_reference | No | Optional merchant reference. Must match transaction.reference when both are supplied. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses crucial behavioral details beyond the annotations: the first call does not run the scan and only returns a $0.01 challenge; after settlement a signed authority decision is returned; receipt issuance success/failure is handled distinctly without inviting a paid retry; and payment is explicitly noted as distinct from the scanned transaction and not proof of authority. This is rich, actionable transparency that the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) do not convey.
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 well-structured and front-loaded: it states the core purpose immediately, then walks through the two-phase flow in chronological order. Every sentence earns its place—no filler, no repetition. It is concise yet comprehensive, covering the challenge, retry, settlement, receipt handling, and a key caveat.
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?
Given the tool's complexity (a two-step payment challenge flow), the description covers all essential aspects an agent needs: the initial challenge response, the retry with payment_signature, the signed decision, receipt outcomes, and the distinction between payment and authority. No output schema exists, but the description appropriately describes the response types and error handling. It's complete for correct invocation.
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 86%, so most parameters already have clear descriptions (e.g., nonce, timestamp, payment_signature, transaction). The tool description adds workflow context tying payment_signature to the retry step, but it does not provide additional parameter-level meaning beyond the schema. This aligns with the baseline for high schema coverage; the description could compensate more, but it doesn't hurt.
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 opens with a clear verb-resource pairing: 'scan an intended agent transaction before execution.' It names the specific purpose (fraud prevention) and distinguishes this tool from all siblings, which focus on passports, mandates, and other governance tasks. The two-step challenge workflow further clarifies what the tool actually does.
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 explicitly states when to use the tool ('before execution') and explains the required workflow: first call returns a payment challenge, then retry with payment_signature after signing. It does not explicitly mention alternatives or when not to use, but the sibling tools are clearly different in function, and the context is unambiguous. It could be improved by referencing a sibling for other scans, but it's solid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_agent_mandateUpdate Agent MandateAIdempotentInspect
Use this tool to update mutable mandate config for an existing FLINT Agent Passport. This updates allowed actions, amount limits, or notes only. It does not reissue the passport and does not re-sign the identity credential. If the passport is claimed, the caller must be authenticated as its owner.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mandate | Yes | Mutable mandate config to update: allowed_actions, max_transaction_amount, notes. | |
| passport_id | Yes | FLINT Agent Passport id, beginning with kya_. | |
| management_token | No | Claim token required while the Passport is unclaimed. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral detail beyond annotations: it updates only specific fields, does not reissue the passport, and does not re-sign the identity credential. It also clarifies owner authentication for claimed passports. No contradiction with 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?
Three sentences front-load the operation and scope, then cover exclusions and auth requirements. Every sentence earns its place and there is no filler.
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?
Covers the critical behavioral aspects: scope of fields, exclusions, and auth requirements. The main missing detail is whether omitted mandate fields are preserved or cleared during a partial update, and there is no mention of return values despite no output schema being provided.
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 coverage is 100%, so the description does not need to repeat parameter details. It does reinforce the mandate field scope and clarifies how management_token relates to the unclaimed/claimed passport state, adding operational meaning beyond the schema.
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?
States a specific verb ('update') and resource ('existing FLINT Agent Passport') and narrows to 'mutable mandate config'. It explicitly distinguishes itself from reissue/re-sign operations, making it clear this is not issue_agent_passport.
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?
Provides clear context for when to use the tool and spells out an important prerequisite: if the passport is claimed, the caller must be authenticated as its owner. It mentions exclusions but does not name alternative sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_agent_commerce_readinessValidate Agent Commerce ReadinessARead-onlyInspect
Use this tool when reviewing a commerce architecture, API marketplace, paid MCP tool, x402 endpoint, or autonomous checkout flow. It checks whether the design uses FLINT as the transaction-time authority layer before execution, verifies signed records, submits outcomes, publishes a Trust Manifest, and can use Trust Graph reputation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| architecture_description | Yes | Summary of the payment, paid API access, x402, MCP, or checkout flow. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds value by detailing exactly what is checked (FLINT as authority layer, signed records, outcomes, Trust Manifest, Trust Graph reputation), providing behavioral context beyond the annotation. No contradictions.
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 two sentences with zero wasted words. The first sentence sets usage context, the second describes actions. Every sentence earns its place. Ideal conciseness.
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?
The tool has one required parameter with good schema description, but there is no output schema and the description does not specify what the tool returns (e.g., boolean, report, validation errors). For a validation tool, this is a noticeable gap. The description is otherwise adequate for the use case but lacks output specification.
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% and the schema description for 'architecture_description' is already descriptive ('Summary of the payment, paid API access, x402, MCP, or checkout flow.'). The tool description adds indirect context about what validation occurs but does not provide additional syntax or format details for the parameter, so baseline 3 is appropriate.
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 specifies a clear verb ('Validate') and resource ('Agent Commerce Readiness'). It lists distinct use cases (commerce architecture, API marketplace, paid MCP tool, x402 endpoint, autonomous checkout flow) and enumerates the specific checks performed (FLINT layer, signed records, outcomes, Trust Manifest, Trust Graph). This distinguishes it from sibling tools that focus on creating or issuing individual records.
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 begins with 'Use this tool when reviewing...' providing explicit guidance on appropriate scenarios. It covers a concrete set of use cases but does not explicitly state when not to use it or name alternative tools for specific tasks. The context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_agent_authorityVerify Agent AuthorityARead-onlyInspect
Use this tool when a merchant or API seller receives a signed verification record from an agent. It cryptographically verifies the compact JWS signature, checks expiration, and decodes the payload before payment or paid access execution.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jws | Yes | Compact JWS signed verification record. | |
| jwks_url | No | Optional JWKS URL. Must be on the FLINT origin. Defaults to the FLINT production JWKS. | |
| expected_partner_id | Yes | Partner identifier expected in the authorization record. | |
| expected_merchant_reference | Yes | Current transaction or resource reference expected in the authorization record. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds concrete behavioral detail: compact JWS signature verification, expiration checking, and payload decoding. It does not describe return values or error behavior, but it adds meaningful operational 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?
A single sentence front-loads the usage trigger and then lists the core verification steps without filler. Every clause contributes useful information.
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?
The tool is read-only, has fully documented parameters, and the description supplies the business context and operational steps. The main gap is the absence of an output schema and no explicit statement of what the tool returns on success or failure, but enough is provided for an agent to understand the tool's role.
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%, so the schema already documents all parameters. The description reinforces the purpose of expected_partner_id and expected_merchant_reference by referring to the decoded payload, but adds no new format or usage details beyond the schema.
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 names a specific verb ('verifies') and resource ('signed verification record from an agent'), and defines the trigger context: before payment or paid access execution. This clearly distinguishes the tool from issuer-oriented siblings like issue_authorization_record.
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?
It explicitly states when to use the tool ('when a merchant or API seller receives a signed verification record from an agent' and 'before payment or paid access execution'). It does not name exclusions or alternative tools, but the context is clear enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
- Removed
submit_transaction_outcome - Changed
update_agent_mandate1 field changed- added
Input schema / properties / management_tokenAdded value: +{ + "description": "Claim token required while the Passport is unclaimed.", + "maxLength": 128, + "minLength": 32, + "type": "string" +}
- Changed
verify_agent_authority3 fields changed- added
Input schema / properties / expected_merchant_referenceAdded value: +{ + "description": "Current transaction or resource reference expected in the authorization record.", + "maxLength": 256, + "minLength": 1, + "type": "string" +} - added
Input schema / properties / expected_partner_idAdded value: +{ + "description": "Partner identifier expected in the authorization record.", + "maxLength": 128, + "minLength": 1, + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "jws" -]New value: +[ + "jws", + "expected_partner_id", + "expected_merchant_reference" +]
1 tool update
- Added
run_flint_scout
1 tool update
- Changed
verify_agent_authority1 field changed- changed
Input schema / properties / jwks_url / descriptionPrevious value: -"Optional JWKS URL. Defaults to the FLINT production JWKS."New value: +"Optional JWKS URL. Must be on the FLINT origin. Defaults to the FLINT production JWKS."
3 tool updates
- Added
get_agent_passport - Changed
issue_agent_passport1 field changed- changed
Input schema / properties / agent / descriptionPrevious value: -"Agent identity: agent_id, agent_name, controller_id, controller_type (user or organization), wallet_address, and optional attestations."New value: +"Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, wallet_address, and attestations."
- Added
update_agent_mandate
8 tool updates
- First observed
create_flint_trust_manifest - First observed
generate_authorization_scope - First observed
issue_agent_passport - First observed
issue_authorization_record - First observed
lookup_agent_reputation - First observed
submit_transaction_outcome - First observed
validate_agent_commerce_readiness - First observed
verify_agent_authority
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Signed agent discovery, security attestations, paid work, and verified settlement reputation.
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
Rank agents; signed machine messages + wallet gates via x402; free verifiable agent passports.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAgent network intelligence for trust verification, broker discovery, and capability matching. Ed25519 identity, graph-based trust scoring, USDC payments, and MCP tools for agent registration, search, and trust attestation.1,4985MIT
- MIT
- AlicenseAqualityBmaintenanceAI agent identity and reputation registry. Ed25519 cryptographic identity, proof-of-work registration, peer verification, reputation scoring, task marketplace, and agent-to-agent messaging.1614Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.2/5.0
Disambiguation5/5
Each tool targets a distinct action and resource: manifest creation, scope generation, passport lifecycle, authorization issuance/verification, reputation lookup, transaction scanning, and architecture validation. Overlapping terms like 'issue_agent_passport' and 'issue_authorization_record' are clearly differentiated by their objects and descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern with clear verbs (create, generate, get, issue, lookup, run, update, validate, verify). Even where verbs are semantically close (issue vs generate), the pattern remains uniform and predictable.
Tool Count5/5
Ten tools is well-scoped for an agent transaction control domain, covering identity, authorization, verification, trust, scanning, and compliance checks without redundancy. Each tool occupies a necessary niche in the workflow.
Completeness4/5
Core lifecycle coverage is strong: passports can be created, read, and updated, authorizations can be scoped, issued, and verified, and reputation/manifests are accessible. Notable minor gaps include no explicit revocation or outcome-submission tool, but agents can still complete the primary transaction flow.