Cubi Estate

Corpus statistics

corpus_stats

Read-only

Day-by-day Cubi corpus activity — aggregate counts only, no listings.

Use this for dashboards or "how is the corpus moving" questions: active
listing totals, per-country breakdown, and per-day series of newly ingested
listings, deactivated listings, and detected price drops.

Args:
    days: Trailing window length in days (1-90, default 30).
    country: Optional full country name filter, e.g. "Portugal", "Spain".
             Case-insensitive. Omit for the whole corpus.

Returns:
    JSON string: {country, days, active_listings, active_by_country,
    daily: {new_listings, deactivated, price_drops}} where each daily
    series maps "YYYY-MM-DD" to a count (price_drops adds avg_pct,
    negative = average drop size in percent).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "corpus_stats"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Trailing window length in days (1-90, default 30).
`country`	No	Optional full country name filter, e.g. "Portugal", "Spain". Case-insensitive. Omit for the whole corpus.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 11, 2026

addedInput schema / properties / country / description

Added value: +"Optional full country name filter, e.g. \"Portugal\", \"Spain\". Case-insensitive. Omit for the whole corpus."

addedInput schema / properties / days / description

Added value: +"Trailing window length in days (1-90, default 30)."

First observedOct 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description adds the meaningful behavioral caveat that results are aggregates only, never individual listings. It also clarifies that price_drops values carry a signed average percentage, which an agent would otherwise misinterpret.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening paragraph is well front-loaded and wastes nothing. However, the 'Args' and 'Returns' blocks duplicate the input schema and the existing output schema almost verbatim, which is space that does not earn its place for an agent that receives those structured fields anyway.

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 two-parameter read-only aggregation tool with full schema coverage, annotations, and an output schema, the description supplies everything needed: the scope, the intended question type, and the interpretation of the one ambiguous field (avg_pct sign). Nothing an agent needs in order to call it correctly is absent.

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

Parameters3/5

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

Schema coverage is 100%, and the 'Args' block largely restates the schema's own descriptions (days 1-90 default 30; country as a case-insensitive full name). The only added nuance is the reminder to omit country for whole-corpus scope, so the baseline 3 applies.

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 first line names a specific aggregate verb and resource ('day-by-day Cubi corpus activity') and immediately scopes it ('aggregate counts only, no listings'), which lets an agent rule out listing-level siblings like search_properties or filter_listings without opening a schema. The enumerated outputs (active totals, per-country breakdown, per-day series) further pin down the shape of the answer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this for dashboards or "how is the corpus moving" questions' gives a clear selection context. What is missing is an explicit counter-case — nothing says which sibling to use when the agent needs actual listing records, though 'no listings' hints at it.

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

All Cubi Estate tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?