Skip to main content
Glama
Sign In
bca-mcp

bca-mcp

by blockchainacademics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

build_custom_indicator

Create a custom time-series indicator by combining BCA data primitives with a formula, such as coverage index divided by price change.

Instructions

Define a custom indicator formula over BCA primitives. Returns time-series. Pro tier.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "formula": "<formula>"
    },
    "name": "build_custom_indicator"
  }
}

Input Schema

NameRequiredDescriptionDefault
formulaYesFormula over data primitives, e.g. 'coverage_index(X)/price_change_7d(X)'.
targetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only mentions the return type ('Returns time-series') but does not indicate if the operation is read-only, creates persistent data, requires special permissions, or has rate limits. This leaves significant ambiguity about side effects and usage costs.

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

Conciseness4/5

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

The description is extremely concise (three clauses) and front-loaded with the most critical information. While it could benefit from slightly more detail without becoming verbose, it achieves efficiency and avoids unnecessary words.

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

Completeness2/5

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

Given the low schema coverage (50%), lack of output schema, and missing annotations, the description is insufficient. It does not elaborate on the return format beyond 'time-series', nor does it explain the 'target' parameter or provide usage examples. A more complete description is needed to compensate for the sparse structured metadata.

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

Parameters2/5

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

Schema coverage is 50%: only the 'formula' parameter has a description (with an example), while 'target' is described only by its schema (string or null, default null). The description adds an example for 'formula' but does not explain 'target' at all, leaving a gap in understanding its purpose.

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

Purpose5/5

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

The description clearly states the action: 'Define a custom indicator formula' and specifies the resource: 'over BCA primitives'. It also indicates output type ('Returns time-series') and tier ('Pro tier'). This effectively distinguishes the tool from sibling tools which are primarily getters or checks.

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

Usage Guidelines2/5

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 alternatives. The mention of 'Pro tier' implies a usage restriction, but there is no description of appropriate scenarios, prerequisites, or when not to use it. Sibling tools like 'get_coverage_index' serve different purposes, but the description does not clarify the trade-off.

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

Deploy Server

Other Tools