fia-signals-mcp
Server Details
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 2.6/5 across 8 of 8 tools scored. Lowest: 2/5.
Many tools have 'checkout' in their names and serve similar metadata-returning purposes, making it hard to distinguish. The explicit alias 'pre_trade_risk_batch_checkout' for 'token_safety_batch_checkout' adds direct ambiguity. Descriptions help but overlap remains, especially among the ACP checkout tools.
All names use snake_case, but the structure varies: some start with a domain (contract_risk, token_safety), others with a verb or action (guarded_swap_execute_dry_run_checkout is overly verbose). The convention is not uniform (e.g., 'checkout' vs 'preview' vs 'acp_checkout'), making patterns hard to predict.
8 tools is a reasonable count for a specialized risk-signals server covering contract risk, token safety, and swaps. The presence of a redundant alias (pre_trade_risk_batch_checkout) slightly inflates the count, but overall the scope is well-balanced.
The set covers preview, batch checkout, and individual checkout for different risk domains, but lacks tools for actual execution or payment finalization. Given the stated focus on metadata and previews, the surface is mostly complete, though an execution trigger or status check would fill obvious gaps.
Available Tools
8 toolscontract_risk_batch_checkoutCInspect
Return paid x402 contract-risk batch endpoint, 0.50 USDC bundled risk-pack upsell, and ACP contract_risk checkout metadata without making a payment.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_addresses | Yes | Comma-separated EVM token addresses, maximum 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool 'without making a payment', indicating a no-cost operation, but it does not disclose what happens on failure, the structure of the returned metadata, or any side effects. The description lacks important 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 a single sentence that is dense and confusing, trying to pack multiple concepts ('paid x402 endpoint', '0.50 USDC bundled risk-pack upsell', 'ACP contract_risk checkout metadata'). It is not front-loaded concisely; rather, it obscures the core purpose.
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 moderate complexity (2 parameters, both partially described), the description should explain what the tool returns. It mentions 'metadata' but does not specify its content or format. The description is incomplete for an agent to fully understand the tool's 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?
The description adds no additional meaning to the parameters beyond the schema. The schema already describes 'token_addresses' as comma-separated with a max of 5, and 'chain' has only a default. The description does not clarify usage of these parameters or their relation to the tool's function.
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 attempts to state the tool's function but is vague: 'Return paid x402 contract-risk batch endpoint, 0.50 USDC bundled risk-pack upsell, and ACP contract_risk checkout metadata without making a payment.' It mentions returning metadata without payment, which gives some purpose, but 'paid x402 endpoint' and '0.50 USDC bundled risk-pack upsell' are unclear and do not clearly differentiate from 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 does not provide explicit guidance on when to use this tool versus alternatives. It implies that this tool does not require a payment, but there is no mention of specific contexts or exclusions. Sibling tools are listed but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_risk_previewCInspect
Free live preview for Fia's paid contract_risk/token-safety checkout path.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_address | Yes | EVM token contract address to screen before a swap. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Free live preview' without disclosing behavioral traits such as what happens on failure, rate limits, or the extent of the preview. The agent is left uninformed about tool behavior.
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 vague sentence that fails to provide adequate information. It is under-specified rather than concise, lacking key details about functionality and usage.
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 should explain what the preview returns (e.g., risk scores, warnings). It does not, leaving the agent uncertain about the tool's output and 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 50%: token_address has a description, but chain lacks any description beyond a default. The description does not add meaning to either parameter, leaving the chain parameter 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 states 'Free live preview for Fia's paid contract_risk/token-safety checkout path,' which is vague. It does not explicitly state what the tool does (e.g., screens a token for risk) or distinguish it from the sibling tool token_safety_batch_checkout.
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 is provided on when to use this tool versus the paid path or the sibling. There is no mention of prerequisites, limitations, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
guarded_swap_execute_dry_run_checkoutCInspect
Return the free Virtuals ACP direct-buy job-create handoff packet for guarded_swap_execute_dry_run before a Base swap. Metadata only; ACP payment/job creation is buyer-controlled.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| amount | No | ||
| to_token | No | WETH | |
| from_token | No | USDC | |
| risk_tolerance | No | medium | |
| max_slippage_bps | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'Metadata only' and 'ACP payment/job creation is buyer-controlled,' implying the tool is non-mutative and does not execute the swap. However, with no annotations provided, it does not fully disclose other behavioral traits like rate limits, authentication requirements, or whether data is returned immediately.
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 conveys key information, but it is dense with domain-specific terms ('Virtuals ACP direct-buy job-create handoff packet'). It could be slightly more readable while maintaining 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?
With six parameters, no output schema, and no annotations, the description is far too minimal. It does not explain return values, parameter constraints, or how the handoff packet is used, making it incomplete for an agent to use effectively.
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 provides no explanation of the six parameters. The defaults (e.g., amount=25, to_token='WETH') are not contextualized, leaving the agent without guidance on how to set these values appropriately.
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 it returns a handoff packet for a dry run before a Base swap, which indicates the tool's purpose. However, it uses specialized jargon ('ACP direct-buy job-create handoff packet') that may not be immediately clear to an AI agent, and it does not distinguish clearly from 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?
No explicit guidance on when to use this tool versus alternatives. It mentions 'before a Base swap' but provides no exclusion criteria or context, such as when not to use or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
offer_angle_ping_acp_checkoutCInspect
Return the free Virtuals ACP direct-buy job-create handoff packet for offer_angle_ping. Metadata only; ACP payment/job creation is buyer-controlled.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | first external buyer | |
| symptom | No | listed but no paid jobs | |
| target_buyer | No | buyer agents | |
| current_offer | No | ||
| current_price | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The disclosure that it returns metadata only and that ACP payment/job creation is buyer-controlled provides some transparency. However, with no annotations to fall back on, it lacks details on side effects, permissions, or rate limits.
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 brief at two sentences and front-loads the core purpose. It could be slightly more structured but is efficient overall.
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 5 undocumented parameters and no output schema, the description is too sparse to fully inform an agent. It needs parameter explanations and a clearer definition of the 'handoff packet'.
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 five parameters (goal, symptom, target_buyer, current_offer, current_price). Agents must infer meaning from names alone, which is insufficient.
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 a 'handoff packet' for offer_angle_ping ACP checkout and specifies it's 'metadata only.' This distinguishes it from sibling tools that deal with contract risk or token safety, though it could be more explicit about what the packet contains.
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 implies it's for offer_angle_ping scenarios but doesn't state conditions or exclusions relative to sibling checkout tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pre_trade_risk_batch_checkoutCInspect
Alias for token_safety_batch_checkout using the /pre-trade-risk/batch buyer-facing path. Metadata only; no payment is made.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_addresses | Yes | Comma-separated EVM token addresses, maximum 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It reveals read-only nature ('metadata only') but omits side effects, required permissions, or error conditions.
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 short sentences with no fluff, efficient but could benefit from integrating purpose and behavior.
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 sufficient detail for a 2-parameter tool with no output schema and no annotations. Does not describe return value or how it compares to sibling tools.
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 has 50% coverage (only token_addresses described). Description adds no parameter information beyond schema, missing chance to clarify chain default or address format.
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 it's an alias and 'metadata only; no payment is made', but doesn't specify the core function (risk checking) or distinguish from similar tools like token_safety_batch_checkout.
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 to use this vs the original alias or other batch checkout siblings. The description only mentions path difference without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_safety_batch_checkoutCInspect
Return paid x402 endpoint, 0.50 USDC bundled risk-pack upsell, and ACP contract_risk checkout metadata without making a payment.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_addresses | Yes | Comma-separated EVM token addresses, maximum 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only discloses 'without making a payment'. Missing side effects, safety, idempotency, or auth requirements. For a read-like operation, more context is needed.
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?
Single concise sentence, but densely packed with domain-specific terms. Could benefit from clearer structure or front-loading key info.
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; description lists three return items but in an unstructured way. Incomplete for a tool with 2 parameters and no output schema.
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 50% (chain parameter has no description). The description adds no additional meaning to token_addresses or chain, missing an opportunity to clarify usage.
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 it returns certain metadata/endpoints, but lacks a clear verb and resource. It mentions 'without making a payment' which hints at a dry-run function, but the jargon is heavy and doesn't clearly differentiate from siblings.
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?
Implicitly suggests using when you want checkout metadata without payment, but no when-not or explicit alternatives provided. Sibling tools exist but aren't referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_safety_check_acp_checkoutAInspect
Return the free Virtuals ACP direct-buy job-create handoff packet for token_safety_check before a token swap. Metadata only; ACP payment/job creation is buyer-controlled.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_address | Yes | EVM token contract address to screen before a swap. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns metadata only and that ACP payment/job creation is buyer-controlled, which is critical for safe invocation. It does not cover auth or rate limits, but the behavioral implication (read-only, non-destructive) is clear.
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, 20 words, no redundant phrases. The key action and constraint are front-loaded. Every word 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 purpose and what it returns (metadata packet), but does not detail the packet's structure or how to use the result. Given no output schema, the agent lacks clues about the return format. Chain default and options are also missing.
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 50% (only token_address has description). The tool description does not add meaning to parameters beyond the schema: 'chain' is left undefined, and token_address is only implicitly linked to the safety check. The description fails to compensate for the missing parameter documentation.
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 returns a 'free Virtuals ACP direct-buy job-create handoff packet' for token safety checks before a swap. It specifies the resource and action, and distinguishes from sibling tools like token_safety_batch_checkout and contract_risk_* tools by focusing on a single token handoff.
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 'before a token swap' but does not explicitly compare with alternatives such as token_safety_batch_checkout or guarded_swap_execute_dry_run_checkout. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_safety_free_previewBInspect
Rate-limited no-spend token-safety preview plus paid /token-safety x402 upgrade metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| token_address | Yes | EVM token contract address to screen before a swap. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses rate-limiting and no-spend behavior, and hints at a paid upgrade. However, it does not describe what safety checks are performed, the response format, or any side effects, leaving behavioral aspects partially opaque.
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 conveys key elements concisely. It is slightly dense but not overly long. Could be improved by structuring information into separate points for clarity.
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 lack of output schema and annotations, the description provides partial context: it's a free preview, rate-limited, with upgrade metadata. However, it omits details on the actual checks, output format, and how it relates to sibling tools, leaving some gaps for effective use.
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 covers 50% of parameters with descriptions (only token_address has a description). The tool description adds no further parameter semantics; it does not explain chain or token_address beyond what is in the schema. Thus, it does not compensate for the 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 states it is a token safety preview that is rate-limited and no-spend, with upgrade metadata. This clearly identifies the tool's function, but it does not explicitly differentiate from sibling tools like token_safety_batch_checkout or token_safety_check_acp_checkout, though the 'preview' and 'no-spend' hints suggest a distinct use case.
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. It implies use for free quick checks, but does not state when not to use it or mention sibling tools, leaving the agent to infer context without clear direction.
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.
Discussions
No comments yet. Be the first to start the discussion!