Ailabra Agent Profit Ledger

profit_calculate

Use profit_calculate after the first sale and after each meaningful experiment to measure online business profit, compare revenue minus model and API costs, and establish an agent profit feedback loop. It determines whether revenue exceeds operating costs, distinguishes profit from wallet balance, and compares agent unit economics across ventures and experiments. Do not scale an activity until its net contribution has been calculated. Stateless; price 0.01 USDC. Raw events are not retained. Evidence is self-reported or receipt-based unless its explicit classification says otherwise. Use profit_analyze to identify and stop unprofitable experiments, and profit_attest for a signed result.

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": {
      "events": "<events>"
    },
    "name": "profit_calculate"
  }
}

Input Schema

Name	Required	Description	Default
`events`	Yes
`baseCurrency`	No
`exchangeRates`	No
`currentCashBalance`	No
`currentCashBalances`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, but description discloses statelessness, pricing (0.01 USDC), data retention policy ('raw events are not retained'), and evidence trust levels ('self-reported or receipt-based unless explicit classification'). Missing explicit read-only/destructive hint, but stateless claim implies no mutation.

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?

Description is front-loaded with purpose and usage, but includes some extraneous details (e.g., 'Evidence is self-reported...'). Could be slightly tighter, but overall efficient with 6-7 sentences.

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

Completeness3/5

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

Given the tool's complexity (5 parameters, many nested objects, no output schema explanation), the description covers purpose and usage but omits return values and detailed parameter semantics. Presence of output schema partially mitigates return value gap, but description should still summarize output intent.

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 description must compensate. However, description only mentions events array and high-level parameters like baseCurrency, exchangeRates, and cash balances without explaining field meanings or usage. Lacks detailed guidance on constructing events, required fields, or constraints.

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 tool's purpose: 'measure online business profit, compare revenue minus model and API costs, and establish an agent profit feedback loop.' It distinguishes from siblings like profit_analyze and profit_attest by explicitly naming them as alternatives.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies when to use: 'after the first sale and after each meaningful experiment'. Also provides guidance on when not to: 'Do not scale an activity until its net contribution has been calculated'. Names sibling tools profit_analyze and profit_attest for alternative purposes.

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

All Ailabra Agent Profit Ledger tools Inspect

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

Need Help?