Skip to main content
Glama
simonmak-ascent

Intangible Asset Valuation

by simonmak-ascent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Customer-Related Assets

valuation_customer
Read-onlyIdempotent

Calculate customer-related intangible value for customer relationships, distribution networks, and non-compete agreements using method-specific formulas with attrition, margins, and discount rates.

Instructions

Customer-related intangibles: customer relationships with attrition, distribution networks by channel profitability, and non-compete agreements on protected profits. Method selects the formula. Use for customer relationships, distribution networks, and non-compete assets; customer_relationships projects multi-period revenue with a retention rate. For the workforce and key-person assets use valuation_human_capital; for technology assets use valuation_technology. Per method: customer_relationships needs customer_count + avg_revenue_per_customer + retention_rate + profit_margin + discount_rate + projection_period; distribution_network needs channel_count + revenue_per_channel + channel_margin + useful_life + discount_rate; non_compete needs protected_revenue + profit_margin + term + enforcement_probability + discount_rate. retention_rate and enforcement_probability are in [0,1]; projection_period sets the number of discounted periods. Only method is required; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, returns an error instead of a value.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termNoNon-compete term in years (≥ 0).
methodYesFormula to apply. Options: customer_relationships = Multi-period revenue net of attrition, discounted.; distribution_network = Channel revenue times margin over the useful life.; non_compete = Protected profit under an enforcement probability, discounted.
useful_lifeNoUseful life in years n (integer ≥ 1).
channel_countNoNumber of distribution channels (integer ≥ 0).
discount_rateNoPer-period discount rate as a decimal (0.10 = 10%).
profit_marginNoProfit margin as a decimal (0.20 = 20%).
channel_marginNoChannel profit margin as a decimal in [0,1].
customer_countNoNumber of customers (integer ≥ 0).
retention_rateNoAnnual customer retention rate, in [0,1].
projection_periodNoProjection horizon in years (integer ≥ 1).
protected_revenueNoAnnual revenue protected by the non-compete, in currency units.
revenue_per_channelNoAnnual revenue per channel, in currency units.
enforcement_probabilityNoProbability the non-compete is enforceable, in [0,1].
avg_revenue_per_customerNoAverage annual revenue per customer, in currency units.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoError message when the call fails.
stepsNoIntermediate calculation steps for traceability (one string per step).
valueYesComputed valuation, rate, or metric.
methodNoFormula / method name that produced the result.
assumptionsNoModelling assumptions applied (list of strings or key/value object).
defaults_appliedNoOptional parameters that were not supplied, so their documented defaults were used.
formula_referenceNoMathematical formula or reference applied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.1
    • addedOutput schema / properties / defaults_applied
      Added value: +{
+  "description": "Optional parameters that were not supplied, so their documented defaults were used.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed6 schema fields changedv2.0.1
    • changedInput schema / properties / channel_count / description
      Previous value: -"Number of distribution channels."New value: +"Number of distribution channels (integer ≥ 0)."
    • changedInput schema / properties / channel_margin / description
      Previous value: -"Channel profit margin as a decimal."New value: +"Channel profit margin as a decimal in [0,1]."
    • changedInput schema / properties / customer_count / description
      Previous value: -"Number of customers."New value: +"Number of customers (integer ≥ 0)."
    • changedInput schema / properties / projection_period / description
      Previous value: -"Projection horizon in years."New value: +"Projection horizon in years (integer ≥ 1)."
    • changedInput schema / properties / term / description
      Previous value: -"Non-compete term in years."New value: +"Non-compete term in years (≥ 0)."
    • changedInput schema / properties / useful_life / description
      Previous value: -"Useful life in years n."New value: +"Useful life in years n (integer ≥ 1)."
  3. Changed2 schema fields changedv0.1.4
    • changedOutput schema / properties / steps / description
      Previous value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."
    • removedOutput schema / properties / steps / items / type
      Removed value: -"object"
  4. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare this as a read-only, idempotent, closed-world operation, and the description adds genuinely new behavioral facts: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, defaults applied where defined, and that parameters belonging to other methods are accepted and silently ignored. It also discloses the failure mode (unknown method or missing method-required parameter returns an error rather than a value), which is exactly the kind of contract detail an agent needs.

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?

It is front-loaded correctly — asset scope and sibling routing come first, method-to-parameter mapping follows, and global caveats (decimal convention, arithmetic-only behavior, error semantics) close it out. The middle section is a dense, comma-spliced run-on that could be bulleted for faster scanning, but essentially every clause carries information an agent needs for a 14-parameter tool.

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

Completeness5/5

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

With an output schema present, return values need not be explained, and the description covers everything else: enum semantics for method, per-method required inputs, unit conventions, rounding, default handling, ignored parameters, and error behavior. Nothing needed to invoke this tool correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline would be 3, but the description goes well beyond it by mapping each method to its required parameter set and clarifying cross-parameter rules that no individual schema description states: which parameters are method-dependent, that only 'method' is required, that unspecified parameters fall back to defaults, and that retention_rate/enforcement_probability are unit fractions in [0,1] and projection_period sets the number of discounted periods.

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 names the specific asset class (customer-related intangibles) and enumerates the three concrete formulas it computes: customer relationships with attrition, distribution networks by channel profitability, and non-compete agreements. It also explicitly routes the agent away from siblings by naming valuation_human_capital and valuation_technology, so the tool is distinguishable without opening any schema.

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?

It states when to use this tool ('Use for customer relationships, distribution networks, and non-compete assets') and gives explicit alternatives for the adjacent domains (workforce/key-person -> valuation_human_capital; technology -> valuation_technology). It further tells the agent how to select among the three internal methods via the required 'method' parameter.

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

Deploy Server

Other Tools