Ailabra Agent Profit Ledger
Server Details
Determine autonomous-agent profit and cash flow with x402-paid MCP tools and signed reports.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 8 of 8 tools scored. Lowest: 3.2/5.
Tools are largely distinct, though profit_analyze and profit_calculate have overlapping purposes. Descriptions clarify the difference (findings vs totals), but potential confusion remains for agents.
All tool names follow a consistent verb_noun snake_case pattern (profit_*, workspace_*, report_verify). No mixing of conventions.
8 tools is appropriate for a profit ledger server, covering stateless analysis and persistent workspace workflows without excessive or insufficient tools.
Core CRUD-like operations are covered for both stateless and persistent modes. Minor gaps exist (e.g., no explicit workspace deletion or listing), but the server's purpose is well-served.
Available Tools
8 toolsprofit_analyzeAInspect
Use profit_analyze when an agent needs deterministic findings about cost concentration, revenue concentration, unprofitable experiments, missing costs, and evidence coverage. Stateless; price 0.05 USDC. Raw events are not retained and no LLM is used. This is not financial advice or an independent audit. Use profit_calculate for totals without findings.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| baseCurrency | No | ||
| exchangeRates | No | ||
| currentCashBalance | No | ||
| currentCashBalances | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses statelessness, pricing, data retention ('raw events are not retained'), no LLM usage, and disclaimers (not financial advice). However, it omits details about error behavior or what happens upon invalid input, preventing a 5.
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 five sentences, each adding unique value: purpose, stateless/pricing, data handling, disclaimer, sibling guidance. No redundant or filler content; front-loaded with the most critical 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?
Given the tool's complexity (5 parameters, nested objects, output schema exists), the description adequately covers output findings and key behaviors. However, it lacks details on input constraints (e.g., max events, required event fields) and error handling. The output schema partially compensates, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (events, baseCurrency, exchangeRates, currentCashBalance, currentCashBalances). The agent must infer meaning from parameter names alone, which is insufficient for a tool with nested structures and complex inputs.
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 that profit_analyze provides deterministic findings about specific financial metrics like cost concentration and revenue concentration, distinguishing it from sibling profit_calculate for totals. It explicitly names the resource categories it analyzes.
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 explicitly tells when to use the tool ('when an agent needs deterministic findings about...') and when not to, by directing to profit_calculate for totals without findings. It also mentions statelessness and pricing as practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
profit_attestBInspect
Use profit_attest when a tamper-evident Ed25519-signed profit calculation is needed for sharing or later verification. Stateless input; price 0.25 USDC. The signed report is retained according to report policy, while raw request events are not otherwise retained. A signature proves integrity and service origin, not independent auditing of self-reported evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| baseCurrency | No | ||
| exchangeRates | No | ||
| currentCashBalance | No | ||
| currentCashBalances | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses stateless input, cost (0.25 USDC), signature mechanism (Ed25519), retention policy (signed report retained, raw events not), and limitation (signature proves integrity, not auditing). This is comprehensive and adds significant value beyond what structured fields could provide.
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 three sentences, each serving a distinct purpose: purpose/usage, cost/statelessness, signature/retention. It is well-structured and concise, with no wasted words. However, it could be slightly more structured (e.g., bullet points) but is effective as is.
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, the description does not mention what is returned (signed report?). The complex input schema (nested objects, many properties) is not elaborated. Given the high complexity and 0% schema coverage, the description is insufficient for an agent to confidently invoke the tool. More detail on return value and parameter semantics would be needed.
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 descriptions in the schema. The description does not explain any of the 5 parameters (events, baseCurrency, exchangeRates, currentCashBalance, currentCashBalances). It mentions 'events' generically but gives no detail on structure or relationships. This is a critical gap.
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: producing a tamper-evident Ed25519-signed profit calculation for sharing or verification. It uses a specific verb (attest) and resource (profit calculation). While it doesn't explicitly differentiate from sibling tools like profit_calculate, the unique signing aspect is implied.
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 opens with 'Use profit_attest when...' providing a clear condition for use. However, it does not specify when not to use this tool or mention alternative tools (e.g., profit_calculate for unsigned calculations). No exclusions are given, but the condition itself is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
profit_calculateAInspect
Use profit_calculate when an autonomous agent needs to determine whether revenue exceeds operating costs, distinguish profit from wallet balance, or compare profitability across ventures and experiments. 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 for deterministic findings and profit_attest for a signed result.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| baseCurrency | No | ||
| exchangeRates | No | ||
| currentCashBalance | No | ||
| currentCashBalances | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses statelessness, price (0.01 USDC), non-retention of raw events, and evidence classification. Missing side effects or auth needs, but sufficient for a stateless calculation 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?
The description is compact (5 sentences) with no redundant information. Front-loaded with use cases, then statelessness and pricing, then sibling tools. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex input schema and presence of an output schema, the description covers key behavioral aspects (stateless, pricing, evidence) and usage context. Lacks details on return values but output schema exists.
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 individual parameters like events, baseCurrency, or exchangeRates. The complex nested schema requires more guidance.
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 calculates profit by comparing revenue to costs, distinguishes profit from wallet balance, and compares profitability across ventures/experiments. It also names sibling tools profit_analyze and profit_attest for 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?
Explicitly states when to use profit_calculate and provides alternatives: 'Use profit_analyze for deterministic findings and profit_attest for a signed result.' Also notes statelessness and pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_verifyAInspect
Use report_verify to check the integrity and service signature of historical report schemas 1, 2, or 3. Free, stateless, and no workspace token is required. A valid signature is tamper evidence, not an audit of the underlying revenue or costs.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions key behaviors: free, stateless, no token required, and the meaning of the signature (tamper evidence). However, it does not describe rate limits, error handling, output format, or any side effects. It adds value but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the primary purpose, and the second adds important behavioral context. Efficiently front-loaded.
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 one nested object parameter with no schema description and no annotations, the description is only partially complete. It covers purpose and key properties but lacks input parameter guidance. The presence of an output schema (not shown) might reduce the need to explain return values, but the input side remains weak.
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 mention the input parameter 'report' or its structure. The schema defines it as an object with additional properties, but no guidance on required fields or format is given. The description adds no meaning 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's purpose: 'check the integrity and service signature of historical report schemas 1, 2, or 3'. It specifies the verb ('check'), resource ('report schemas'), and scope (schemas 1, 2, or 3), distinguishing it from sibling tools like profit_analyze or profit_attest.
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 clear context: it is free, stateless, and requires no workspace token. It also explains that a valid signature indicates tamper evidence, not an audit. However, it does not explicitly state when to use this tool versus alternatives like profit_attest, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_createAInspect
Use workspace_create for a persistent 30-day agent economics workflow instead of one stateless batch. Price 0.25 USDC. Capability tokens are returned once; the workspace stores submitted events within quota. Use profit_calculate when retention is unnecessary. Stored evidence is not independently audited.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: 30-day persistence, price 0.25 USDC, capability tokens returned once, event storage within quota, stored evidence not independently audited. Full transparency despite no annotations.
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?
Every sentence adds distinct value: usage guidance, pricing, token handling, quota, alternative, audit disclaimer. No filler, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with output schema, description covers all relevant aspects: persistence, cost, token, quota, audit disclosure, and sibling distinction. No gaps.
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 exist, so schema coverage is 100%. Description adds context about workspace behavior but does not need to explain missing parameters. Baseline 4 is appropriate.
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?
Explicitly states the tool creates a persistent 30-day agent economics workflow, contrasting with stateless batch and naming sibling profit_calculate as alternative. Clearly defines verb+resource.
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?
Provides explicit guidance: use for persistent workflows, use profit_calculate when retention is unnecessary. Clearly states when to use and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_get_data_qualityAInspect
Use workspace_get_data_quality to inspect evidence coverage, missing cost categories, attribution gaps, and warnings for retained workspace events. Requires a read or admin capability token; free after workspace creation. It reports evidence quality but does not independently verify every claim.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | ||
| capabilityToken | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds a useful limitation ('does not independently verify every claim') but omits other behavioral traits like idempotency, side effects, or rate limits. The read-only nature is implied but not explicit.
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 with three sentences, front-loading the purpose. It could be more structured but avoids unnecessary 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 the existence of an output schema, the description does not need to detail return values. It covers key aspects of use (what it inspects, token requirement, post-creation timing) and adds a limitation. It is largely complete for a data quality inspection 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%, so the description must compensate. It only indirectly hints at the token parameter via the token requirement, but provides no details on workspaceId or token format. This adds minimal value 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 inspects specific aspects of data quality (evidence coverage, missing cost categories, attribution gaps, warnings) for retained workspace events. It uses a specific verb 'inspect' and resource, and stands out from sibling tools focused on profit or reporting.
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 context: requires a read or admin capability token and is available after workspace creation. However, it does not specify when to prefer this tool over alternatives like report_verify or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_get_profitAInspect
Use workspace_get_profit for current deterministic profit, cash flow, venture contribution, and experiment profitability from retained workspace events. Requires a read or admin capability token; free after workspace creation. Use profit_calculate for stateless data.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | ||
| capabilityToken | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses authentication requirements ('Requires a read or admin capability token'), cost implications ('free after workspace creation'), and the deterministic nature of the data. While it doesn't detail error handling or output format, the output schema covers return values, making it fairly transparent.
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 with three sentences, each serving a clear purpose: stating the tool's output, specifying requirements, and directing to an alternative. No unnecessary information is present.
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 existence of an output schema, the description appropriately does not elaborate on return values. It lists key output concepts (profit, cash flow, venture contribution, experiment profitability) and mentions the source ('retained workspace events'). Missing details like error handling or rate limits are minor, so completeness is strong.
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% for both parameters. The description adds meaning to the capabilityToken parameter by specifying it must be a 'read or admin capability token', but provides no additional context for workspaceId. This partial compensation places the score at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'current deterministic profit, cash flow, venture contribution, and experiment profitability from retained workspace events', specifying the resource and context. It distinguishes itself from sibling profit_calculate, ensuring no confusion.
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 explicitly states when to use this tool ('for current deterministic profit...') and when to use an alternative ('Use profit_calculate for stateless data'). It also mentions the requirement of a capability token, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workspace_record_eventsAInspect
Use workspace_record_events to append revenue, expenses, refunds, fees, capital, withdrawals, and transfers during a 30-day persistent workflow. Requires a write or admin capability token; no additional x402 charge. Events count against quota and remain until expiry or deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | ||
| workspaceId | Yes | ||
| capabilityToken | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auth requirements, lack of extra charge, quota counting, and event persistence. Missing details: failure behavior, rate limits, idempotency, or the meaning of '30-day persistent workflow'.
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?
Three sentences, each adding value: purpose and content, auth/charge info, quota/persistence. No redundant or filler text.
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 complex input schema (nested events with many properties) and an output schema not visible, the description gives no information about return values, error responses, or post-conditions. The 30-day workflow constraint is mentioned but not explained.
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%, so description must compensate. It only mentions the capabilityToken requirement, but does not explain workspaceId or the complex events parameter structure. The nested event object's many fields are left entirely to 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 starts with a clear verb ('append') and specifies the resource ('events'), listing a comprehensive set of event types (revenue, expenses, etc.). This distinguishes it from sibling tools like profit_analyze or workspace_create.
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 states required capability token type ('write or admin'), mentions no additional charge, and notes quota and persistence. However, it does not explicitly compare to alternatives or provide when-to-use vs. not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!