Skip to main content
Glama
Sign In
Commons

Commons

by Neoo-Blue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

fact_history

Retrieve a subject's fact validity timeline from valid_from to valid_to, with optional project and predicate filters, to track when each fact applied.

Instructions

Full validity timeline of a subject's facts (valid_from -> valid_to).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subject": "<subject>"
    },
    "name": "fact_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectNo
subjectYes
predicateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.38.0

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and says almost nothing: ordering of the timeline, whether expired/superseded facts are included, whether it is scoped to the current project by default, and cost/pagination are all unstated. Only the valid_from -> valid_to framing hints at the shape of the result.

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?

A single tight sentence with the resource and temporal range front-loaded; nothing is padded. It is under-specified rather than verbose, which costs it little here.

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

Completeness2/5

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

For a three-parameter tool with no annotations and no output schema, the description should say what the returned timeline contains and how filters interact. As written, an agent must guess the semantics of the optional parameters and the default scope.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must explain the three parameters and does not. It implies subject-based lookup but never mentions the project scoping or what the optional predicate filter does (single predicate timeline vs. all facts).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely: a subject's fact validity timeline, with the (valid_from -> valid_to) range clarifying it is a temporal history. It reads as a noun phrase rather than a verb, and never explicitly names the siblings it differs from (fact_get, fact_set, why), but an agent can still infer this is the historical read.

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

Usage Guidelines2/5

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

There is no when-to-use guidance. Nothing says to call this instead of fact_get for the current value, or when the timeline beats a search call, and no prerequisites or exclusion cases are given.

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