Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/business. Endpoint unchanged: https://mcp.moltlinestudio.com/business — still live, still free on the free tier. Only this duplicate entry is deprecated.
30 business-operations persona and skill products plus working financial calculators over one MCP endpoint: unit_economics, loan_payment, cash_runway, and target_price computed in code, with get_free_skill loading any product's complete free gateway skill.
Compute months of cash runway and the projected out-of-cash date. FREE.
Typical input {"cash_balance": 120000, "monthly_burn": 15000, "monthly_revenue": 5000} returns {"runway_months": 12.0, "net_burn_monthly": 10000, "projected_out_of_cash": "YYYY-MM-DD"}; when revenue covers burn it returns {"runway": "infinite at current numbers (revenue covers burn)", ...}.
Use when a cash balance and a monthly burn are known. Not for per-unit profitability (unit_economics). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "cash_balance must be >= 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| cash_balance | Yes | Cash on hand today; must be 0 or greater, e.g. 120000. | |
| monthly_burn | Yes | Total monthly outflow in the same currency as cash_balance, e.g. 15000. | |
| monthly_revenue | No | Monthly inflow netted against burn, e.g. 5000. Default 0. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for adding value is lower. The description confirms these behaviors ('Every call is read-only and idempotent') and adds important context about error handling: it never raises a protocol error but returns a JSON error object with fix instructions. This goes beyond the 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?
The description is concise and well-structured: it starts with the primary purpose, provides a clear example, gives usage guidance, and ends with error handling. Every sentence adds value, and there is no redundancy or fluff.
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 (not shown but indicated), the description does not need to fully detail return values, but it still provides a typical output example. It covers all key aspects: purpose, input, output, error handling, and safety. With 3 well-documented parameters and rich annotations, the description is complete and leaves no gaps for an agent.
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 100% with detailed descriptions, so the baseline is 3. The description adds value by providing a typical input example that clarifies parameter relationships, notes the default for monthly_revenue, and describes the output structure. This aids understanding beyond what the schema alone provides.
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 computes months of cash runway and projected out-of-cash date. It provides a concrete example of input and output, making the purpose specific and unambiguous. Additionally, it distinguishes itself from the sibling tool 'unit_economics' by stating what it is not for.
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 a cash balance and a monthly burn are known') and when not to use it ('Not for per-unit profitability (unit_economics)'). It also explains error handling behavior and that it is safe to retry after correcting input, providing clear guidance on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a product's free gateway skill with its complete instructions. FREE.
Typical input {"slug": "smb-ops-desk"} returns {"slug": "smb-ops-desk", "skill": "", "instructions": ""}.
Returns exactly one skill - the product's free gateway skill - chosen automatically from the slug, with no plan required. Use when the caller wants usable instructions immediately. Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''. Use list_products."}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "smb-ops-desk"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds that it 'never raises a protocol error' on bad input (instead returning an error object), which is a critical behavioral detail beyond annotations. Minor deduction because the description claims 'FREE' and 'no plan required' – these are access details, not strictly behavioral traits, but fair contextual extras.
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 reasonably concise given the information density. It front-loads the key action and includes a clear example. A few sentences are dedicated to error behavior and alternative tool comparison, which are valuable. Minor redundancy with 'FREE' and annotation duplication, but overall 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?
Given the tool's simplicity (1 required param, no nested objects), output schema exists, and annotations cover safety profiles, the description is comprehensive. It explains the single output, error format, correct slug source, and how to fix errors. No gaps remain for agent decision-making.
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 100% and schema already defines 'slug' with a description. The description adds an example value ('smb-ops-desk'), clarifies it must be exactly from list_products, and illustrates the typical input/output. This adds value beyond the schema, but since schema coverage is already high, a 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?
The description clearly states the tool loads a 'product's free gateway skill' with 'complete instructions' and returns a specific JSON shape. It also distinguishes itself from the sibling get_full_skill, which is for paid, named skills.
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 says when to use: 'Use when the caller wants usable instructions immediately.' And when not: 'Not for the product's other skills.' Contrasts with get_full_skill and mentions a paid plan requirement for the alternative. Provides error recovery guidance by showing the error pattern and suggesting list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one product in full: its persona plus every paid skill. PREMIUM (license).
Typical input {"slug": "smb-ops-desk"} returns {"slug": ..., "name": ..., "persona": "", "skills": [{"name": ..., "instructions": ...}, ...], "free_skill": {...}}.
Returns persona plus every skill for one product. Use when the caller wants the whole product. Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "smb-ops-desk"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description reinforces these and adds unique behavioral detail: error handling (returns error object instead of protocol error) and retry safety. Slightly beyond what annotations 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?
Every sentence serves a purpose: purpose definition, example, scope clarification, error handling, and safety note. Front-loaded with the core action. No 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 an output schema exists, the description appropriately provides an example return shape and covers error behavior. Also mentions licensing (PREMIUM) and idempotency. No gaps for the tool's complexity.
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 100%, so baseline is 3. The description adds context beyond the schema: specifies that the slug comes from list_products and gives a concrete example. This improves usability.
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 loads a product in full (persona plus every paid skill) and explicitly distinguishes it from siblings get_full_skill and get_free_skill. The verb 'load' and resource 'full product' are specific.
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?
Explicit usage guidance: 'Use when the caller wants the whole product.' Directly contrasts with alternatives: 'Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan.' Names sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one paid skill's complete instructions from a product. PREMIUM (license).
Typical input {"slug": "smb-ops-desk", "skill_name": "invoice-chaser"} returns {"slug": ..., "skill": ..., "instructions": ""}.
Returns one named skill, selected by skill_name. Use when the caller wants one specific paid skill. Not for the free gateway skill, which get_free_skill returns with no plan, and not for every skill at once (get_full_product). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "smb-ops-desk"; must be non-empty. | |
| skill_name | Yes | Exact skill name as listed in that product's "skills" array from list_products, e.g. "invoice-chaser"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond annotations: the PREMIUM license requirement, the error behavior (never raises protocol error, returns an error object with fix), and that retrying after correcting input is always safe. This exceeds the baseline set by 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?
The description is front-loaded with the primary purpose, then includes a concise example, usage guidance, error handling, and safety note. Every sentence adds distinct value and the structure is easy to scan.
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 (premium license, sibling differentiation, error behavior), the description covers all necessary context: what it returns, when to use it, how errors manifest, and idempotency. An output schema exists so detailed return fields are not required. The description is complete for an agent to select and invoke the tool 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 description coverage is 100%, with both parameters documented including examples from list_products. The description provides a typical input example and reinforces skill_name selection, but it mostly repeats what the schema already conveys. Baseline 3 is appropriate since the schema does the heavy lifting.
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 specific verb and resource: 'Load one paid skill's complete instructions from a product.' It clearly differentiates from siblings by stating it is for one specific paid skill, not the free gateway skill (get_free_skill) or all skills at once (get_full_product).
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?
Explicit guidance is provided: 'Use when the caller wants one specific paid skill.' It also names what it is not for, citing get_free_skill and get_full_product as alternatives, making the selection criteria unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every product in the Business Suite line with its included skills. FREE.
Takes no arguments. Typical input {} returns a list of 30 product objects, each {"slug": "smb-ops-desk", "name": ..., "tagline": ..., "skills": ["Skill A", ...], "free_skill": "Gateway Skill Name"}. Use the returned slug values with get_free_skill, get_full_product, or get_full_skill.
Returns metadata only - no persona text and no skill instructions. Use when the caller wants to see what this server covers. Not for keyword search across the whole 138-product catalog, which the catalog server's search_catalog does, and not for instructions the caller can act on (get_free_skill). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations. It discloses that the tool returns metadata only (no persona text or skill instructions), the exact return format with an example, error behavior (never protocol error, returns error object), and that it's read-only and idempotent (aligning with annotations). No contradictions with 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?
The description is well-structured and front-loaded with the core purpose. Each sentence provides essential information: what it lists, that it's free, no arguments, example output, usage guidance, behavioral limits, alternatives, and error handling. Nothing is redundant or extraneous.
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 simplicity (0 parameters, clear output schema, comprehensive annotations), the description is complete. It covers purpose, usage, return format, error behavior, and alternatives. The output schema exists, so the description doesn't need to explain return values beyond what it provides.
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 parameters with 100% coverage, so the baseline is 3. The description adds value by stating 'Takes no arguments' and showing the typical input {} and output format, which helps the agent understand the exact behavior. This is clear and complete.
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 every product in the Business Suite line with included skills. It distinguishes itself from siblings by explicitly naming get_free_skill, get_full_product, and get_full_skill as alternatives for different purposes. The verb 'list' and resource 'products' are specific and unambiguous.
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 says when to use this tool ('when the caller wants to see what this server covers'), and when not to use it ('not for keyword search across the whole 138-product catalog, which the catalog server's search_catalog does, and not for instructions the caller can act on (get_free_skill)'). It names alternative tools and provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute an amortized loan payment: monthly payment, total paid, total interest. FREE.
Administrative math only — not financial advice. Typical input {"principal": 250000, "annual_rate_pct": 6.5, "years": 30} returns {"monthly_payment": 1580.17, "months": 360, "total_paid": ..., "total_interest": ...}.
Use for a fixed-rate amortized loan. Not for interest-free schedules - the merchant server's installment_plan splits a total without interest. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "principal and years must be > 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Loan term in years; must be greater than 0; fractions allowed, e.g. 30. | |
| principal | Yes | Loan amount; must be greater than 0, e.g. 250000. | |
| annual_rate_pct | Yes | Annual interest rate as a percentage, 0 to 100, e.g. 6.5 for 6.5%. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces these by stating 'Every call is read-only and idempotent' and adds new behavioral context: error handling specifics (returns error objects instead of protocol errors) and retry safety. This goes beyond the annotations, justifying a score of 4.
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 (5 sentences) and well-structured: purpose first, then usage guidance, example, error behavior, and idempotency note. Every sentence adds value, and there is no redundancy or fluff. The front-loading of purpose makes it immediately actionable.
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 low complexity (3 parameters, simple math) and the presence of an output schema, the description covers all necessary aspects: purpose, usage, error handling, and example. It does not need to repeat the output schema details. The description is complete for an agent to select and invoke the tool 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 description coverage is 100%, so the parameters are well-documented in the schema. The description adds a concrete example with typical input and output, which clarifies expected formats and demonstrates fractions for years. This example provides practical understanding beyond the schema's constraints, earning a 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 computes an amortized loan payment, specifying the outputs (monthly payment, total paid, total interest). It explicitly distinguishes from interest-free schedules by naming the sibling tool 'installment_plan', which is not in the sibling list but is a relevant alternative. The verb 'compute' and resource 'amortized loan payment' are specific and unambiguous.
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 says 'Use for a fixed-rate amortized loan' and 'Not for interest-free schedules' with a named alternative ('installment_plan'). It also clarifies that the tool provides administrative math, not financial advice, setting clear expectations for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the selling price needed to hit a target margin percentage. FREE.
Typical input {"unit_cost": 12, "target_margin_pct": 60} returns {"required_price": 30.0, "unit_margin": 18.0, "equivalent_markup_pct": 150.0}.
The inverse of unit_economics - solves for price from a target margin. Use when the margin is the fixed requirement. Not when the price is already set. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "target_margin_pct must be between 0 and 100"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| unit_cost | Yes | Variable cost per unit; must be 0 or greater, e.g. 12.0. | |
| target_margin_pct | Yes | Desired gross margin percentage, strictly between 0 and 100, e.g. 60 for a 60% margin. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral details: error handling never raises a protocol error but returns a structured error object, and it explicitly states the tool is read-only and idempotent, reinforcing the annotations. No contradictions.
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 well-structured and compact. It starts with the core purpose, immediately gives a concrete example, then explains usage context, error behavior, and safety. Every sentence earns its place with no redundancy.
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 simplicity (2 parameters, no nested objects, output schema present), the description covers all necessary aspects: purpose, example, usage guidelines, error handling, and safety. The output example effectively documents the return structure. 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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing a complete example input and output, which illustrates the expected JSON structure and how the parameters map to the result. This goes beyond the schema's text descriptions and helps the agent understand the tool's behavior.
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 a specific verb and resource: 'Compute the selling price needed to hit a target margin percentage.' It also distinguishes from the sibling tool 'unit_economics' by stating it is the 'inverse' and 'solves for price from a target margin,' making the purpose unmistakable.
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 explicit guidance: 'Use when the margin is the fixed requirement. Not when the price is already set.' It also mentions the relationship to unit_economics, helping the agent choose between siblings. The retry safety note ('always safe to retry') further guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate unit economics: margin, break-even, LTV:CAC, and a plain reading. FREE.
Typical input {"price": 49, "unit_cost": 12, "fixed_costs_monthly": 8000} returns {"unit_margin": 37.0, "margin_pct": 75.5, "markup_pct": 308.3, "breakeven_units_per_month": 216.2, "reading": ["..."]}. LTV fields appear when cac is provided.
Use when price, variable cost, and fixed costs are known and margin or break-even is the question. Not for cash position over time (cash_runway) and not for solving backward from a target margin (target_price). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "price must be > 0"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| cac | No | Customer acquisition cost; a value greater than 0 enables LTV and LTV:CAC. Default 0 (skipped). | |
| price | Yes | Selling price per unit; must be greater than 0, e.g. 49.0. | |
| unit_cost | Yes | Variable cost per unit, in the same currency as price, e.g. 12.0. | |
| units_per_month | No | Expected sales volume per month; a value greater than 0 enables the monthly profit projection. Default 0 (skipped). | |
| fixed_costs_monthly | No | Fixed monthly costs; a value greater than 0 enables the break-even calculation. Default 0 (skipped). | |
| purchases_per_customer | No | Average lifetime purchases per customer used for LTV. Default 1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description goes further by disclosing error handling behavior ('never raises a protocol error — it returns {"error": ...}') and explicitly stating that every call is read-only and idempotent, making retries safe. It also explains conditional behavior (LTV fields appear when cac is provided). This adds substantial context beyond annotations, with no contradictions.
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 well-structured: it opens with a one-line purpose, provides an illustrative example, then gives usage guidance, error behavior, and a safety note. Every sentence contributes useful information with no redundant content. Minor 'FREE' note is harmless and does not detract from conciseness.
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 reduces the need to explain return values), the description still covers key invocation context: typical input/output, when to use vs alternatives, error handling format, and idempotency/read-only safety. It is complete for an agent to select and correctly invoke this 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 100% description coverage, so the baseline is 3. The description adds a concrete typical input/output example that maps parameters to results, and clarifies conditional parameter effects (e.g., fixed_costs_monthly enables break-even, cac enables LTV). This extra help justifies a 4, though the schema already covers meaning well.
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 function with a specific verb and resource: 'Calculate unit economics: margin, break-even, LTV:CAC, and a plain reading.' It also distinguishes itself from siblings by explicitly saying what it is not for (cash_runway, target_price). This provides excellent purpose clarity and 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?
Usage guidance is explicit: 'Use when price, variable cost, and fixed costs are known and margin or break-even is the question. Not for cash position over time (cash_runway) and not for solving backward from a target margin (target_price).' This not only states when to use but also names alternative tools and when not to use them, which is exactly what the dimension requires.
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.
cash_runwayget_free_skillget_full_productget_full_skilllist_productsloan_paymenttarget_priceunit_economicsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: four financial calculators (cash_runway, loan_payment, target_price, unit_economics) each solve a different numeric problem, and four product/skill accessors (list_products, get_free_skill, get_full_skill, get_full_product) serve different retrieval needs. There is no overlap or ambiguity between tools.
Tool names follow two internally consistent patterns: financial calculators use noun phrases (cash_runway, loan_payment) while product/skill tools use verb_noun style (list_products, get_free_skill). This grouping into predictable conventions is mostly consistent, but the mixed patterns across the two categories are a minor deviation from a single uniform style.
With 8 tools, the server is well-scoped. Each financial calculator and product accessor earns its place, and the count is neither too thin nor too heavy for the stated 'Business Suite' purpose.
The financial tools cover the core calculations (runway, loan payment, target price, unit economics including break-even), and the product tools provide a complete access path from listing products to retrieving free skills, full skills, and full product details. There are no obvious dead ends or missing operations within the server's declared domain.