BlindOracle MCP server gives agents verifiable commerce, ERC-8004 identity, x402/USDC payments, market analysis, trading signals, job management, alerting, and security auditing.
Portable identity & payments: use ERC-8004 passports, x402 payment challenges, and Lightning invoices for paid oracle/prediction/arbitrage/comprehensive-report jobs.
Market intelligence: analyze all prediction markets, fetch Chainlink price feeds, get detailed market data, detect arbitrage opportunities, and retrieve pre-computed belief velocity.
Trading & signals: generate trading signals for assets, fetch historical signal accuracy, and execute cross-market arbitrage trades (with dry-run and risk limits).
Job lifecycle: submit paid jobs, create job invoices, check job status, retrieve results, and list available job types.
Alert management: configure alert thresholds/channels/quiet hours, add price alerts, view alert history, and start/stop monitoring.
System insight & control: view system metrics and compute advantage, initialize DITD lifecycle agents, and run comprehensive security audits covering contracts, APIs, agents, and infrastructure.
Trust layer for the x402 agent economy. ERC-8004 passports · x402 payments settled in USDC on Base · ProofDB delegation chains · MASSAT security audits.
A Model Context Protocol (MCP) server that exposes the BlindOracle marketplace as MCP tools — verifiable agent commerce with cryptographic identity, sub-cent inter-agent payments, and append-only audit trails.
Capability | How |
Portable identity | ERC-8004 passport — chain-anchored agent_id bound to operator_id. Free to mint. Replaces OAuth for credential rotation. |
Payment | x402 HTTP 402 challenge, settled in USDC on Base. Sub-cent per call. No merchant-of-record. |
Audit | ProofDB — 15 cryptographic proof kinds incl. ProofOfDelegation (kind 30014). HMAC-SHA256, append-only, 18+ month queryable. MiCA/SOC2-ready. |
Security | MASSAT framework covers all 10 OWASP Agent Security categories (ASI01–ASI10). Findings published publicly — transparency is the differentiator. |
Related MCP server: AgentStamp
# Install
git clone https://github.com/craigmbrown/blindoracle-mcp.git
cd blindoracle-mcp
pip install -e .
# Run the MCP server
python main.pyOr add to your Claude Desktop / Cursor / continue.dev MCP config:
{
"mcpServers": {
"blindoracle": {
"command": "python",
"args": ["/path/to/blindoracle-mcp/main.py"]
}
}
}main.py MCP server entry point (FastMCP)
pyproject.toml Package metadata + dependencies
core/ Core MCP tooling + BLP framework
sub_agents/ Design/Implementation/Testing/Deployment/Operations agents
alerting/ Alert routing + email/whatsapp channels (env-var configured)
trading_signals/ Signal generator + store
contracts/ Solidity smart contracts (PrivateClaimVerifier, AgentRegistry, etc.)The server reads its operator-specific configuration from environment variables. No hard-coded secrets. Common variables:
Variable | Purpose | Default |
| Where alerts route to |
|
| P0 alert SMS-style channel | (none) |
| Outbound email From: address |
|
| Your ERC-8004 passport ID | (mint free at the BlindOracle marketplace) |
# See the treasury's live solvency status on Base — the marketplace IS running
curl https://api.craigmbrown.com/a2a/treasury/balances
# Read the agent-services manifest (live services)
curl https://craigmbrown.com/.well-known/agent-services.json | jq '.services | length'
# See the public MCP server card
curl https://craigmbrown.com/.well-known/mcp/server-card.jsonHow BlindOracle Works — architecture + settlement pipeline + privacy layer + payment rails
API Reference — services with schemas
Solo FAQ — 10 owner questions for 1–5 agent fleets
Team FAQ — 5–50 agent fleets
Marketplace-Operator FAQ — 50+ agents, MiCA/SOC2/SLA
ERC-8004 migration guide — 3-phase OAuth → ERC-8004 path
Repo | What |
Python client SDK for calling the BlindOracle marketplace | |
MASSAT security audit toolkit (OWASP ASI01-10) — used to audit MCP servers | |
Curated reading list for the ERC-8004 standard |
Live treasury on Base at 0x5E70…4EB9 — solvency status verifiable via curl https://api.craigmbrown.com/a2a/treasury/balances
Settlement rail: x402/USDC on Base — the only customer settlement rail
Services live at /.well-known/agent-services.json
42+ agent fleet in production, BLP framework 60/60 property coverage
MASSAT self-audit findings published publicly (OWASP ASI01–ASI10)
/a2a/* endpoints live at api.craigmbrown.com/a2a/
Apache 2.0 — see LICENSE. Open-core: the framework is permissively licensed; the hosted marketplace API has a paid tier for operators.
PRs welcome. Issues tracker at github.com/craigmbrown/blindoracle-docs/issues.
For security disclosures: please email security@craigmbrown.com (do NOT file a public issue). MASSAT audit findings welcome via the same channel.
Author: Craig Brown · craigmbrown.com · @cmb24k2
Add a price alert for an asset.
REQ-ALERT-006: MCP tool exposure
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| direction | No | above | |
| target_price | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as side effects, idempotency, rate limits, or authorization needs. For a mutation tool, this leaves significant gaps for the agent.
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 short but includes an unnecessary line ('REQ-ALERT-006: MCP tool exposure') that adds no value. It is mostly concise but wastes one sentence on irrelevant metadata.
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 mutation nature and 3 parameters, the description is incomplete. It fails to mention return value, success confirmation, or any side effects. Although an output schema exists (not shown), the description should provide enough context for safe 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?
Schema coverage is 0% (no parameter descriptions). The description adds no explanation beyond what the schema provides. While 'asset' and 'target_price' are self-explanatory, 'direction' (default 'above') is not clarified, leaving ambiguity about acceptable values.
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 ('Add a price alert for an asset.') with a specific verb and resource. It distinguishes from siblings like get_alert_history and configure_alerts, though not explicitly. A higher score would require explicit sibling differentiation.
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 alternatives (e.g., configure_alerts, start_alert_monitoring). There is no mention of prerequisites, context, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze all prediction markets with oracle verification @requirement: REQ-AGG-001 - Unified market aggregation @requirement: REQ-BLP-001 - Alignment tracking Properties: Alignment(+0.5), Self-Improvement(+0.3)
| Name | Required | Description | Default |
|---|---|---|---|
| find_arbitrage | No | ||
| include_kalshi | No | ||
| include_polymarket | No | ||
| include_chainlink_verification | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only mentions 'analyze' and 'oracle verification' without explaining side effects, resource usage, or what happens during analysis. The cryptic properties (Alignment, Self-Improvement) add confusion.
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 very short but includes irrelevant requirement tags and property lines that clutter the core message. It could be more structured by separating the purpose from metadata.
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 having an output schema and multiple sibling tools, the description fails to explain the output format, integration with other tools, or how optional parameters affect behavior. It feels incomplete for a complex analysis 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 input schema has 4 optional parameters but the description provides no explanation of them. With 0% schema coverage, the description should compensate but does not even mention parameters, leaving agents to infer from parameter names alone.
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 analyzes all prediction markets with oracle verification, distinguishing it from sibling tools that focus on individual markets or trading. However, it does not explicitly differentiate from tools like submit_comprehensive_report.
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 alternatives such as get_market_details or submit_oracle_job. The description lacks context about prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check status of submitted job @requirement: REQ-MCP-006 - Job status tracking @requirement: REQ-AUTH-002 - Job token validation Properties: Durability(+0.4), Alignment(+0.2)
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| job_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions requirements and 'Durability'/'Alignment' properties, but these are opaque and do not clarify behavior like whether the tool is read-only, what side effects occur, or what the response contains.
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 short but includes extraneous lines like '@requirement' and 'Properties' that are not helpful for tool selection or invocation. These could be removed for conciseness without losing 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 tool has an output schema but the description fails to explain what 'status' means or what the output contains, the description is incomplete. It does not cover the full scope of information needed for an agent to correctly interpret 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?
Schema description coverage is 0%, meaning the description adds no meaning to parameters beyond the schema. The description does not explain what 'job_id' or 'job_token' represent or how they should be used, leaving the agent to rely solely on the schema.
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: 'Check status of submitted job'. It uses a specific verb 'check' and resource 'job status', but does not differentiate from sibling tools like 'get_job_result', which might also provide status information.
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 provides no guidance on when to use this tool versus alternatives such as 'get_job_result' or 'submit_arbitrage_job'. There is no indication of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure alert settings.
REQ-ALERT-006: MCP tool exposure
| Name | Required | Description | Default |
|---|---|---|---|
| channels | No | ||
| quiet_hours | No | ||
| arbitrage_threshold | No | ||
| probability_threshold | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description still fails to disclose critical behavior. Does not indicate if settings are overwritten, if changes are reversible, or if special permissions are required.
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 short but lacks structure; it does not front-load key info. The reference to 'REQ-ALERT-006' is irrelevant to an AI agent.
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 4 parameters and no schema description coverage, the description is grossly incomplete. It fails to provide essential context 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?
Schema coverage is 0%, yet description adds no meaning to parameters like 'channels', 'quiet_hours', 'arbitrage_threshold', or 'probability_threshold'. Without schema documentation, the agent is left guessing.
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 'Configure alert settings' states a verb and resource, but lacks specificity. It does not distinguish from sibling tools like 'add_price_alert' or 'get_alert_history', which also deal with alerts.
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 tool versus alternatives like 'add_price_alert' or 'start_alert_monitoring'. 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.
Create Lightning invoice for job payment @requirement: REQ-MCP-005 - Lightning payment integration @requirement: REQ-PAY-003 - Invoice creation Properties: Autonomy(+0.6), Durability(+0.3)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | ||
| job_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as side effects, security implications, or destructive potential. It simply states the action.
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 very short but includes extraneous text like @requirement tags and properties that do not aid the agent. It sacrifices clarity for brevity.
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 has 2 required parameters with no descriptions, a JSON schema with nested objects, and no behavioral annotations, the description is incomplete. It fails to provide enough context for an agent to use it correctly.
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% with no descriptions for the two parameters. The description does not explain what job_type values are valid or what params should contain. This is insufficient 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 states the purpose clearly: 'Create Lightning invoice for job payment'. It specifies a verb and resource, but does not differentiate from sibling tools like check_job_status or list_job_types.
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 tool vs alternatives. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute cross-market arbitrage trade @requirement: REQ-ARB-001 - Cross-market arbitrage Properties: Autonomy(+0.6), Self-Organization(+0.4)
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| max_size | No | ||
| opportunity | Yes | ||
| min_profit_threshold | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes cryptic metadata about autonomy and self-organization. It does not disclose whether the trade actually modifies state, requires permissions, or has side effects. The behavioral impact is unclear.
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 very short but includes extraneous content like '@requirement: REQ-ARB-001' and property values that do not clarify usage. It is not optimally structured and wastes space on non-functional metadata.
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 complexity of an arbitrage trade with multiple parameters and an output schema, the description omits critical information such as return values, risk implications, and invocation constraints. It is insufficient for correct tool 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 input schema has 0% description coverage, and the tool description does not explain any parameters (e.g., 'opportunity', 'dry_run', 'max_size', 'min_profit_threshold'). The agent gains no understanding of how to populate the schema.
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 'Execute cross-market arbitrage trade' which is a specific verb+resource combination. However, it does not distinguish from the sibling tool 'submit_arbitrage_job', leaving ambiguity about when to use this tool.
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 alternatives like 'submit_arbitrage_job' or 'get_trading_signals'. The description lacks context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent alert history.
REQ-ALERT-006: MCP tool exposure
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| event_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, side effects, permissions, or rate limits. The tool name implies reading, but this is not explicitly stated.
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 short (one line plus a noise requirement tag), but it under-specifies crucial information. It is not concise in a helpful sense; it lacks necessary 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?
Given that there are two optional parameters and no enums, the description is insufficient. No context on ordering, time range, or valid event_type values. Output schema exists but is not referenced in the description.
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% (no descriptions in schema) and the description does not mention any parameters. The meaning of 'limit' and 'event_type' is left unexplained, requiring the agent to infer from defaults.
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 'Get recent alert history' clearly identifies the action (get) and resource (alert history). It distinguishes from sibling tools like add_price_alert (create) and configure_alerts (configure), though 'recent' is slightly vague.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pre-computed belief velocity data for prediction markets. Returns top movers (markets with fastest probability change) filtered by topic and time window. No LLM call — reads from data/belief_changes.jsonl (pure math output).
Args: topic: Optional keyword filter (e.g. "ETH", "SEC", "ETF"). Empty = all markets. lookback_minutes: How far back to look for velocity data (default 60 min). limit: Max number of markets to return (default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | No | ||
| lookback_minutes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states 'No LLM call' and 'reads from data/belief_changes.jsonl (pure math output)', fully disclosing the data source and non-generative nature. This provides complete transparency for a read-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?
Description is front-loaded with purpose and efficiently explains key behavioral trait (no LLM) in one line. The Args section is structured and clear. Could trim minor redundancy, but overall each sentence earns its place.
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 all parameters optional and an output schema (implied), the description covers all needed context: data source, filtering, ordering (top movers), performance note, and parameter details. Complete for a data retrieval 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?
Despite 0% schema description coverage, the description includes an 'Args' section that clearly explains each parameter's purpose and default values, adding meaning beyond the schema's type and default fields. This fully compensates for the lack of schema descriptions.
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 it gets pre-computed belief velocity data for prediction markets, specifies it returns top movers filtered by topic and time window, and distinguishes itself by noting it reads from a local file with no LLM call. This provides a specific verb+resource and context that separates it from sibling tools like get_market_details or get_trading_signals.
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?
Implied usage: fast, math-based data with no LLM call. But lacks explicit guidance on when to use this vs alternatives (e.g., get_trading_signals) or when not to use it. No exclusions or alternative suggestions, making it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Chainlink oracle price feed data @requirement: REQ-CHAIN-001 - Price feed aggregation Properties: Alignment(+0.3), Autonomy(+0.2)
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | ethereum | |
| asset_pair | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It only says 'Get ... data', implying read-only but not explicitly stating read-only or any side effects. The added 'Properties' line is not standard behavioral information and may confuse.
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 short but includes non-standard metadata that is not helpful for the agent. It is under-specified, sacrificing completeness for brevity.
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 parameter descriptions and no behavioral context, the description is incomplete despite having an output schema. It does not provide enough information for correct 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?
The input schema has 0% description coverage, meaning no parameter descriptions. The tool description adds no meaning to the parameters (e.g., what 'asset_pair' format, what 'network' options). This fails to help the agent with parameter 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 'Get Chainlink oracle price feed data', which clearly identifies the action (get) and resource (price feed data). It distinguishes from siblings as no other tool is specifically for Chainlink oracle data. However, the inclusion of irrelevant metadata ('@requirement' and 'Properties') slightly detracts from clarity.
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 usage guidelines are provided. The description does not explain when to use this tool versus alternatives, nor does it give any context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve completed job result @requirement: REQ-MCP-007 - Result retrieval @requirement: REQ-AUTH-002 - Job token validation Properties: Durability(+0.5), Self-Organization(+0.2)
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| job_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'retrieve' implying read-only, and includes requirement tags (REQ-MCP-007, REQ-AUTH-002) and cryptic properties (Durability, Self-Organization) that add no behavioral clarity. It does not disclose error handling, authorization specifics, or side effects.
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 short but includes extraneous metadata tags (requirements, properties) that are not useful for an agent. The core sentence is front-loaded and clear, but the technical annotations reduce conciseness and may confuse.
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?
An output schema exists but its content is not described. The description omits what the result contains (e.g., fields, format), error scenarios, or success conditions. For a result retrieval tool, this context is critical and 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 description coverage is 0%, and the description adds no meaning to the parameters job_id or job_token. The requirement tag hints at job token validation but does not explain its role. The description fails to clarify parameter purpose or constraints beyond the schema.
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 completed job result, which is a specific verb+resource. It distinguishes from siblings like check_job_status (status vs result) and submit_* jobs (creation vs retrieval). However, it does not explicitly address what happens if the job is not completed or fails, slightly limiting clarity.
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 tool versus alternatives. Sibling check_job_status exists for status checks, but no mention that get_job_result should be called only after completion. No when-not-to-use or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific market @requirement: REQ-MARKET-002 - Market data normalization
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | kalshi | |
| market_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose any behavioral traits such as authentication requirements, rate limits, or error handling. The requirement tag adds no behavioral context for an AI agent.
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 followed by an irrelevant requirement tag. While conciseness is valued, the description omits essential information, making it under-specified rather than concise.
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 annotations, two parameters, and an existing output schema, the description fails to provide complete context. It does not describe the output format or any important behavioral details, leaving the agent with insufficient information.
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%, meaning the description adds no meaning beyond parameter names and types. The description does not mention the platform default or the required market_id, nor does it explain their formats or constraints.
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 the tool retrieves detailed info about a specific market. The verb 'Get' and resource 'detailed information about a specific market' are specific. Among siblings, it is distinct from other getters like get_alert_history or get_system_metrics, but no explicit differentiation is provided.
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 when-to-use or when-not-to-use guidance is provided. There is no mention of alternatives or context for using this tool over siblings like get_chainlink_price_feed or get_trading_signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical signal accuracy metrics from SQLite store.
REQ-SIGNALS-005b: Returns real accuracy data (not "not_available"). BLP-031: Self-Improvement — enables strategy tuning based on outcomes.
Args: days: Rolling window in days for accuracy calculation (default 30).
Returns: Dict with overall accuracy, per-asset and per-signal-type breakdowns, and total signal counts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Returns real accuracy data (not "not_available")', assuring data quality. Implies read-only operation. Could explicitly state read-only nature, but sufficient.
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 concise with clear Args and Returns sections. Includes requirement IDs that may be extraneous for an AI agent. Still well-structured and efficient.
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?
Output schema exists (context signals), so description needn't detail return values thoroughly. It provides a high-level overview of return content. Lacks error handling info, but acceptable for a simple tool with one parameter.
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%, but description adds: 'days: Rolling window in days for accuracy calculation (default 30).' This explains the parameter's purpose and default value, fully compensating for schema lacking description.
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?
Clearly states 'Get historical signal accuracy metrics from SQLite store', specifying verb, resource, and data source. Distinguishes from sibling tool 'get_trading_signals' which likely returns current signals, not accuracy metrics.
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?
Mentions 'Self-Improvement — enables strategy tuning based on outcomes', indicating when to use. Does not explicitly state when not to use or alternatives, but context from sibling list makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current system metrics and compute advantage @requirement: REQ-CA-001 - Compute advantage calculation @requirement: REQ-BLP-001 through REQ-BLP-006 - All property tracking
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the operation is read-only, any required permissions, or what 'compute advantage' entails. The agent is left guessing about side effects and constraints.
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 short but includes unnecessary requirement tags that do not help an agent decide invocation. It could be more focused on what the tool returns and how 'advantage' is computed.
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 having an output schema (which is not shown), the description lacks detail on what system metrics are included and what 'advantage' means. For a tool with no parameters, the description should explain output semantics to guide 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?
There are no parameters in the schema, so the baseline is 4. The description adds no parameter information, but the requirement tags are extraneous. Since schema coverage is 100% (no params), no further detail 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 states the tool gets system metrics and computes advantage, adding a bit beyond the name. However, 'system metrics' and 'advantage' are vague, and the tool is not clearly distinguished from siblings like get_belief_velocity or get_signal_accuracy.
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 tool versus the many siblings, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate trading signals for specified assets.
Args: assets: List of assets to analyze (default: BTC, ETH) include_prediction_markets: Include prediction market momentum min_confidence: Minimum confidence threshold (0-100)
Returns: Dict containing signals, metadata, and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| assets | No | ||
| min_confidence | No | ||
| include_prediction_markets | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits fully. It only describes a generic 'generate' action without indicating side effects, safety, or performance implications (e.g., computational cost, data source freshness).
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 follows a clear docstring pattern (summary, Args, Returns) with no extraneous text. However, it could be slightly more concise by omitting the Returns section if the output schema is rich, but it remains efficient.
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 basics but lacks details on error handling, rate limits, or prerequisites. The return format is vague ('Dict containing signals, metadata, and recommendations'), though an output schema may compensate. Usage guidelines are 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?
The description provides default values and contextual meaning for all three parameters (assets default to BTC/ETH, min_confidence range 0-100, include_prediction_markets enables momentum). This adds significant value beyond the schema's bare titles and types.
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 'Generate trading signals for specified assets', which is a specific verb+resource combination. It distinguishes from siblings like get_signal_accuracy or analyze_all_markets by focusing on signal generation.
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 tool versus alternatives. Sibling tools like get_signal_accuracy or execute_arbitrage_trade have related but distinct purposes, but no exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize DITD lifecycle agents @requirement: REQ-AGENT-001 through REQ-AGENT-005 - All DITD agents
| Name | Required | Description | Default |
|---|---|---|---|
| phases | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only says 'Initialize DITD lifecycle agents' without mentioning side effects, permissions, or what initialization entails (e.g., are existing agents affected?).
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 very short (one line), which is concise, but it lacks structure and omits critical details. A concise description should still cover key aspects.
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 there is an output schema and only one optional parameter, the description could be fairly complete if it explained initialization behavior. However, it fails to provide sufficient contextual details about the tool's function and prerequisites.
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 single parameter 'phases' is not described in the description, and the schema has 0% description coverage. The default value provides some guidance, but the meaning of phases (e.g., allowed values, order) is missing.
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 'Initialize DITD lifecycle agents', which is a clear verb+resource combination. However, it does not distinguish from siblings or explain what DITD refers to, but the core action is clear.
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 alternatives, or when not to use it. The description lacks any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available job types and pricing @requirement: REQ-MCP-008 - Job type discovery Properties: Alignment(+0.3), Autonomy(+0.2)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for disclosing behavior. It merely restates the tool's purpose and adds cryptic properties (Alignment, Autonomy) that are not explained. No side effects, authentication requirements, or rate limits are mentioned.
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 very short and front-loaded with the core purpose. However, the requirement tag and properties line add extraneous information that may not be helpful for an AI agent.
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 parameters and an output schema exists, the description could still benefit from more context about what job types are included or how pricing is structured. It is adequate but minimal.
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 tool has no parameters, so the description does not need to add parameter semantics. Baseline of 4 is appropriate as schema coverage is 100% and no parameter info is required.
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 available job types and pricing. The verb 'list' and resource 'job types' are specific, with added detail on pricing. It distinguishes from sibling tools, which are primarily submission and analysis 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 is provided on when to use this tool versus alternatives. The requirement tag does not convey usage context or exclusions. The agent receives no direction on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conduct a comprehensive security audit of the entire BlindOracle system.
Covers smart contracts, API endpoints, agent code, infrastructure, privacy mechanisms, and overall architecture. Returns a detailed report with severity levels, findings, recommendations, and potential exploits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behaviors. It does not mention read-only nature, side effects, rate limits, permissions, or performance impact (e.g., potential long runtime), leaving behavioral gaps.
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 concise and front-loaded, stating the main action first, then listing coverage areas, and ending with output details. Every sentence adds value, with 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 an output schema exists, the description appropriately summarizes return values (severity levels, findings, etc.). It covers the tool's purpose, scope, and output adequately, though permissions or runtime estimates are 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?
There are zero parameters, and schema coverage is 100%. The description adds no parameter info, which is acceptable as no parameters exist. Baseline is 3 due to high coverage, but the absence of parameters allows a higher score for clarity.
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 conducts a comprehensive security audit of the entire BlindOracle system, listing specific components (smart contracts, API endpoints, etc.). It returns a detailed report, which distinguishes it from sibling tools like analyze_all_markets or get_system_metrics.
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 comprehensive security auditing but lacks explicit guidance on when to use versus alternatives, prerequisites, or exclusions. No when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the alert monitoring system.
REQ-ALERT-006: MCP tool exposure
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'start the system'. Does not disclose if starting is idempotent, requires prior configuration, or what side effects occur (e.g., begins polling, activates rules). Very 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?
Single sentence is concise, but includes non-functional noise 'REQ-ALERT-006: MCP tool exposure' that provides no agent value. Could be trimmed to just the functional part.
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 zero parameters and no annotations, the description remains incomplete: no mention of return value, behavior when already running, error conditions, or linkage to other tools like 'stop_alert_monitoring'. Fails to provide adequate context for agent 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?
No parameters, logline: baseline 4 per rules. Description adds no parameter meaning but none needed. However, it fails to compensate for missing schema richness.
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 'Start the alert monitoring system' – a clear verb and resource, but does not differentiate from siblings like 'stop_alert_monitoring' or 'configure_alerts'. Minimum viable clarity without distinctiveness.
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 tool versus alternatives like 'configure_alerts' or 'get_alert_history'. No prerequisites, exclusions, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the alert monitoring system.
REQ-ALERT-006: MCP tool exposure G3 fix: expose stop capability to complement start_alert_monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether stopping is reversible, what happens to ongoing alerts, or required permissions.
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 relevant description is one sentence, which is concise. However, it includes extraneous lines about requirement IDs that do not help an agent.
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 parameters and an output schema (assumed to provide return info), the description is minimal but adequate for a simple stop action. It could mention that stopping may affect ongoing alert monitoring.
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?
Zero parameters exist, so schema coverage is 100%. The description adds no parameter info, but baseline for 0 params is 4.
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 stops the alert monitoring system, using a specific verb and resource. It distinguishes itself from its sibling 'start_alert_monitoring' which performs the complementary action.
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 or when not to use. The usage is implied as the counterpart to start_alert_monitoring, but no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit Market Arbitrage job @requirement: REQ-MCP-003 - Arbitrage opportunity detection @requirement: REQ-PAY-001 - Payment verification Properties: Self-Improvement(+0.5), Self-Organization(+0.3)
| Name | Required | Description | Default |
|---|---|---|---|
| pairs | Yes | ||
| exchanges | No | ||
| min_spread | No | ||
| payment_proof | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose any behavioral traits such as side effects, permissions, or safety. Contains irrelevant lines (Self-Improvement, Self-Organization) that do not aid transparency.
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 short but includes non-standard requirement and property lines that are likely noise. Front-loaded with a functional statement, but extra lines waste space without conveying useful 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?
For a job submission tool with 4 parameters and an output schema, the description provides almost no context. Does not mention what the job does, how results are obtained (hint: get_job_result sibling), or schema of output.
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 description does not explain any of the 4 parameters (pairs, exchanges, min_spread, payment_proof). The description adds no value beyond the schema structure.
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?
States 'Submit Market Arbitrage job', giving a verb and resource, but lacks specificity—does not clarify if this triggers detection or execution. Sibling execute_arbitrage_trade suggests it's for detection, but not 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 guidance on when to use this tool over siblings like submit_oracle_job or execute_arbitrage_trade. No context for selecting this alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit Comprehensive Report job @requirement: REQ-MCP-004 - Full market analysis report @requirement: REQ-PAY-001 - Payment verification (1000 sats) Properties: Alignment(+0.5), Self-Improvement(+0.4)
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | standard | |
| topic | Yes | ||
| payment_proof | No | ||
| include_predictions | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only provides cryptic requirement and property lines without explaining side effects, authentication needs, rate limits, or what the report submission entails. The agent has no clue about safety or mutation.
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 short but fails to convey necessary information. The front-loaded metadata (@requirement, Properties) is unclear and not self-explanatory. Conciseness here sacrifices utility.
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 and an output schema, but the description ignores all context. No explanation of what the report job does, how parameters affect it, or what the output looks like. Totally inadequate for a complex 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 description coverage is 0%, and the description adds zero parameter information. Parameters like depth, payment_proof, include_predictions are unexplained, leaving the agent to guess their meanings and formats.
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 'Submit Comprehensive Report job' is vague. The requirement lines hint at a full market analysis report requiring payment, but it doesn't clearly distinguish this from sibling tools like submit_prediction_job. The verb 'submit' suggests job creation, but the specific report type is undefined.
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 tool versus alternatives. Sibling tools include other submit jobs (arbitrage, oracle, prediction), but no criteria for choosing this comprehensive report are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit Oracle Feed job with payment @requirement: REQ-MCP-001 - Public job submission @requirement: REQ-PAY-001 - Payment verification gate Properties: Alignment(+0.3), Autonomy(+0.5)
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | ||
| symbols | Yes | ||
| payment_proof | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only mentions 'with payment' and cryptic 'Properties: Alignment(+0.3), Autonomy(+0.5)', which add no standard behavioral context like side effects, permissions, or result handling.
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 short but includes non-standard lines (@requirement, Properties) that add clutter without clear benefit. It could be more focused and 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?
Given the complexity (3 params, many siblings, no annotations), the description lacks completeness: no parameter guidance, usage context, or behavioral details. Output schema exists but not referenced.
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%, meaning no parameter explanations in the description. The description does not add meaning to any parameter (e.g., payment_proof not linked to payment). Parameters remain undocumented beyond schema.
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 'Submit Oracle Feed job with payment', which specifies the verb and resource. However, it does not differentiate from sibling tools like submit_prediction_job, so it lacks explicit sibling distinction needed for a 5.
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 @requirement lines hint at prerequisites (public submission, payment verification), but there is no guidance on when to use this vs other submit tools or exclusions. The description fails to provide explicit context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit Prediction Analysis job @requirement: REQ-MCP-002 - Prediction market analysis @requirement: REQ-PAY-001 - Payment verification Properties: Alignment(+0.4), Self-Improvement(+0.3)
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| timeframe | No | 24h | |
| payment_proof | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It mentions 'Payment verification' requirement and properties like Alignment(+0.4), but these are opaque. There is no disclosure of side effects, auth needs, rate limits, or what happens after job submission.
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 (two lines plus tags), but it lacks meaningful structure. The front-loaded phrase 'Submit Prediction Analysis job' is clear, but the requirements and properties are not well-integrated for an AI agent's consumption.
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 has 3 parameters, no annotations, and sibling tools that submit similar jobs, the description is incomplete. It does not cover what the job entails, what the inputs represent, or how the output is used (despite an output schema existing).
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 (market, timeframe, payment_proof). It adds no semantic value beyond the parameter names and default values in the schema.
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 'Submit Prediction Analysis job', providing a clear verb+resource. It distinguishes from sibling tools like submit_oracle_job by specifying 'Prediction Analysis', though it could be more explicit about what constitutes a prediction 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 guidance is provided on when to use this tool versus alternatives. The description lacks context for appropriate usage scenarios, and the requirement references (@requirement: REQ-MCP-002, REQ-PAY-001) are not explained in terms of decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_price_alertanalyze_all_marketscheck_job_statusconfigure_alertscreate_job_invoiceexecute_arbitrage_tradeget_alert_historyget_belief_velocityget_chainlink_price_feedget_job_resultget_market_detailsget_signal_accuracyget_system_metricsget_trading_signalsinitialize_ditd_agentslist_job_typesrun_security_auditstart_alert_monitoringstop_alert_monitoringsubmit_arbitrage_jobsubmit_comprehensive_reportsubmit_oracle_jobsubmit_prediction_jobTools are generally distinct, with alert-related tools covering different operations (add, configure, history, start/stop) and job submission tools each for a specific job type. Some market analysis tools (get_belief_velocity, get_market_details, analyze_all_markets) have overlapping domains but different purposes, so only minor ambiguity exists.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., add_price_alert, get_alert_history, submit_oracle_job). No mixing of conventions or irregular forms, making the naming predictable and easy to understand.
With 23 tools, the set is slightly large but still reasonable for the server's scope covering alerts, job management, market analysis, and system operations. Each tool serves a clear role, though a few could potentially be merged (e.g., start/stop_monitoring).
The tool surface covers a wide range of functionalities including alerts, job submission/status, market data, trading signals, and system metrics. There is a slight gap: no tool to list all markets (only get_market_details requires a specific market). Overall, CRUD-like operations are well-covered for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The trust layer for the x402 agent economy: verifiable agent identity, payment & audit.
Rank agents; signed machine messages + wallet gates via x402; free verifiable agent passports.
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/craigmbrown/blindoracle-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
