Skip to main content
Glama
Sign In

Straelo Relay

by com.straelo
OverviewDiscussionsAdmin

Vendor Customer Transition Signal Lookup

vendor_customer_transition_signal_lookup

Find customer domains with observed technology transition signals involving a specified vendor and return prioritized signals with supporting evidence. USE WHEN: an agent needs to identify customer-level technology transition signals related to a vendor for prospecting or change analysis. DO NOT USE WHEN: the agent needs confirmed proof that a customer switched from one vendor to another (vendor_customer_confirmed_lookup), historical ADDED/REMOVED adoption events (vendor_customer_adoption_change_lookup), or vendors currently detected on a specific customer domain (customer_vendor_detection); POSSIBLE_REPLACEMENT is a correlated signal, not a confirmed switch. Side effect: unsupported-vendor requests may persist aggregated demand telemetry. Results reflect CSI snapshots and may change between calls.

Input Schema

NameRequiredDescriptionDefault
vendorYesVendor whose customer technology transition signals should be evaluated. Supported values: yotpo, judge.me.

Output Schema

NameRequiredDescriptionDefault
errorNoError type name on pipeline/discovery error, otherwise null.
leadsYesPrioritized transition signals when available.
staleYesWhether the CSI snapshot is stale and no longer actionable.
demandNoDemand telemetry for unsupported vendors.
reasonNoHuman-readable reason for the status, when applicable.
statusYesMachine-readable outcome status for the request.
vendorYesNormalized vendor/technology key queried.
chargedYesWhether payment was settled for this chargeable CSI delivery; false for unsupported or non-chargeable outcomes.
targetsYesValidated target domains scanned.
supportedYesWhether the queried vendor is supported by this capability.
actionableYesWhether the transition signal is actionable for commercial delivery.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / actionable
      Added value: +{
+  "description": "Whether the transition signal is actionable for commercial delivery.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / stale
      Added value: +{
+  "description": "Whether the CSI snapshot is stale and no longer actionable.",
+  "type": "boolean"
+}
    • changedOutput schema / required
      Previous value: -[
-  "status",
-  "vendor",
-  "supported",
-  "charged",
-  "leads",
-  "targets"
-]New value: +[
+  "status",
+  "vendor",
+  "supported",
+  "charged",
+  "leads",
+  "targets",
+  "stale",
+  "actionable"
+]
  2. Changed8 schema fields changed
    • changedInput schema / properties / vendor / description
      Previous value: -"Vendor whose customer technology transition signals should be evaluated."New value: +"Vendor whose customer technology transition signals should be evaluated. Supported values: yotpo, judge.me."
    • addedOutput schema / properties / charged / description
      Added value: +"Whether payment was settled for this chargeable CSI delivery; false for unsupported or non-chargeable outcomes."
    • addedOutput schema / properties / error / description
      Added value: +"Error type name on pipeline/discovery error, otherwise null."
    • addedOutput schema / properties / reason / description
      Added value: +"Human-readable reason for the status, when applicable."
    • addedOutput schema / properties / status / description
      Added value: +"Machine-readable outcome status for the request."
    • changedOutput schema / properties / status / enum
      Previous value: -[
-  "OK",
-  "UNSUPPORTED_VENDOR",
-  "NO_TARGETS_FOUND",
-  "PIPELINE_ERROR",
-  "INVALID_INPUT"
-]New value: +[
+  "OK",
+  "UNSUPPORTED_VENDOR",
+  "NO_TARGETS_FOUND",
+  "PIPELINE_ERROR",
+  "INVALID_INPUT",
+  "UNKNOWN_PAYMENT_STATE",
+  "REFRESH_REQUIRED",
+  "DISCOVERY_REQUIRED",
+  "DISCOVERY_COOLDOWN"
+]
    • addedOutput schema / properties / supported / description
      Added value: +"Whether the queried vendor is supported by this capability."
    • addedOutput schema / properties / vendor / description
      Added value: +"Normalized vendor/technology key queried."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description reconciles the non-read-only annotation by disclosing that unsupported-vendor requests may persist aggregated demand telemetry, and explains non-idempotency by noting results reflect CSI snapshots that change between calls. These are real behavioral facts the annotations alone (readOnlyHint=false, openWorldHint=true, idempotentHint=false) only hint at.

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

Conciseness4/5

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

Front-loaded purpose followed by clearly labeled USE WHEN / DO NOT USE WHEN blocks, then side-effect caveats — a good ordering. Slight redundancy between the opening sentence and the USE WHEN restatement, and the DO NOT USE clause packs four siblings into one dense sentence.

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

Completeness5/5

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

For a single-parameter lookup with an output schema, full annotation coverage, and a rich sibling set, the description covers selection, semantics of the signal type, side effects, and data freshness. Nothing needed to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% and the enum is fully documented, so the baseline is already 3. The description adds meaning beyond the schema by warning that unsupported vendor values do not simply fail but trigger demand telemetry, which changes how an agent should treat the vendor argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb+resource ('Find customer domains with observed technology transition signals involving a specified vendor') plus the return shape ('prioritized signals with supporting evidence'). It is immediately distinguishable from the sibling lookups, which are even named later.

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

Usage Guidelines5/5

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

Explicit USE WHEN and DO NOT USE WHEN blocks name three concrete alternatives (vendor_customer_confirmed_lookup, vendor_customer_adoption_change_lookup, customer_vendor_detection) with the condition selecting each. It also pre-empts the most likely misuse by stating that POSSIBLE_REPLACEMENT is a correlated signal, not a confirmed switch.

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

All Straelo Relay toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources