Pay-per-call US brand evidence and signal workflows with free MCP discovery and x402 payments.
Average 4.2/5 across 21 of 21 tools scored.
Many tools have overlapping purposes, e.g., us-brand-signal-metrics-aggregator, us-brand-signal-cross-tabulator, and us-brand-signal-brand-summary all produce counts or summaries of the same type of data. The descriptions are detailed, but the boundaries between analyzers, summarizers, and aggregators are unclear enough that an agent may struggle to pick the right one.
Most tools follow a consistent 'us-brand-' prefix with descriptive nouns separated by hyphens (e.g., us-brand-signal-batch-splitter, us-brand-evidence-chronology-builder). The exception is 'pricing_info', which uses an underscore and lacks the prefix, creating a minor inconsistency.
At 21 tools, the set is on the heavier side but still manageable for a complex domain like brand intelligence. Many tools are variations on deterministic signal processing, which could be streamlined, but the count itself is not extreme.
The tool set covers a broad pipeline for processing buyer-supplied signals and evidence, including splitting, summarizing, routing, and building payloads. However, it lacks any tools for ingesting or fetching data from external sources (except one federal award snapshot), and there is no end-to-end controller that orchestrates the workflow. This leaves notable gaps for a complete 'brand intelligence' lifecycle.
pricing_infoPricing — US Brand IntelligenceAFree — list every paid tool in the 'us-brand-intelligence' bundle with its price, payTo address and network. Call this first if you don't have a wallet ready yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that the call is 'Free' and advises calling first when no wallet is ready, adding context beyond annotations. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences. The first is front-loaded with 'Free — list...' followed by specifics; the second adds usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema, read-only), the description sufficiently explains what the tool does and when to call it. It mentions the key output fields (price, payTo, network).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema is empty. Description doesn't need to explain params; baseline is 4. It clearly implies there are no inputs needed by saying 'list every...' without conditions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and specific resource 'every paid tool in the us-brand-intelligence bundle' with details on price, payTo address, and network. It distinguishes this tool from all sibling tools, which focus on signals and evidence, not pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to 'Call this first if you don't have a wallet ready yet', indicating a clear use case. It doesn't explicitly name alternative tools, but the context implies when to use it preferentially.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-action-queueUS Brand Action QueueATurn verified US brand signals into one deterministic prioritized action queue with evidence, urgency, ownership status, and rule traces for downstream operators and agents. The Actor does not send messages or write to destinations. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Choose this or datasetId, never both; the runtime enforces XOR because the Apify schema dialect cannot express cross-property relations. | |
| options | No | Deterministic caps and optional explanation mode. | |
| scoredAt | Yes | Explicit UTC timestamp bound into request identity and used by all time-based scoring rules. | 2026-08-05T00:00:00Z |
| datasetId | No | Choose this or items, never both; the runtime enforces XOR because the Apify schema dialect cannot express cross-property relations. | |
| requestId | No | Bounded correlation value only; it does not deduplicate separate Actor runs. | |
| schemaVersion | Yes | Closed contract version. | 1.0 |
| openrouterApiKey | No | Optional caller-supplied value for one bounded explanation only; runtime enforces the BYOK conditional because the Apify schema dialect cannot express it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive, and the description adds that the Actor 'does not send messages or write to destinations,' reinforcing no side effects. It also adds determinism, inclusion of urgency/ownership/rule traces, and cost ($0.05/call) beyond annotation coverage, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a cost note; every sentence carries useful information: the core transformation, the no-side-effect boundary, and the pricing/currency. It is front-loaded with the main verb and resource, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested objects, XOR input constraints, and no output schema, yet the description gives only a high-level output summary without detailing the queue structure, prioritization criteria, or return format. While the input schema's `items` prefill hints at the shape, an agent selecting this tool would benefit from more explicit output details, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions evidence, urgency, ownership status, and rule traces, which map to nested fields in the `items` parameter, but it does not add syntax, format, or precedence details beyond the schema's own per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Turn verified US brand signals into one deterministic prioritized action queue' with an explicit resource and output artifact. It clearly distinguishes from sibling tools focused on signals, evidence, or chronology by naming the action-queue output and its contents (evidence, urgency, ownership status, rule traces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is for 'downstream operators and agents' and explicitly excludes sending messages/writing to destinations, giving a clear boundary. It does not explicitly name alternative tools, but the context and exclusion provide practical guidance on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-evidence-chronology-builderUS Brand Evidence Chronology BuilderABuild a deterministic chronology from 1 to 30 closed US brand evidence rows and an explicit UTC as-of time. It sorts supplied facts, marks same-time groups, reports future-dated IDs, and emits stable counts and digests. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| asOf | Yes | Explicit UTC timestamp; the runtime never reads the current clock. | |
| rows | Yes | One to 30 closed rows. Input order is not semantic. | |
| schemaVersion | Yes | Required closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: deterministic processing, same-time grouping, future-dated ID reporting, stable counts/digests, and explicit UTC as-of usage. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the core purpose, enumerate key behaviors, and include pricing. Every phrase carries meaning—no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested row objects and no output schema, the description covers the main behavioral contract (sorting, grouping, future-id reporting, digests) and the central time constraint. It is somewhat vague on the exact output structure, but combined with the extensive schema descriptions, it is adequate for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (schemaVersion, asOf, rows) is well-described in the schema, including details like 'Explicit UTC timestamp; the runtime never reads the current clock' and 'Input order is not semantic.' The tool description reinforces but does not add per-parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and a clear resource ('deterministic chronology'), with explicit input constraints ('1 to 30 closed US brand evidence rows and an explicit UTC as-of time'). It distinguishes itself from sibling tools by naming concrete operations: sorting, same-time grouping, future-dated ID reporting, and stable counts/digests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a deterministic chronology from US brand evidence) but provides no explicit alternatives or exclusions. It does not name sibling tools or state when not to use this tool, so it only reaches the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-evidence-citation-tableUS Brand Evidence Citation TableATurn a small buyer-owned evidence packet into a stable citation table with bounded Markdown citations, host and source counts, limitations, and digests. It formats the supplied facts and does not browse, fetch, verify, rank, or enrich them. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 rows with unique opaque evidence IDs. All text is bounded; timestamps are strict UTC; source URLs must be HTTPS without credentials or fragments. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false), the description adds valuable behavioral context: it explicitly confirms no browsing/fetching/verification, mentions the output is a 'stable' table, and discloses the cost and payment method ($0.05/call, x402 USDC on base). This enriches the annotation information without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a pricing tag, front-loaded with the core action and output. Every clause adds meaningful information: the action, the output components, the explicit non-actions, and the cost. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (arrays with multiple fields, no output schema), the description is complete: it explains what the output contains (counts, limitations, digests), what it does NOT do, and the schema fully documents the input fields and constraints. Annotations cover safety, and the description clarifies behavior sufficiently for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for both parameters (rows and schemaVersion) with detailed field constraints and semantics. The tool description does not add parameter-specific meaning; it only refers generally to the evidence packet and formatting, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: transforming a buyer-owned evidence packet into a stable citation table with specific components (bounded Markdown citations, host/source counts, limitations, digests). It also distinguishes itself by explicitly negating browse, fetch, verify, rank, or enrich actions, setting it apart from potential sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have a small buyer-owned evidence packet) and clearly states when-not (it does not browse, fetch, verify, rank, or enrich). However, it does not explicitly name alternative sibling tools, so it stops short of the full 5 criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-evidence-snapshot-diffUS Brand Evidence Snapshot DiffACompare two small buyer-supplied US brand evidence snapshots and return a stable machine-readable report of added, removed, changed, and unchanged records. Inline-only, deterministic, and designed for agents that already own both snapshots. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| primary | Yes | One to 50 rows for the side selected by primarySide. Identical rows are rejected structurally; runtime also rejects the same dedupeKey across non-identical rows. | |
| counterpart | No | Optional one to 50 rows for the opposite side; omit it for an empty counterpart snapshot. Runtime rejects repeated dedupeKey values. | |
| primarySide | Yes | Whether primary rows are the before or after snapshot. | before |
| schemaVersion | Yes | schemaVersion | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: 'Inline-only, deterministic,' 'stable machine-readable report,' and the explicit operation of comparing two snapshots, which goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and result, then adds relevant constraints and pricing. Every clause earns its place, making it efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema and annotations, the description is largely complete. It explains purpose, use context, determinism, and inline-only behavior. It does not specify the exact output format, but the stated report categories and the presence of no output schema keep this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters, including nested fields. The description adds high-level context like 'buyer-supplied' and 'both snapshots,' but does not improve per-parameter semantics beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compare') with a clear resource ('two small buyer-supplied US brand evidence snapshots') and specifies the output categories ('added, removed, changed, and unchanged records'). This clearly distinguishes it from sibling tools like chronology builders or normalizers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'designed for agents that already own both snapshots,' giving clear context for when to use it. It also notes 'Inline-only,' which implies when external fetching is not appropriate, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-federal-award-snapshotUS Brand Federal Award SnapshotAGiven one exact USAspending recipient ID and a bounded UTC date window, return a deterministic snapshot of federal contract transactions for that recipient. Built for company and government-intelligence agents; no buyer URL, API key, browser, or LLM. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | Inclusive YYYY-MM-DD end date, no later than the UTC run date. | |
| requestId | No | Optional bounded correlation label; it is not replay state. | |
| startDate | Yes | Inclusive YYYY-MM-DD start date; runtime validation enforces the calendar and 2007-10-01 lower bound. | |
| maxResults | No | Maximum number of exact-attributed transactions in the one snapshot row. | |
| recipientId | Yes | USAspending lowercase child recipient ID ending in -C. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: 'deterministic snapshot' indicates consistent outputs, and 'no buyer URL, API key, browser, or LLM' clarifies it is a direct, low-dependency API. Pricing and payment method ($0.05/call, x402 USDC on base) provide operational transparency beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, the second embeds target audience, dependency constraints, and cost. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With strong annotations, 100% schema coverage, and a clear statement of inputs and output content (federal contract transactions), the description provides all essential context for an agent to select and invoke the tool. The absence of an output schema is acceptable given the tool's straightforward snapshot nature, and the description mentions the key operational constraints (cost, no API key).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed per-parameter descriptions including regex patterns, defaults, and semantic meaning (e.g., 'child recipient ID ending in -C'). The description summarizes the two key inputs ('one exact USAspending recipient ID and a bounded UTC date window') but adds no new parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'return a deterministic snapshot of federal contract transactions for that recipient.' It also defines exact input constraints (one USAspending recipient ID, bounded UTC date window), which clearly distinguishes it from the many sibling analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for federal contract transaction retrieval and says 'built for company and government-intelligence agents,' but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No sibling tool names or conditions are provided, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-offer-evidence-normalizerUS Brand Offer Evidence NormalizerATurn supplied US brand offer, coupon, ad, and landing-page evidence into closed deterministic JSON. Submit bounded inline rows or one authorized read-only Dataset; the Actor validates source proof and terms without browsing or inferring ownership. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | One to 100 closed evidence-row objects. Leave empty when selecting a Dataset. | |
| options | No | Labels are off unless an explicit model and caller key are supplied in BYOK mode. | |
| datasetId | No | One resource selected with READ permission. Dataset V1 accepts at most 10 rows and probes 11 in one SDK call. Leave empty when using inline rows. | |
| requestId | Yes | Correlation ID for this run. Reusing it in another run does not deduplicate purchases. | |
| schemaVersion | Yes | Required V1 contract version. | 1.0 |
| openrouterApiKey | No | Optional caller-owned key for BYOK labels. The runtime must redact and never persist it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it validates source proof and terms, does not browse or infer ownership, produces deterministic output, and costs $0.05/call. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose in the first sentence and constraints/modes in the second. Every word earns its place: there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema (6 params, nested objects) and no output schema, the description covers the essential context: what the tool does, input modes, constraints (bounded rows, authorized read-only Dataset), and behavioral boundaries (no browsing, no ownership inference). It does not describe output structure, but the phrase 'closed deterministic JSON' gives a reasonable expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema itself thoroughly documents every parameter. The description adds only a high-level mention of 'bounded inline rows or one authorized read-only Dataset,' which maps to the rows/datasetId choice but does not add syntax or detailed semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Turn'), specifies the resource ('US brand offer, coupon, ad, and landing-page evidence'), and gives the output ('closed deterministic JSON'). It distinguishes itself from sibling evidence tools by noting it validates source proof and terms without browsing or inferring ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs how to submit input: 'bounded inline rows or one authorized read-only Dataset.' It also provides a boundary by stating it does 'not browsing or inferring ownership,' which implies when this tool is not appropriate. It does not name explicit alternative tools, but the guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-batch-splitterUS Brand Signal Batch SplitterASplit a bounded batch of normalized US brand signal rows by brand, event type, severity, or analysis status. Receive stable groups, exact IDs, counts, and SHA-256 digests without browsing, enrichment, inference, or child calls. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 rows. Rows are submitted facts; this Actor does not verify, enrich, or infer them. | |
| groupingMode | Yes | Choose the submitted row field used as the group key. | brand |
| schemaVersion | Yes | Required closed V1 contract. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=true, but the description says 'without browsing, enrichment, inference, or child calls' and promises 'stable groups', implying a closed, deterministic operation. This directly contradicts the openWorldHint annotation and creates significant uncertainty about the tool's actual behavior. ReadOnlyHint and destructiveHint are consistent, but the openWorldHint mismatch is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus pricing, with the action and grouping keys front-loaded in the first sentence. The second sentence lists output guarantees and exclusions concisely. There is no filler; every clause adds informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a small 3-param schema with no output schema, the description covers input scope, output characteristics (stable groups, exact IDs, counts, SHA-256), and boundary conditions (no browsing, enrichment, inference, or child calls). It could mention error behavior or exact output format, but it is largely complete for a pure grouping tool. The openWorldHint contradiction slightly undermines overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters and their enums. The description adds a high-level enumeration of grouping modes and output digest details, but it does not provide field-level semantics beyond what the schema already explains, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with the specific verb 'Split', identifies the resource ('bounded batch of normalized US brand signal rows'), and enumerates the grouping dimensions (brand, event type, severity, analysis status). The phrase 'without browsing, enrichment, inference, or child calls' helps distinguish it from sibling analysis tools, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the agent needs deterministic grouping of already-normalized rows and explicitly wants to avoid enrichment, inference, browsing, or child calls. It does not name sibling alternatives explicitly, but the exclusion list provides clear when-not guidance, making usage context sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-brand-summaryUS Brand Signal Brand SummaryASummarize 1 to 60 buyer-supplied normalized US brand signals for up to 15 explicit brands. Receive deterministic counts and grouped facts without identity resolution, source verification, browsing, or live enrichment. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 60 unique signal rows. brandName is explicit and input order is ignored. | |
| schemaVersion | Yes | Required closed V1 contract. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds valuable behavioral details: outputs are 'deterministic,' inputs are 'buyer-supplied' with 'explicit brands,' and it explicitly does not do 'identity resolution, source verification, browsing, or live enrichment.' It also mentions pricing and payment rail ('$0.05/call, x402 (USDC on base)'), which helps operational decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that front-load the core action and scope, then pack limitations and pricing into the second sentence. Every clause serves a purpose, with no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a rich schema and annotations, the description covers purpose, input constraints, and behavioral limits. It indicates the output type ('deterministic counts and grouped facts') but does not detail the exact structure of the return value, and there is no output schema. However, the description is sufficient for an agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for both parameters: rows has min/max, field descriptions, enums, and patterns; schemaVersion is a closed enum. The tool description reinforces the count limits ('1 to 60') and brand limit ('up to 15 explicit brands') already present in schema text, but it does not add new parameter-level semantics beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Summarize' and identifies the resource: 'buyer-supplied normalized US brand signals' for 'up to 15 explicit brands.' It clearly defines the output as 'deterministic counts and grouped facts' and distinguishes this tool from siblings by listing exclusionary traits: 'without identity resolution, source verification, browsing, or live enrichment.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (with normalized buyer-supplied signals, up to 15 explicit brands) and exclusions (no identity resolution, source verification, browsing, or live enrichment), effectively telling the agent what this tool is not for. However, it does not explicitly name alternative sibling tools for those excluded capabilities, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-brief-composerUS Brand Signal Brief ComposerATurn a buyer-supplied snapshot of US brand signals into one bounded deterministic machine-readable brief. It reduces the facts you provide and does not discover, fetch, verify, or enrich evidence. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | Exactly 1-50 closed rows. Input order is ignored; rows are sorted deterministically. | |
| title | Yes | Printable ASCII title bound into the brief digest. | Nike US signal brief |
| snapshotAt | Yes | Explicit UTC timestamp with a real Gregorian calendar date. It is also emitted as generatedAt; the Actor never reads the current clock. | 2026-08-05T00:00:00Z |
| schemaVersion | Yes | Required closed V1 contract. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations. Annotations include openWorldHint: true, implying the tool may access external data or open-world knowledge, but the description explicitly states it 'does not discover, fetch, verify, or enrich evidence' and is bounded to the buyer-supplied facts. This is a serious inconsistency, warranting a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose, followed by a clarifying exclusion and cost/payment info. Every word adds value, with no redundancy or filler. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 fully documented required parameters and no output schema, the description provides sufficient context: it clarifies the input boundary, the transformation nature, and the cost. It leaves no major gaps about usage or input constraints. However, the contradiction with openWorldHint slightly undermines trust, so a 4 rather than 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for each parameter (e.g., 'Explicit UTC timestamp with a real Gregorian calendar date' for snapshotAt, and 'Input order is ignored; rows are sorted deterministically' for rows). The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Turn a buyer-supplied snapshot of US brand signals into one bounded deterministic machine-readable brief.' It uses a specific verb ('Turn') and resource ('buyer-supplied snapshot of US brand signals'), and explicitly distinguishes itself from sibling tools by noting it 'reduces the facts you provide and does not discover, fetch, verify, or enrich evidence.' This makes its purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when the user already has a snapshot and wants a composed brief. It also gives exclusions—'does not discover, fetch, verify, or enrich evidence'—which tells the agent not to use this tool for evidence gathering or enrichment. However, it does not name specific alternative tools, so it stops short of explicit 'use X instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-confidence-gateUS Brand Signal Confidence GateAClassify buyer-supplied normalized US brand signal scores against explicit accept and review thresholds. Receive sorted accepted, review, and rejected IDs with stable reason codes, counts, and digests; no source or identity claims are made. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 unique signal IDs with integer normalized scores from 1 to 100. IDs are sorted by the runtime before classification. | |
| thresholds | Yes | Accept is inclusive at acceptThreshold; review is inclusive from reviewThreshold up to, but excluding, acceptThreshold. The required ordering marker prevents ambiguity. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations: 'no source or identity claims are made' clarifies the openWorldHint, and it discloses the output structure (sorted IDs, reason codes, counts, digests) and cost. This is a good behavioral profile for an inline read-only classifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a pricing note. The first sentence delivers the core purpose, the second covers output and caveats, and the short billing note adds cost transparency. Every sentence earns its place, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested thresholds and rows, no output schema), the description covers the essential aspects: what it does, what it returns, and key caveats (no source/identity claims). It does not detail every reason code or threshold boundary, but the schema fully documents those constraints, so this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by tying parameters to behavior: thresholds are used for classification, and rows are buyer-supplied with no identity claims. It does not repeat schema details but reinforces how inputs drive the output, which supports parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Classify buyer-supplied normalized US brand signal scores against explicit accept and review thresholds.' The verb 'classify' is specific, the resource (normalized US brand signal scores) is clear, and the output (sorted accepted/review/rejected IDs) distinguishes this from sibling tools like rule-router or policy-simulator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the classification behavior and outputs, but it does not explicitly state when to use this tool versus alternatives like us-brand-signal-rule-router or us-brand-signal-policy-simulator. No exclusions or alternative recommendations are provided, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-cooccurrence-analyzerUS Brand Signal Co-occurrence AnalyzerAMeasure how often buyer-supplied opaque signal IDs appear together in bounded observation groups. Return stable signal counts, unordered pair counts, support, Jaccard overlap, and digests without fetching or making causality claims. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| groups | Yes | One to 100 named groups. Each group may contain up to 30 unique opaque signal IDs. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations: it explicitly denies fetching and causality claims, notes 'stable' counts, and mentions the $0.05/call fee. This is useful extra context within the lower bar set by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences plus a pricing tag. It leads with the main verb and key object, specifies outputs, and adds a caveat ('without fetching or making causality claims') without redundancy. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey return values; it does by listing counts, pair counts, support, Jaccard overlap, and digests. It also states input constraints via 'bounded observation groups' and explicitly disclaims fetching/causality. 'Digests' is not fully explained, but the tool is a simple analyzer with clear scope, so a 4 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters (groups and schemaVersion) thoroughly. The description mostly restates the conceptual purpose (opaque signal IDs, bounded groups) and does not add new parameter-level syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Measure') and clearly specifies the resource ('buyer-supplied opaque signal IDs appear together in bounded observation groups'). It enumerates concrete outputs (stable signal counts, unordered pair counts, support, Jaccard overlap, digests), which distinguishes it from sibling tools like the cross-tabulator or metrics aggregator by focusing on co-occurrence statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it works on bounded observation groups and explicitly excludes fetching or making causality claims. This signals when not to use it (e.g., when causality or external data is needed), though it does not name specific alternative tools. That is clear context with implicit exclusions, scoring a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-crm-field-mapperUS Brand Signal CRM Field MapperATurn 1 to 100 buyer-supplied US brand signal rows into unsent HubSpot, Salesforce, or generic CRM field proposals while preserving evidence IDs and URLs. No CRM credentials, network calls, proxy, LLM, identity resolution, or arbitrary expressions. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to one hundred rows with explicit opaque entity IDs and source evidence. | |
| target | Yes | Select the closed target field vocabulary; this Actor does not call the target CRM. | hubspot |
| mapping | Yes | Each source field may appear once and must map to the exact target field allowed for the selected CRM. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'unsent' and explicit negations ('No CRM credentials, network calls...'). It adds behavioral context about preserving evidence IDs/URLs and the pricing/call model, going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the primary function, then lists key exclusions and pricing. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with nested rows and mappings, but the schema covers parameter details and the description covers high-level behavior and constraints. With no output schema, a bit more explanation of the 'field proposals' output shape could help, but the current description is sufficient for a mapping tool with strong schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains every parameter in detail. The description does not add new parameter-specific semantics beyond summarizing the batch size and the mapping purpose, which matches the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action: turning 1-100 buyer-supplied US brand signal rows into unsent CRM field proposals for HubSpot, Salesforce, or generic CRM, while preserving evidence IDs and URLs. It clearly distinguishes the tool's scope from siblings by naming the CRM mapping focus and the 'unsent' output nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies when to use by listing exclusions: no CRM credentials, network calls, proxy, LLM, identity resolution, or arbitrary expressions. This helps an agent understand this is for local, safe transformation only, though it does not explicitly name alternative tools or provide direct 'when to use vs. X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-cross-tabulatorUS Brand Signal Cross-TabulatorABuild a deterministic two-dimensional count table from buyer-supplied opaque rows, such as event type by status or brand by review state. It only counts the bounded request and does not verify sources or infer causality. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 unique opaque rows. There can be at most 15 unique rowDimension values and 15 unique columnDimension values. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are already rich (readOnlyHint=true, openWorldHint=true), but the description goes beyond by adding 'deterministic', 'only counts the bounded request', and 'does not verify sources or infer causality'. It also usefully adds pricing context. These details clarify what the tool will and will not do, exceeding the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two sentences: the first states purpose with examples, the second states limitations and pricing. No filler or redundancy; every phrase carries meaning. It is front-loaded and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the output is understandably described as a 'two-dimensional count table', which is sufficient for this simple tool. The input constraints (bounded rows, at most 15 unique values) are covered in the schema, and the description clarifies the tool's limited scope. This is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented. The description adds some illustrative context (e.g., 'event type by status or brand by review state') that aids understanding of rowDimension/columnDimension, but it does not introduce novel parameter semantics beyond the schema. This matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build a deterministic two-dimensional count table from buyer-supplied opaque rows.' It then gives concrete examples ('event type by status or brand by review state') which clarify the use case and distinguish it from sibling tools like metrics-aggregator or cooccurrence-analyzer. The scope is sharpened further with 'only counts the bounded request.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool: when a simple deterministic count table is needed from opaque rows. It also states exclusions ('does not verify sources or infer causality') and that it 'only counts the bounded request', which helps rule out inappropriate uses. However, it does not explicitly name alternative sibling tools, 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.
us-brand-signal-merge-reportUS Brand Signal Merge ReportAReconcile two buyer-supplied batches of normalized US brand signals. Receive a deterministic union, exact duplicate IDs, field conflicts, one-sided ID sets, counts, and digests without choosing a winner or making a truth claim. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| left | Yes | One to 50 rows from the first sensor or workflow. | |
| right | Yes | One to 50 rows from the second sensor or workflow. | |
| schemaVersion | Yes | Closed V1 contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description aligns with that by stating it produces a report without selecting a winner. It adds useful context: deterministic output, returned digests, and pricing details ($0.05/call). It does not describe every internal step, but the key behavioral guarantees are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every phrase earns its place (inputs, outputs, key constraint, pricing). No fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates all major output components (union, exact duplicate IDs, field conflicts, one-sided sets, counts, digests), giving the agent a clear picture of results. It also communicates the critical constraint (no truth claim) and cost. Minor gaps: it doesn't explain 'digests' in detail, but the overall context is sufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, including detailed constraints (patterns, enums, bounds). The description itself adds minimal parameter-specific value beyond 'buyer-supplied' and 'normalized', which are already in the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reconcile') and resource ('two buyer-supplied batches of normalized US brand signals'), and clearly enumerates the outputs (union, duplicate IDs, field conflicts, etc.). It distinguishes from sibling tools by emphasizing 'without choosing a winner or making a truth claim', which is unique to this merge-report tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use: when you have two normalized signal batches and need a reconciliation report. It also clarifies the non-decisive nature ('without choosing a winner'), suggesting this is for analysis rather than merging into a single authoritative set. However, it does not explicitly name alternatives or state when NOT to use it, so I deduct slightly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-metrics-aggregatorUS Brand Signal Metrics AggregatorACompute deterministic machine-friendly metrics for US brand signal rows you already collected, including event, severity, status, source, confidence, warning, and digest metrics. Stateless, keyless, offline, and bounded for agent pipelines. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 closed rows. signalId is unique and all text is printable ASCII only. | |
| schemaVersion | Yes | Required closed V1 contract. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/open-world/non-destructive aspects. The description adds useful behavioral context: deterministic, stateless, keyless, offline, and bounded. It also discloses pricing and payment method ($0.05/call, x402), which informs operational usage. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at under three sentences, front-loaded with the primary verb and target. The pricing/payment adjunct is useful operational detail but arguably secondary; still, it does not feel verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing the metric categories produced. It also clarifies stateless/offline constraints and pricing. It could be improved by explicitly defining 'warning' or 'digest' metrics or stating error behavior, but overall it provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions in the schema carry the burden. The tool description mentions 'rows you already collected' but adds no new semantic details about parameters like schemaVersion or the expected row structure, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Compute deterministic machine-friendly metrics' for 'US brand signal rows you already collected,' and enumerates metric categories (event, severity, status, source, confidence, warning, digest). This clearly identifies the tool's function and differentiates it from sibling tools focused on summaries, cross-tabs, or other transformations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'rows you already collected' implies it is for post-collection processing, and 'bounded for agent pipelines' suggests a pipeline context. However, it does not explicitly state when not to use this tool or name alternative tools, leaving the agent to infer differentiation from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-policy-simulatorUS Brand Signal Policy SimulatorACompare buyer-defined threshold policies over the same opaque US brand signal scores. Return accepted, review, and rejected IDs for every policy plus differences and sensitivity summaries; it does not choose or recommend a policy. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | One to 100 unique opaque IDs with integer scores from 1 to 100. | |
| policies | Yes | One to 20 unique policies. Review must be strictly below accept. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral context beyond the annotations: it returns per-policy accepted/review/rejected IDs, differences and sensitivity summaries, and explicitly does not choose or recommend a policy. It also adds operational details ($0.05/call, x402 USDC on base), which are useful. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a cost/protocol note. It front-loads purpose, outputs, and a key limitation. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (arrays of scores and policies) and absence of an output schema, the description covers the key outputs (per-policy IDs, differences, sensitivity summaries) and the non-goal (no recommendation). It does not describe error cases or exact output structure, but the schema provides validation constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add syntax or format details beyond what the schema provides, but it does reinforce that policies are threshold-based and scores are opaque, aligning with the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compare' with a defined object 'buyer-defined threshold policies' over 'the same opaque US brand signal scores'. It clearly states the output ('Return accepted, review, and rejected IDs... plus differences and sensitivity summaries') and explicitly distinguishes itself from decision tools by saying 'it does not choose or recommend a policy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: comparing multiple threshold policies on the same input scores. It includes an explicit exclusion (does not choose/recommend), but does not name alternative sibling tools or provide more granular when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-rule-routerUS Brand Signal Rule RouterATurn normalized US brand signals and ordered rules into a deterministic routing plan with matched routes, unmatched IDs, counts, warnings, and reproducible digests. It never sends messages, calls destinations, fetches URLs, or infers identity. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | firstMatch uses the first matching rule; allMatches retains every matching rule in input order. | firstMatch |
| rules | Yes | Closed explicit predicates. Runtime additionally enforces unique rule/route IDs, NFC and UTF-8 byte bounds, and confidenceMin <= confidenceMax because the Store schema dialect cannot compare sibling values. | |
| signals | Yes | Closed rows. Runtime additionally enforces unique IDs, NFC, 256 UTF-8-byte text bounds, a 256 KiB envelope, strict calendar timestamps, and finite 9-decimal confidence values. | |
| schemaVersion | Yes | Closed input and output contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds valuable context: determinism ('deterministic routing plan', 'reproducible digests'), side-effect-free behavior ('never sends messages, calls destinations, fetches URLs'), and the closed-world constraint ('or infers identity'). It also discloses pricing, which is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the main action front-loaded. The first sentence packs the core purpose and outputs without waste; the second sentence adds essential side-effect exclusions and pricing. Every phrase earns its place, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 top-level parameters, two nested array types) and rich schema, the description is complete enough. It describes the high-level behavior and lists the key output components, which is important since there is no output schema. The exclusion of identity inference and side effects further clarifies boundaries. A full output structure description would push it to 5, but the current level is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema: it refers to 'normalized US brand signals and ordered rules' as the inputs, but the schema already documents each property with detailed descriptions, enums, and constraints. The description does not need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: turning normalized US brand signals and ordered rules into a deterministic routing plan. It enumerates specific outputs (matched routes, unmatched IDs, counts, warnings, digests) and explicitly differentiates itself from sibling tools by noting it never sends messages, calls destinations, fetches URLs, or infers identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need a deterministic routing plan from signals and rules. It also gives exclusions via 'never sends messages, calls destinations, fetches URLs, or infers identity,' implying alternatives are needed for messaging or identity inference. However, it does not explicitly name alternative tools or state 'use when...' versus 'do not use when...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-sequence-transition-analyzerUS Brand Signal Sequence Transition AnalyzerAMeasure ordered adjacent transitions in buyer-supplied opaque sequences for workflow, funnel, and journey analysis. The bounded processor analyzes only the JSON you provide and makes no identity or causality claim. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| sequences | Yes | One to 100 sequences; each contains 2 to 30 ordered opaque step IDs. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already assert readOnlyHint=true and destructiveHint=false, so the low bar is met. The description adds valuable context: 'makes no identity or causality claim' informs the agent about interpretive limits, and 'bounded processor' plus 'analyzes only the JSON you provide' indicates statelessness and no data retention. Pricing and payment method ($0.05/call, x402 USDC on base) are also disclosed, beyond what annotations capture. Not a 5 because it doesn't describe the exact output shape or whether any logs are kept, but it's solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the core function and use case; the second adds key caveats (bounded, no identity/causality claims) and monetization. No filler, no repetition of schema details. Highly scannable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description is nearly complete. It explains what the tool does, its processing boundary, and pricing. The only gap is that it doesn't describe what the output looks like (e.g., a transition count list or aggregate measures). Since there is no output schema, one could argue the description should hint at the output format, but the tool name and 'Measure... transitions' imply a quantified result. Given the strong schema and annotations, this is a minor omission, not a serious shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the schema richly describes both schemaVersion and sequences, with per-field descriptions (e.g., 'Two to 30 opaque IDs... repeated step IDs are allowed because order and loops are meaningful'). The description adds no new parameter-level semantics beyond reinforcing that sequences are 'buyer-supplied' and 'opaque.' Since the schema already carries the load, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Measure ordered adjacent transitions in buyer-supplied opaque sequences...' This clearly distinguishes it from sibling tools like cooccurrence-analyzer or cross-tabulator, which analyze different aspects of sequences. The scope (workflow, funnel, journey analysis) and the opaque-sequence constraint further refine its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use it: when you need to analyze ordered adjacent transitions in sequences for workflow/funnel/journey analysis. It also implies a boundary via 'bounded processor... analyzes only the JSON you provide,' which hints that it is not for cross-request or external data. However, it does not explicitly contrast with alternatives (e.g., 'use cooccurrence-analyzer for non-adjacent pairs'), so it misses the 'when-not-to-use' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-sla-checkerUS Brand Signal SLA CheckerAClassify buyer-supplied schedule rows against an explicit UTC timestamp: which items met their due time, missed it, or remain open. Deterministic and offline; it never fetches a clock or resolves an item to a person or company. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| asOf | Yes | Strict Gregorian UTC timestamp in YYYY-MM-DDTHH:mm:ssZ form. This value controls all open-row classification. | |
| rows | Yes | One to 100 rows with opaque item IDs and explicit opened, due, and optional resolved timestamps. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: deterministic, offline, no live clock, no identity resolution, and a per-call cost. No contradiction exists; the description significantly enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose with a clear verb and outcome, the second covers offline/deterministic behavior and cost. Every sentence earns its place, with no fluff or redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity is moderate, and the schema plus annotations are rich. The description covers the core classification logic and alludes to output categories, but it does not explicitly describe the output format (e.g., a per-row list with statuses). Given the lack of an output schema, a slightly more explicit mention of return structure would make it more complete, but the current coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not repeat parameter details and adds minimal new meaning beyond what the schema provides. The phrase 'explicit UTC timestamp' aligns with asOf, but it doesn't enrich the semantics of rows, schemaVersion, or asOf further that the schema doesn't already state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Classify') and a clear resource ('buyer-supplied schedule rows'), and defines the three output states (met, missed, open). This clearly distinguishes the tool from siblings by its focus on SLA classification and its deterministic/offline nature, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides meaningful context by stating the tool is deterministic, offline, never fetches a clock, and never resolves to a person/company. This implies when to use it (when deterministic offline classification is needed) but does not explicitly name alternative tools or exclusion cases, so it stops short of full guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
us-brand-signal-webhook-payload-builderUS Brand Signal Webhook Payload BuilderABuild one bounded deterministic unsent payload shaped for Slack, Teams, or a generic webhook from one normalized signal and buyer-supplied evidence. The Actor never sends a webhook or accepts a destination. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | Buyer-provided text and one to three HTTPS evidence records. No identity or live-source lookup is performed. | |
| target | Yes | A closed enum only. This selects a local JSON shape; it never supplies a destination. | slack |
| presentation | Yes | Only these booleans, style enum, and bounded character limit are accepted. Templates and expressions are not supported. | |
| schemaVersion | Yes | The only supported closed contract version. | 1.0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: the tool never sends a webhook, never accepts a destination, and produces 'bounded deterministic' output. The pricing note ($0.05/call, x402) is an additional transparency element. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first densely packs purpose, scope, and target selection; the second states a vital safety guarantee. No repetitive or unnecessary wording, and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested inputs and 4 parameters, the schema thoroughly documents all inputs and constraints. The description covers purpose, safety, and pricing. Since there is no output schema, the description could have clarified return-value structure, but the tool name and purpose make it obvious that it returns the built payload. The overall definition is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage with detailed field descriptions, enums, nested item schemas, and constraints (e.g., maxLength, patterns, min/maxItems). The description itself adds no parameter-specific information, but the schema already carries that burden. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Build one bounded deterministic unsent payload') with clear targets (Slack, Teams, generic webhook) and input source ('normalized signal and buyer-supplied evidence'). It distinguishes from siblings by explicitly noting 'The Actor never sends a webhook or accepts a destination,' which differentiates it from any potential sending or destination-consuming tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: to construct a payload for Slack/Teams/generic from a normalized signal and evidence. It also provides an exclusion by stating 'never sends a webhook or accepts a destination,' which signals when not to use it (if delivery is needed). However, it does not name specific alternative tools, so it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on 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.
No comments yet. Be the first to start the discussion!
