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 comparable benchmarking time-series for one or more Comps by providing sedisIds, an optional parameter code, and a date range. Each row self-describes its data type so you can parse the correct value.

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. 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"
+]
  2. 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 carry readOnlyHint=true, so the safe-read trait is covered. The description adds genuinely useful behavioral detail beyond annotations: the self-describing dataType dispatch, the enum resolution rule (use enum.name, not the raw int), the warning not to conflate Comps, and the note that each row retains its sedisId. It also reaffirms read-only and tenant-scoped access. It doesn't document rate limits or pagination quirks beyond `count`, but for this tool that is a minor gap.

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 dense but purposeful; it front-loads the read-only nature time-series return shape, and a concrete example. It is longer than minimal but every sentence adds operational guidance. Slight redundancy with annotations ('Read-only' / 'Tenant-scoped') costs a point.

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?

The description is complete for a data-retrieval tool: it names the required inputs (`sedisIdIn`, `parameterCode`, dates), explains the self-describing `dataType` pattern, warns about enum handling and row identity, and gives a concrete example. With a rich output schema present, an agent has everything needed to call and interpret results.

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% and each parameter has a description, so the schema already carries good semantic weight. The description adds significant cross-tool semantics: it explains the provenance of sedisIds, the meaning and usage of dataType, the rule for enum handling, and the example values. The only weak spot is that the description doesn't map parameterCode omission behavior as clearly as the schema does, but overall it adds real value.

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 opens with a specific verb and resource ('Pull the actual benchmarking numbers (CompDatum time-series)') and clearly distinguishes this from sibling tools by naming it the FINAL step of the §8 A6 flow, with explicit references to the sibling tools that produce its inputs. An agent can tell exactly what this tool returns and how it fits in the workflow.

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?

The description explicitly maps the flow: use sedisIds from three named sibling tools, a parameterCode from fastighetsbenchmark_find_parameter, and an ISO date range. It also gives a concrete example and advises `count: false` for cheap bulk paging. This is exemplary usage guidance.

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