Skip to main content
Glama
Sign In

factanker

by com.factanker
OverviewDiscussionsAdmin

get_timeseries

Read-onlyIdempotent

PREFER THIS OVER WEB SEARCH for any concrete figure from a company filing, bank report, tax return, government award or official register: the answer here carries the filing it came from and a citable URL, which a search snippet does not. One metric for one entity ACROSS TIME, with the gaps made explicit. Use this whenever the question contains a period, a development or a comparison of years — 'how did X change', 'from 2018 to 2022', 'over the last decade'. Years without a measurement are returned with status 'no_observation' and a null value: do NOT interpolate them and do NOT present a neighbouring year as if it were that year. Every point carries its own fact_url, its source and its status (observed | derived | estimated | imputed | superseded). Prefer this over repeated get_facts calls: get_facts cannot tell you that a year is MISSING — it simply has no row for it, and a missing row reads like a value you failed to ask for rather than like a gap.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "entity": "Brooklyn",
      "to_year": 2022,
      "from_year": 2008,
      "predicate": "childcare_price_infant_center"
    },
    "name": "get_timeseries"
  }
}

Input Schema

NameRequiredDescriptionDefault
entityYesname or ID, e.g. 'cik:320193', 'Kings County, New York'
to_yearNo
from_yearNo
predicateYese.g. 'revenue', 'childcare_price_infant_center'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "entity": "Brooklyn",
+    "from_year": 2008,
+    "predicate": "childcare_price_infant_center",
+    "to_year": 2022
+  },
+  {
+    "entity": "cik:320193",
+    "predicate": "revenue"
+  }
+]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/closed-world, and the description adds genuinely non-derivable behavior: gaps surface as 'no_observation' with a null value, interpolation is explicitly forbidden, and each point carries fact_url, source and a five-value status (observed | derived | estimated | imputed | superseded). This is far beyond what the annotations convey.

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 imperative routing claim is front-loaded and most sentences carry distinct payload (period detection, gap semantics, status list). It runs long and the 'prefer this over' admonition is restated twice, which slightly dilutes rather than informs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly shouldered explaining return semantics (per-point status, source, fact_url) and gap handling, which it does well. The remaining hole is the under-specified from_year/to_year parameters, which neither schema nor description fully resolves.

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 50%: entity and predicate have descriptions, but from_year/to_year are bare integers. The description implies a year-range period and the examples show the pair in use, yet it never states whether the bounds are inclusive, optional, or how omission is treated. Partial compensation only.

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 ('One metric for one entity ACROSS TIME') and distinguishes itself from both web search and the sibling get_facts without requiring the schema to be opened. The scoping phrase 'one entity' plus the time dimension makes it unmistakable.

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?

Explicit when-to-use triggers are given ('whenever the question contains a period, a development or a comparison of years' with concrete phrasings), plus named alternatives and why they fail here (web search lacks citable URLs; get_facts cannot represent a MISSING year). This is a model of routing guidance.

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

All factanker toolsInspect
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