Skip to main content
Glama
Sign In

quant-backtest-escrow-auditor

by io.github.adamgraymon
OverviewDiscussionsAdmin

submit_encrypted_deliverable

[EN] Vertical 1 (Datasets): Audit encrypted CSV/JSON dataset (100% deterministic antimalware/clone scan + 30-row Vitter cryptographic blind sampling) & settle USDC or refund 100%. | [ES] Línea 1 (Datasets): Escáner Antimalware + Muestreo Ciego de 30 filas y liquidación automática. | [中文] 垂直领域1 (数据集审计): AES-256 加密 CSV/JSON 数据集反恶意软件与盲抽样审计，自动释放 USDC 或 100% 退款。

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": {
      "jobId": "<jobId>",
      "rawDatasetJsonString": "<rawDatasetJsonString>"
    },
    "name": "submit_encrypted_deliverable"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobIdYes
rawDatasetJsonStringYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real behavior: a deterministic antimalware/clone scan plus 30-row Vitter blind sampling, followed by USDC settlement or a 100% refund. It omits important traits such as whether submission is one-shot/irreversible, what happens on a failed audit, timing, cost, and who can call it.

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

Conciseness2/5

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

The same content is repeated verbatim in three languages, tripling length without adding information. The English portion is front-loaded and reasonably tight, but the overall payload is bloated and the tag prefixes add noise.

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?

There is no output schema and no annotations, yet the description does not explain the settlement/refund response, the relationship between jobId and the dataset string, or failure handling. For a tool that moves USDC and handles encrypted data, this leaves an agent unable to call it confidently.

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 description coverage is 0%, so the description had to compensate and does not: neither jobId nor rawDatasetJsonString is mentioned or explained. Worse, the description says the dataset is 'encrypted' while the parameter is named rawDatasetJsonString, which an agent must reconcile on its own.

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

Purpose4/5

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

The description names a specific verb and resource: audit an encrypted CSV/JSON dataset and settle USDC or refund. It also scopes itself to 'Vertical 1 (Datasets)', which separates it from the escrow-audit siblings. It falls short of 5 because the tool name says 'submit' while the description only describes the audit/settlement pipeline, leaving the submission act implicit.

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?

There is no when-to-use, when-not-to-use, or prerequisite guidance. The only routing signal is the 'Vertical 1 (Datasets)' label; nothing tells an agent how to choose this over audit_agent_skill_escrow or the other siblings, nor what conditions must hold before submitting.

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

All quant-backtest-escrow-auditor toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources