Market regime, execution-cost, bar-QC and backtest-audit tools for agents. Pay per call via x402.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 21 of 21 tools scored. Lowest: 2.9/5.
Each tool has a distinct purpose, with clear differentiation between SYGNL/47 event tiers (live, 1m, 15m, archive), subscription management, and auxiliary tools like backtesting and regime detection. No overlapping functionality.
Most tools follow a descriptive underscore pattern, with 'sygnl47_' prefix for event and subscription tools, and 'get_' for data retrieval. Some variation in verb prefixes (audit, check, estimate) but overall predictable and readable.
21 tools is slightly high but justified by the tiered data access model for SYGNL/47 events and supporting infrastructure. The count covers core functionality without being excessive.
The tool set covers the stated domain well: event monitoring at different recency, backtesting, regime detection, and subscription management. Minor gaps like historical pricing data are not central to the server's focus.
audit_backtestBInspectForensic audit of a backtest trade ledger ($5.00).
Impossible-fill detection against the real tape, cost-adjusted expectancy, overfitting checks, verdict + grade. trades_csv: CSV text with columns like symbol, side, entry_time, exit_time, entry_price, exit_price, qty.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | No | large_cap | |
| n_trials | No | ||
| trades_csv | Yes | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a $5.00 cost but lacks details on authorization needs, rate limits, or side effects. With no annotations, it partially carries the transparency burden but misses important behavioral traits.
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?
Three sentences cover purpose, capabilities, and parameter format. Could be more structured, but overall concise without redundant information.
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?
Lacks details on output format (verdict and grade), default parameter behaviors, and error handling. Given 4 parameters and no output schema, the description is incomplete for full tool understanding.
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 description adds meaning for the 'trades_csv' parameter by specifying required columns, but does not explain 'preset', 'n_trials', or 'payment_signature'. Schema coverage is 0%, so description partially compensates but is incomplete.
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 as a forensic audit of a backtest trade ledger, listing specific checks like impossible-fill detection and overfitting. It distinguishes from sibling tools which focus on bar quality, execution cost, pricing, and regime analysis.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide comparisons to sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_bar_qualityAInspectForensic QC on YOUR OHLCV bars before you backtest on them ($0.05).
Detects impossible bars, bad prints, unadjusted splits, gaps, stale data. bars: [{timestamp, open, high, low, close, volume}, ...] (5..100000 rows)
| Name | Required | Description | Default |
|---|---|---|---|
| bars | Yes | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions cost and data size, but does not describe what the tool returns (e.g., a report object) or any side effects. For a QC tool, the return structure is crucial for agent decision-making, and it is missing.
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?
Extremely concise: three lines with no superfluous content. The purpose is front-loaded, key checks are listed, and the bars format is specified. Every sentence 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?
Given no output schema and no annotations, the description covers purpose and bars param adequately but omits the output format and the optional payment_signature parameter. For a simple tool with 2 params, this is acceptable 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 coverage is 0%, so description adds value. It explains the 'bars' parameter structure: expected fields (timestamp, open, high, low, close, volume) and valid size range (5..100000 rows). However, 'payment_signature' is not explained, leaving its purpose unclear.
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 it performs forensic QC on OHLCV bars before backtesting. It lists specific detections (impossible bars, bad prints, etc.) and distinguishes from sibling tools like audit_backtest and trade_preflight by focusing on pre-backtest data quality.
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?
Explicitly says 'before you backtest on them', indicating when to use. Mentions cost ($0.05) as a consideration. Does not explicitly state when not to use or list alternatives, but context with siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_execution_costAInspectRealistic execution cost in bps for an order ($0.01).
Calibrated to measured live fills (SPY/QQQ 1.5bps round-trip floor), with square-root size impact. order_type: limit_nbbo | market.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | buy | |
| symbol | Yes | ||
| order_type | No | limit_nbbo | |
| notional_usd | Yes | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the model (square-root size impact), calibration source (measured live fills), and supported order types. No annotations provided, so description compensates well but could mention if any side effects or authentication exist.
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?
Short and efficient, no redundant text. However, lacks structure for easy scanning (e.g., separating parameter 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?
Provides unit (bps) and floor cost ($0.01), and mentions calibration. But no output schema exists, and description does not specify return format or whether it's a single number or object. Partial coverage.
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?
Only order_type is partially explained with two values. No explanation for side, payment_signature, symbol, or notional_usd beyond what schema provides. With 0% schema coverage, description fails to compensate.
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 estimates realistic execution cost in bps for an order, with a floor of $0.01. It specifies calibration to SPY/QQQ and order type support, distinguishing it from pricing 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?
No guidance on when or when not to use this tool compared to siblings like get_pricing or trade_preflight. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspectFREE: price list, payment network, and payTo address for all paid tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It mentions output content but does not disclose side effects, authentication requirements, rate limits, or whether the tool is read-only. This lacks sufficient detail for safe invocation.
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 sentence, efficiently conveying the core purpose and scope. Every word is necessary, and the 'FREE:' prefix provides a secondary context without 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?
The description covers the output content but is vague on format (e.g., whether it returns a list or object). It does not mention prerequisites like authentication or existence of paid tools. Given no output schema, more detail on return structure would improve 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?
The input schema has no parameters, so the description cannot add parameter details. However, it effectively sets expectations by stating the tool returns pricing data for all paid tools, which is useful context for a parameterless tool.
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 retrieves a price list, payment network, and PayTo address for all paid tools. It is distinct from sibling tools which focus on backtesting, bar quality, execution cost, and regime analysis.
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 when pricing information is needed but does not explicitly state when to use or avoid this tool, nor does it mention alternatives. The context of siblings suggests it is for pricing, but no direct guidelines are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regime_currentAInspectLive market regime: STABLE/VOLATILE + confidence + position_scalar ($0.005).
Validated variance detector: VOLATILE predicts ~2x forward volatility with ~90% persistence. Use for position sizing / risk gating, NOT direction.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it is a variance detector predicting forward volatility with persistence, and that it should not be used for direction. This is sufficient behavioral context.
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?
Extremely concise: two short paragraphs with essential information front-loaded. Every sentence 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?
The description explains the output structure but omits documentation for the payment_signature parameter. With one undocumented parameter and no output schema, it is adequate but incomplete.
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 has one parameter 'payment_signature' with 0% description coverage. The description does not mention this parameter at all, leaving its purpose and usage unexplained.
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 it returns the live market regime (STABLE/VOLATILE) with confidence and position_scalar. The name 'get_regime_current' distinguishes it from siblings like get_regime_history, but the description does not explicitly differentiate.
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?
Explicitly advises 'Use for position sizing / risk gating, NOT direction.' This provides clear when-to-use and when-not-to-use guidance, though it does not mention sibling tools for directional analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regime_historyCInspectHistorical regime snapshots, 5-min cadence since 2026-02, 417k+ rows ($0.02).
start/end are ISO timestamps; limit <= 10000.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| limit | No | ||
| start | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions cost ($0.02) and row count (417k+), but does not disclose whether the operation is read-only, destructive, requires authentication, or has side effects. Key behavioral traits are missing.
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 extremely concise, using only two sentences to convey essential information. It is front-loaded with the most critical details (cadence, time range, cost, constraints) and contains no filler or redundant text.
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 has 4 parameters, no output schema, and no annotations. The description fails to explain the output structure (e.g., fields in each regime snapshot) and leaves one parameter ('payment_signature') undocumented. This is insufficient for an agent to fully understand the tool's usage and results.
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 description adds meaning for three parameters (start, end, limit) by specifying ISO timestamp format and a maximum limit of 10000. However, the 'payment_signature' parameter is not mentioned, leaving its purpose unclear. Given 0% schema description coverage, the description partially compensates but is incomplete.
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 indicates this tool returns historical regime snapshots with a specific cadence (5-min) and time range (since 2026-02). The name 'get_regime_history' and sibling tools like 'get_regime_current' further reinforce its purpose, though the exact nature of a 'regime snapshot' could be more explicit.
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?
No explicit guidance on when to use this tool versus alternatives like 'get_regime_current' or 'get_regime_sample'. The description states constraints (start/end timestamps, limit) but lacks when-not-to-use or scenario-based recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regime_sampleAInspectFREE: 24h-delayed market regime snapshot (taste of the live paid feed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is free and 24-hour delayed, which are key behavioral traits. It does not specify output format or any limits, but for a sample tool, these are reasonable omissions. No contradiction with annotations since none exist.
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 sentence that is front-loaded with 'FREE' and conveys all essential information: purpose, delay, and nature (taste of paid feed). 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 no output schema, the description does not detail return values, but it mentions 'market regime snapshot,' which gives a general idea. For a simple free sample tool with zero parameters, this is sufficient context. Missing details like data format are minor for this tool's purpose.
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?
There are zero parameters, and schema coverage is 100% (vacuously). According to guidelines, baseline is 4 when no parameters exist. The description adds no param info, but none is needed.
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 provides a free, 24-hour delayed market regime snapshot, distinguishing it from siblings like get_regime_current and get_regime_history by being a sample/taste. It uses specific verb 'get' and resource 'regime sample' with key attributes (free, delayed).
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 this tool is for sampling the paid feed due to its free and delayed nature, but it does not explicitly state when to use this tool versus alternatives. Sibling tools (current, history) are not mentioned; guidance is indirect at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_entitiesAInspectTracked entity gazetteer plus today's guard state ($0.25).
RETURNS: every entity SYGNL/47 listens for with its disambiguation rules attached — a country only counts when a policy instrument is nearby, "intel" does not count next to "agency", "apple" does not count next to "pie" — and, per ticker, whether it is BLOCKED right now by the earnings and liquidity guards, with the reason string. WHY IT CHANGES: a name being watched and a name being actionable today are different facts. An earnings print inside the holding window destroys move attribution, so those names are refused outright. Liquidity below $10M 20-session average dollar volume is a hard reject. A guard that could not check reports UNKNOWN and never silently passes. GUARANTEED MAX STALENESS: guard state is resolved at publish time; the response carries guards_evaluated_utc and sync.feed_age_seconds so you can judge it yourself. PRICE: $0.25 USDC. NOT A PREDICTION: this is a reference and constraint dataset, not a recommendation to trade any name it lists as allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: returns disambiguation rules, guard state with reasons, explains why state changes (earnings prints, liquidity), guarantees staleness with timestamps, and states pricing. Very 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 verbose but well-structured with labeled sections. However, it could be more concise while retaining all key information.
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 low complexity (1 parameter, no output schema, no annotations), the description is rich in behavioral details. However, missing parameter explanation and usage guidance prevent higher score.
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 only parameter, 'payment_signature', has no description in the schema (0% coverage) and the tool description does not explain its purpose or usage. The mention of '$0.25 USDC' does not clarify the parameter role.
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 that the tool returns a 'tracked entity gazetteer plus today's guard state', with specific disambiguation rules and per-ticker BLOCKED status. This distinguishes it from sibling tools that focus on events or 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?
The description does not provide guidance on when to use this tool versus its siblings. It includes a disclaimer 'NOT A PREDICTION' but no explicit comparison or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_event_detailAInspectFull detail for one SYGNL/47 event by id ($2.00).
RETURNS: the complete event — verbatim snippet (180-char cap), verification block (live vs replay, liveness reason, independent source count, consensus confidence) and market attribution (mark, benchmark, abnormal return by horizon). GUARANTEED MAX STALENESS: none — this serves events of any age including the newest, which is why it is priced at the live tier rather than the archive tier. PRICE: $2.00 USDC. An unknown event_id returns 404 and is NOT settled. NOT A PREDICTION: verified observation of a public statement. event_id example: sygnl47-20260727-192342-GM
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses behavior: returns detailed structure, pricing, staleness guarantee, error handling (404), and nature (verified observation).
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?
Description is organized into labeled sections (RETURNS, GUARANTEED, PRICE, NOT A PREDICTION) and is concise while covering key 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?
No output schema, but description fully explains return structure, pricing, and error handling. Adequate for a single-entity detail 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 coverage 0% so description must compensate. Provides example for event_id but does not explain payment_signature parameter, leaving ambiguity.
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 'Full detail for one SYGNL/47 event by id' with pricing. Distinguishes from sibling tools that list events.
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?
Explains pricing tier and that it serves events of any age. Mentions it is 'NOT A PREDICTION' and returns 404 for unknown IDs, but does not explicitly compare to sibling tools like latest_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_events_15mAInspectVerified POTUS statement events, nothing newer than 15 minutes ($0.25).
RETURNS: the same complete payload as the live tier, including the full verification and market-attribution blocks. GUARANTEED MAX STALENESS: 900 seconds. PRICE: $0.25 USDC. Appropriate for attribution and research rather than reaction. NOT A PREDICTION: verified observation, no edge claim.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: guaranteed max staleness of 900 seconds, price of $0.25 USDC, and that it returns the same payload as the live tier including verification and market-attribution blocks. This provides sufficient behavioral context.
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 and front-loaded with essential info: purpose, staleness, price. It then details return payload and usage. However, it could be more structured with parameter explanations.
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 complexity (3 params, no output schema, no annotations), the description covers purpose and behavior but omits parameter semantics, making it incomplete for an agent to use without additional context.
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 0% and the description does not explain any of the three parameters (limit, since, payment_signature). An agent has no guidance on how to use these inputs, which is a critical gap for correct invocation.
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 it provides 'Verified POTUS statement events' with a maximum staleness of 15 minutes. It distinguishes from siblings by specifying the time delay and price, but lacks explicit comparison to similar tools like sygnl47_events_1m or sygnl47_events_live.
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 guides usage by stating 'Appropriate for attribution and research rather than reaction' and clarifies it is 'verified observation, no edge claim.' This implies appropriate contexts, though it does not explicitly list excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_events_1mBInspectVerified POTUS statement events, nothing newer than 60 seconds ($0.75).
RETURNS: identical schema, identical fields and identical verification block to the live tier. Nothing is stripped — only recency is. GUARANTEED MAX STALENESS: 60 seconds. The cutoff is enforced server-side on ts_utc and bound to this priced route, not to any argument you send. PRICE: $0.75 USDC. NOT A PREDICTION: verified observation, no edge claim.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It discloses guaranteed max staleness, server-side enforcement, price, and that it is not a prediction. It does not cover authentication or rate limits, but for a read-only tool this is adequate.
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 clear and front-loaded but contains redundant phrases (e.g., emphasizing 'nothing newer than 60 seconds' multiple times). It could be more concise without losing key information.
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 description explains the return format (identical to live tier, same fields and verification block) but does not cover error handling, pagination, or parameter details. With 3 params and no output schema, it is moderately 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?
The input schema has 3 parameters (limit, since, payment_signature) with 0% schema description coverage. The tool description does not explain any parameter, leaving the agent to guess their semantics. This is a critical gap.
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 identifies the tool as returning verified POTUS statement events with a 60-second recency constraint, distinct from siblings like sygnl47_events_15m and sygnl47_events_live. It includes pricing and emphasizes it is not a prediction.
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 its own properties (recency, price) but lacks explicit guidance on when to use it over alternatives. It does not mention exclusions or prerequisites, though the fact it is priced and has a recency limit implies it is for recent verified events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_events_archiveAInspectVerified POTUS statement events at T+24h and older ($0.10).
RETURNS: the full historical record, same complete schema as every other tier — the archive is not a sample and not a degraded copy. GUARANTEED MAX STALENESS: 86400 seconds. PRICE: $0.10 USDC, the cheapest rung — deliberately kept low enough that a price-sensitive agent still has something it can transact on. INVENTORY, HONESTLY: 2 events today, both reconstructed from archived broadcast audio of one speech (2026-07-27, GM Milford Proving Ground) and labelled source: replay with sources: 1 and replay_checked: false. Two fires from one speech are not two independent observations. NOT A PREDICTION: verified observation, no edge claim, zero confirmed live outcomes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the behavioral disclosure burden. It states returns are the full historical record (not a sample), not degraded, guarantees max staleness 86400 seconds, lists price $0.10, and honestly discloses inventory details and that it is not a prediction. This is highly 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 front-loads the core purpose but becomes verbose with detailed inventory and disclaimers. While informative, it is not concise and could be streamlined without losing key points.
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 description covers data nature, pricing, freshness, and honesty, but lacks explanation of parameter usage, output schema (only mentions 'same complete schema' vaguely), and payment mechanism. For a tool with 3 params, no output schema, and no annotations, this leaves gaps.
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?
Despite 0% schema description coverage, the description does not explain any of the three parameters (limit, since, payment_signature). It adds no meaning beyond what the schema's names and defaults provide, leaving the agent without guidance on how to use them.
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 retrieves verified POTUS statement events at T+24h and older, at a price of $0.10. This specific verb+resource combination distinguishes it from sibling tools like sygnl47_events_live (real-time) and sygnl47_events_15m (fresher intervals).
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 use for historical events older than 24h due to the 'T+24h and older' clause and pricing tier mention. However, it does not explicitly state when not to use this tool or name alternative tools for fresher data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_events_liveAInspectVerified POTUS statement events with no delay applied ($2.00).
RETURNS: newest-first list of CONFIRMED observations, same schema as every other tier: verification block (live vs replay via acoustic fingerprinting, independent source count) and market block (abnormal return vs benchmark). GUARANTEED MAX STALENESS: 0 seconds. PRICE: $2.00 USDC — the top of the ladder, because recency is the only thing the price buys. NOT A PREDICTION: verified observation of a public statement and the price action that followed. Zero confirmed live outcomes to date. since: ISO-8601 lower bound on ts_utc (narrows only). limit: 1..500.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: max staleness 0 seconds, price, verification and market blocks in returns, note that it's not a prediction, and zero confirmed live outcomes. It provides rich context beyond the raw function call.
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 structured with clear sections (RETURNS, GUARANTEED, PRICE, NOT A PREDICTION) and is informative. It is slightly verbose with price and return schema details, but each sentence adds value, no waste.
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 3 parameters, no output schema, and no annotations, the description covers parameter semantics, return format, pricing, and even historical context (zero confirmed outcomes). It is sufficiently complete for accurate tool selection and invocation.
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?
Despite 0% schema description coverage, the description explains 'since: ISO-8601 lower bound on ts_utc (narrows only)' and 'limit: 1..500', adding semantic meaning. However, the 'payment_signature' parameter is not described, leaving a small gap.
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 it returns 'Verified POTUS statement events with no delay applied', using a specific verb ('returns') and resource ('events'), differentiating from siblings like sygnl47_events_1m and sygnl47_events_archive by emphasizing 'live' and 'no delay'.
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?
It explains the tool returns newest-first confirmed observations with zero staleness and a price of $2.00, implying it's for real-time use. However, it does not explicitly state when not to use it or mention specific alternatives, though contrasts with delayed tiers are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_feedsAInspectBroadcast feed buffer-depth map and source health ($0.25).
RETURNS: per live news feed, the measured connect-buffer depth — how many seconds of already-buffered audio the source dumps the instant you connect — plus transport kind and uptime observation counts. The measurement behind it found continuous Icecast radio buffers 2-5x shallower than segmented video HLS (NPR 2.7s vs Reuters 38.3s), which is a genuinely useful fact for anyone building a low-latency listening path. STATED PLAINLY: this is buffer depth, NOT standing latency. Standing latency is a different number, it requires a simulcast we have not captured, and the cross-feed correlation available today scores below its own acceptance threshold — so no per-feed lag figure is published. We would rather return a null than a confident wrong number. PRICE: $0.25 USDC. NOT A PREDICTION: infrastructure measurement only.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the tool returns buffer depth in seconds, transport kind, and uptime counts. It clarifies it does not return standing latency or predictions, and mentions pricing ($0.25). However, it is verbose and includes tangential benchmarking data that may distract.
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 front-loads the core purpose but then includes tangential details like Icecast vs HLS buffer depth comparison and additional context. While informative, it is longer than necessary for tool invocation, reducing conciseness.
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 description explains what is returned (per-feed buffer depth, transport kind, uptime counts) and what is not, compensating for the lack of output schema. However, the payment_signature parameter is not explained, leaving a minor gap in 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?
The only parameter, 'payment_signature', is not described in the input schema (0% coverage) and the description does not explain its purpose or usage. While price is mentioned, the parameter remains undefined, which is a significant gap for low 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 clearly states the tool broadcasts a 'feed buffer-depth map and source health', specifying it returns per-feed buffer depth, transport kind, and uptime counts. This distinguishes it from sibling tools like sygnl47_events and sygnl47_entities by focusing on buffer depth measurement.
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 states what the tool returns (buffer depth, not standing latency) and what it does not (per-feed lag figure, prediction). It explains when not to use it for latency and mentions the cross-feed correlation is below threshold, providing clear guidance on appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_latest_eventAInspectMost recent verified POTUS statement event, no delay ($2.00).
RETURNS: the single newest CONFIRMED observation — timestamp, entity and ticker named, a verbatim snippet capped at 180 characters, the verification block (live vs replay, how many independent feeds corroborated it, consensus confidence) and the market block (mark, benchmark, abnormal return at 1/5/15/30 minutes, instrument minus benchmark). GUARANTEED MAX STALENESS: 0 seconds of deliberate delay. Real freshness is bounded by publisher sync and reported in every response as sync.feed_age_seconds — measured, never assumed. PRICE: $2.00 USDC. Deliberately premium: this is verified, hard-to- replicate data and we would rather learn what one real buyer pays than what a hundred free riders sample. NOT A PREDICTION. This reports what was said and what happened afterwards. No edge claim, no win rate, no recommendation. If no event exists the call returns 404 and is NOT settled — you are not charged for silence.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses pricing ($2.00 USDC), freshness guarantee (0 seconds delay, measured), behavior on no event (404, no charge), and the rationale for the premium. It also explains the return structure and that it is not a prediction. Very 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 well-structured with clear sections (returns, guarantees, price, disclaimer). It front-loads the core purpose and key differentiator (no delay, cost). Every sentence adds value, and there is no redundant or extraneous content.
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 only one parameter and no output schema, the description covers purpose, behavior, freshness, cost, and return format thoroughly. The only missing piece is documentation for the payment_signature parameter, which is a notable gap for the tool's usability.
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 has one parameter (payment_signature) with no description and 0% coverage. The tool description does not mention or explain this parameter at all, leaving the agent without guidance on how to provide payment. This is a critical gap for a paid tool.
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 identifies the tool as returning the most recent verified POTUS statement event with no delay. It distinguishes from sibling tools (e.g., sygnl47_events_1m, sygnl47_events_15m) by emphasizing real-time freshness and a single confirmed observation, and by specifying that it is not a prediction.
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 the tool is for obtaining the latest verified event at a premium price, and clarifies it is not a prediction. It does not explicitly list when not to use it or compare with siblings, but the context of alternative event feeds is implied by the sibling names. Slight gap in explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_manifestAInspectFREE: SYGNL/47 service manifest — method, latency tiers, prices, inventory.
Read this before calling any paid sygnl47_* tool. Describes how events are detected and verified (live-vs-replay acoustic fingerprinting, multi-source corroboration, linguistic guards, abnormal-move attribution), the full price ladder, and the CURRENT INVENTORY stated plainly.
Inventory today is thin and we would rather you knew: 2 events, both reconstructed from archived broadcast audio of a single speech and labelled source: replay, and ZERO confirmed live outcomes. This manifest contains no event data — it is a description of the service, not a free sample. There is no free tier of the data itself, only cheaper (older) tiers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details what the manifest contains (method, detection process, price ladder, inventory), discloses that inventory is thin and events are reconstructed with zero confirmed live outcomes, and states there is no free data tier. This is highly 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 front-loads key information with a clear summary. It is mostly concise but includes some redundancy (two sentences confirming no free data tier). Still effective and well-structured.
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 manifest tool with no parameters and no output schema, the description covers the essential context: what it is, its contents, inventory status, and its relationship to paid tools. It does not explain return format but that is acceptable for a descriptive 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?
There are zero parameters, so baseline is 4. The description does not need to add parameter information since none exist. It appropriately focuses on the tool's content.
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 this tool is a FREE service manifest covering method, latency tiers, prices, and inventory. It explicitly says 'Read this before calling any paid sygnl47_* tool,' differentiating its role from sibling tools and establishing it as a prerequisite.
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 advises reading this before using paid sygnl47_* tools and clarifies it is free, providing clear context. It does not explicitly state when not to use it, but implies that for event data one should use other tools, as this contains no event data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_subscribe_archive_30dAInspectBuy a 30-day unmetered pass to the SYGNL/47 archive tier ($100.00).
RETURNS: a signed bearer token granting unmetered access to the archive tier (T+24h and older) for 30 days. The archive payload is complete, not a sample — same schema and same verification block as the live tier, only older. IMPORTANT: an archive pass does NOT authorize the live, 1m or 15m routes. Using it there returns a normal 402 with an explanation, because a pass may never widen freshness beyond the tier it was bought for. PRICE: $100.00 USDC. NOT A PREDICTION: verified observation feed, no edge claim.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: returns a signed bearer token, archive payload is complete and same schema as live, pass cannot widen freshness, and misuse yields a 402 with explanation.
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 front-loaded with the main action, has clear sections (returns, importance, price), and is generally succinct without unnecessary detail. Minor redundancy with 'NOT A PREDICTION' line.
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?
While the description covers the return value, constraints, and distinction from other tiers, it omits explanation of the payment_signature parameter and assumes default empty behavior, leaving a significant gap for a purchase 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?
The description does not mention the only parameter 'payment_signature' at all, despite 0% schema description coverage. The agent has no guidance on what to provide or how to format it.
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 explicitly states 'Buy a 30-day unmetered pass to the SYGNL/47 archive tier' with a verb and resource, and distinguishes from siblings by noting the archive pass does not authorize live, 1m, or 15m routes.
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 archive data access and clearly states the pass is not for live/fresh routes, returning a 402 if misused. However, it does not explicitly compare to other subscription tools like sygnl47_subscribe_live_30d.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_subscribe_live_24hAInspectBuy a 24-hour unmetered pass to the SYGNL/47 live tier ($50.00).
RETURNS: {token, sub_id, tier, expires_utc, max_freshness_seconds, authorized_routes}. Send the token as header X-SYGNL47-TOKEN on any authorized route and no per-call payment is charged until it expires. STORE THE TOKEN — verification is stateless by design, so we cannot reissue it. WHAT IT DOES NOT BUY: fresher data. The pass grants unmetered access to the live tier, and the server-side ts_utc cutoff applies to pass holders exactly as it does to per-call buyers. An expired token falls back to a normal 402 challenge, never to a free serve. PRICE: $50.00 USDC, versus $2.00 per live call. NOT A PREDICTION: this buys access to a verified observation feed with zero confirmed live outcomes, whose current inventory is 2 replay-sourced events.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral disclosure burden. It details the mutation (buying a pass), stateless verification, token usage, return fields, pricing, and current inventory, leaving no ambiguity.
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 well-structured with the core action first, followed by returns, caveats, pricing, and clarifications. It is appropriately front-loaded but slightly verbose with additional clarifications that could be condensed.
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 description provides detailed return fields and behavioral context. It covers pricing, token usage, fallback, and limitations. However, it lacks prerequisites or instructions for obtaining the payment signature.
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?
Only one parameter (payment_signature) with zero schema description coverage. The description does not explain its format, how to obtain it, or its significance; it only appears in the schema with a default empty string.
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 buys a 24-hour unmetered pass to the SYGNL/47 live tier for $50.00. It distinguishes from sibling subscription tools and per-call alternatives, and lists return fields.
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?
Explicitly compares to per-call pricing ($2.00 per live call), clarifies what the pass does not buy (fresher data), explains token storage and fallback behavior, and warns it is not a prediction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sygnl47_subscribe_live_30dAInspectBuy a 30-day unmetered pass to the SYGNL/47 live tier ($750.00).
Same contract as the 24-hour pass over a 30-day window: signed bearer token, unmetered access to the live tier, no widening of freshness beyond that tier, stateless verification, and a normal 402 fallback once it expires. PRICE: $750.00 USDC. NOT A PREDICTION: verified observation feed, no edge or win-rate claim, zero confirmed live outcomes to date. At this price you should read sygnl47_manifest first — it states the inventory plainly, and the inventory is currently 2 events reconstructed from archived audio.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: the contract type (signed bearer token, unmetered access), freshness constraints, stateless verification, 402 fallback on expiry, pricing, and the fact that it is a verified observation feed with no win-rate claims. This adds significant context beyond the schema.
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 relatively long and contains some redundancy (e.g., 'Same contract as the 24-hour pass over a 30-day window' could be trimmed). However, it is well-structured with line breaks for key points, and critical warnings are 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?
The description lacks information about the tool's return value or output format (no output schema). The parameter is not fully documented. While the purchase use case is covered, the agent is left guessing what happens after a successful call (e.g., token delivery, confirmation).
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?
With 0% schema description coverage, the description should explain the 'payment_signature' parameter. It mentions 'signed bearer token' in the contract description but does not explicitly link to the parameter or clarify its format or origin. The agent may infer, but it is not explicit enough.
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 action ('Buy a 30-day unmetered pass') and the resource ('SYGNL/47 live tier'). It differentiates from sibling tools like sygnl47_subscribe_live_24h and sygnl47_subscribe_archive_30d by specifying the duration and tier.
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?
Explicitly advises reading sygnl47_manifest first, providing a precondition for usage. Also notes that the tool is for purchasing and that the subscription is not a prediction, helping the agent decide 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.
sygnl47_subscription_plansAInspectFREE: prepaid-pass plans for SYGNL/47 (the subscription catalog).
x402 is per-call by design. A subscription here is a PREPAID TIME-BOXED PASS on the same rails: one payment buys unmetered access to one tier for one window and returns a signed bearer token, which you then send as X-SYGNL47-TOKEN instead of paying per call.
Lists each plan with its tier, duration, price and the exact routes it authorizes. Read this before calling any sygnl47_subscribe_* tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains the read-only nature, the prepaid pass concept, bearer token usage, and what the listing includes. Missing rate limits or auth details but adequate for a list endpoint.
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 somewhat verbose but every sentence adds value. It is well-structured, starting with the concept and ending with the listing contents.
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 specifies the fields returned (tier, duration, price, routes) and explains the authentication mechanism, making it complete for correct usage.
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?
No parameters, so schema coverage is 100%. The description adds significant meaning beyond the empty schema by explaining the subscription concept and token mechanism.
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 lists subscription plans with tier, duration, price, and authorized routes. It distinguishes from sibling subscribe tools by explicitly positioning it as a prerequisite.
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?
Explicitly instructs to read this before calling any sygnl47_subscribe_* tool, providing clear context and alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trade_preflightAInspectPre-trade decision gate for AI trading agents ($0.01).
Deterministic ALLOW / REDUCE / REQUIRE_CONFIRMATION / BLOCK with reason codes, an order-hash-bound approved size, 60s expiry, and an EIP-191-signed attestation. Composes the live regime detector, the measured execution-cost oracle, and YOUR policy (max_notional_usd, max_cost_bps, daily_loss_limit_usd, confirm_above_usd, symbol_allowlist, ...). order: {symbol, side, notional_usd, order_type}. evidence: {audit_score} from audit_backtest. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | ||
| state | No | ||
| policy | No | ||
| evidence | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behavioral traits: deterministic decisions (ALLOW/REDUCE/BLOCK), 60s expiry, signed attestation, and composition of policy/regime/cost. It does not mention side effects or data persistence, which seems appropriate for a decision-only tool.
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 somewhat long but front-loads key info (outcomes, expiry, attestation). It could be trimmed slightly, but each sentence adds value. The structure is logical.
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 explains return values (decisions, reason codes, signed attestation) but lacks detail on output format. With 5 parameters and nested objects, it covers most parameter meanings (order, evidence, policy) but not state or payment_signature. Overall adequate but not exhaustive.
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?
With 0% schema description coverage, the description adds significant value by explaining the 'order' object fields (symbol, side, notional_usd, order_type) and 'evidence' field (audit_score from audit_backtest). However, 'state' and 'payment_signature' are not elaborated.
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 as a 'Pre-trade decision gate for AI trading agents' and lists its deterministic outcomes (ALLOW, REDUCE, etc.). It distinguishes itself from sibling tools like get_pricing or audit_backtest by focusing on pre-trade authorization.
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 as a gate before trade execution but does not explicitly state when to use or avoid it over siblings like get_regime_current or estimate_execution_cost. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!