Skip to main content
Glama
mikki321

night-margin-mcp

by mikki321

Review your own past months (net of estimated turnover cost)

review_history

Review past monthly performance data by mirroring actual KPIs including revenue, estimated turnover cost, net profit, occupancy, and ADR. No forecasting or recommendations.

Instructions

Season review: mirrors your OWN past monthly Wheelhouse KPIs back at you — per month, your revenue, an ESTIMATED turnover cost, estimated net, and what fraction of gross the cleaning ate (turnover share), plus occupancy and ADR. Turnover cost is estimated from monthly averages (occupied nights ÷ average length of stay × AVG_TURNOVER_COST), not measured per booking, and is labeled as an estimate. It describes what already happened over your real history; it does NOT forecast, does NOT recommend or rank strategies, and does NOT say what you 'should have' done or what another strategy 'would have' earned. Window defaults to all available history (usually only a handful of months per listing — it states the real span, never 'last year' or '5 years' unless the data actually covers it). Read-only — never changes any prices and never writes any state. Requires WHEELHOUSE_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLatest month to include, YYYY-MM-DD — matched at MONTH granularity and INCLUSIVE. Optional — defaults to all available history.
fromNoEarliest month to include, YYYY-MM-DD — matched at MONTH granularity and INCLUSIVE (any day in the month includes that whole month). Optional — defaults to all available history.
avg_turnover_costNoOverride AVG_TURNOVER_COST for this run: € per turnover. Used to ESTIMATE turnover cost from monthly averages (occupied nights ÷ avg length of stay × this number).
Behavior5/5

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

Since no annotations are provided, the description carries full burden. It declares read-only nature, no state changes, estimation methodology for turnover cost, that estimates are not measured per booking, and that window defaults to available history (no fabricated spans). Comprehensive.

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?

The description is well-structured and front-loaded with purpose. Every sentence adds value, though there is slight redundancy (estimation mentioned twice). Efficient overall.

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?

Without output schema, the description explains return values (revenue, turnover cost, net, turnover share, occupancy, ADR). It also covers derivation limitations, defaults, and read-only behavior. Thorough for a 3-param tool.

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 baseline is 3. The description adds value by explaining default behavior (optional, defaults to all history) and the purpose of avg_turnover_cost override and its estimation formula. This extra context justifies a 4.

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 mirrors your own past monthly KPIs (revenue, estimated turnover cost, net, turnover share, occupancy, ADR). It distinguishes from siblings like analyze_portfolio or compare_strategies by focusing on personal history review.

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 says when to use: to review past history. Also clearly states what it does NOT do: forecast, recommend, rank strategies, or suggest alternatives. Provides clear context on default window behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mikki321/night-margin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server