Skip to main content
Glama

Intangible Asset Valuation MCP Server

Human Capital

valuation_human_capital
Read-onlyIdempotent

Human capital: assembled-workforce value by replacement cost and key-person value from revenue contribution and departure risk. Method selects the formula. Use for assembled workforce and key-person intangibles; assembled_workforce nets training and attrition into a replacement cost. For customer-related assets use valuation_customer; for technology assets use valuation_technology. Per method: assembled_workforce needs employee_count + avg_replacement_cost + training_cost + productivity_factor + attrition_rate; key_person needs revenue_contribution + replacement_cost + departure_probability + discount_rate. attrition_rate is in [0,1]; productivity_factor scales the replacement cost (1.0 = parity). Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesFormula to apply. Options: assembled_workforce = Replacement cost including training, net of attrition.; key_person = Revenue contribution and replacement cost under departure risk.
discount_rateNoPer-period discount rate as a decimal (0.10 = 10%).
training_costNoTraining cost per employee, in currency units.
attrition_rateNoAnnual attrition rate, in [0,1].
employee_countNoNumber of employees.
replacement_costNoCost to replace the key person, in currency units.
productivity_factorNoProductivity factor on replacement cost (1.0 = parity).
avg_replacement_costNoAverage cost to replace one employee, in currency units.
revenue_contributionNoAnnual revenue contribution, in currency units.
departure_probabilityNoAnnual probability the key person departs, in [0,1].

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).
formula_referenceNoMathematical formula or reference applied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/no-open-world, and the description adds substantial non-obvious behavior: pure arithmetic with no I/O, results rounded to 2 decimals, error on unknown method or missing method-required parameter, and extra method parameters silently ignored. These are failure modes an agent must know and are not derivable from annotations.

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?

Front-loads purpose, then routing, then per-method parameters, then edge-case behavior — a sensible order with no filler. It is dense and long, with some restatement of schema-documented ranges, but nearly every sentence carries operational weight.

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?

For a 10-parameter, method-branching calculator with an output schema, the description covers required vs optional params, defaults, ignore semantics, and error conditions. Return-value explanation is correctly omitted since the output schema exists.

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

Parameters4/5

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

Schema coverage is 100%, so units and ranges are already documented; the description's value-add is the per-method parameter grouping (assembled_workforce needs five named params, key_person needs four) and the guidance to supply only the selected method's params and omit the rest. It repeats the [0,1] and 1.0=parity notes already in the schema, so it stops short of a 5.

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?

States a specific output (assembled-workforce value by replacement cost, key-person value from revenue contribution and departure risk) and explicitly names the sibling tools it is not (valuation_customer, valuation_technology). An agent can route to it without opening the 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?

Gives explicit use cases ('use for assembled workforce and key-person intangibles') plus exclusion routing to valuation_customer and valuation_technology. The method-selection rule ('Method selects the formula') tells the agent how to choose between the two internal paths.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.