Skip to main content
Glama
sedis-ab

@sedis/mcp

Official
by sedis-ab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get the CompDatum time-series

fastighetsbenchmark_get_comp_timeseries
Read-only

Fetch benchmarking time-series values for one or more comparables using sedisIds, parameter code, and an ISO date range.

Instructions

Read-only. Pull the actual benchmarking numbers (CompDatum time-series) for one or more Comps. This is the FINAL step of the §8 A6 flow: pass the sedisIds you found (from fastighetsbenchmark_search_property_units, _list_samlingar's containingCompSedisIds, or _list_jamforelseobjekt) as a comma-separated sedisIdIn, plus a parameterCode from fastighetsbenchmark_find_parameter and an ISO date range. Each row is SELF-DESCRIBING via dataType (decimal/boolean/enum/date) — read the matching member (figure/boolean/enum/date); an enum resolves to { value, name, enumType }, so use enum.name, never the raw int. Every row keeps its sedisId (do not conflate Comps). Use count: false for cheap bulk paging. Example: sedisIdIn 'PU-1,PU-2', parameterCode 'NX71', fromDate '2016-01-01', toDate '2026-12-31'. Tenant-scoped to your data; read-only — never writes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-indexed result page (first page = 1), e.g. 1.
countNofalse (default) skips totalCount for cheaper high-volume bulk paging, e.g. false.
toDateNoInclusive upper ISO date bound (yyyy-MM-dd), e.g. '2026-12-31'.
fromDateNoInclusive lower ISO date bound (yyyy-MM-dd), e.g. '2016-01-01'.
pageSizeNoRows per page (v2 default 50, max 500), e.g. 50.
sedisIdInYesComma-separated Comp sedisIds to fetch (multi-value), e.g. 'PU-1,PU-2'.
parameterCodeNoCompParameter code from fastighetsbenchmark_find_parameter; omit for all parameters, e.g. 'NX71'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesSelf-describing CompDatum rows — one per Comp+parameter+valueDate; dataType + sedisId kept on every row.
pageYesThe page you are on (1-indexed).
pageSizeNoRows per page used for this response.
totalCountNoTotal matching rows across all pages; null/absent when count=false (v2 omits the key).
totalPagesNoTotal page count; null/absent when count=false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / properties / data / items / properties / valueDate / description
      Previous value: -"ISO date (yyyy-MM-dd) of the period the value applies to (part of the natural key), e.g. '2025-12-31'."New value: +"ISO date (yyyy-MM-dd) of the period the value applies to (part of the natural key), e.g. '2025-12-31'. Usually 31 December, but it can be any quarter-end (e.g. '2026-06-30') — do NOT assume one row per year; flows on a quarter-end are rolling 12 months."
  2. Changed8 schema fields changedv1.1.6
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / properties / data / items / properties / boolean / anyOf
      Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / data / items / properties / boolean / type
      Added value: +[
+  "boolean",
+  "null"
+]
    • removedOutput schema / properties / data / items / properties / date / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / data / items / properties / date / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedOutput schema / properties / data / items / properties / figure / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedOutput schema / properties / data / items / properties / figure / type
      Added value: +[
+  "number",
+  "null"
+]
  3. First observedv1.1.5

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuine behavioral context (rows are self-describing via dataType, enum resolves to {value,name,enumType}, count:false enables cheap bulk paging). It only partially covers return/paging mechanics, but output schema carries that burden.

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-loaded with the scope and the flow position, and every sentence carries signal. Slight redundancy in repeating 'read-only — never writes' at both the start and end keeps it from a 5.

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?

Given an output schema exists, return values need not be re-explained; the description covers inputs, sourcing, ordering in the flow, and the dataType self-description pattern. Nothing essential for correct invocation is missing.

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, but the description adds real meaning: comma-separated multi-value sedisIdIn, the source of parameterCode, the ISO date range semantics, and a concrete worked example. It goes beyond restating the schema.

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 verb and resource ('Pull the actual benchmarking numbers (CompDatum time-series) for one or more Comps'), scoping it to Comps and distinguishing it from the search/list siblings. An agent can immediately tell what this returns versus the discovery tools.

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 positions this as 'the FINAL step of the §8 A6 flow' and names the three upstream tools that supply sedisId plus find_parameter for parameterCode. It gives the exact when-to-use and the dependency chain, leaving no routing inference.

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