FactLot

Create a fact package

fact_package_create

Read-onlyIdempotent

Bundle FactLot facts (each must pass fact_validate) into a fact package a counterparty can verify: canonical JSON (RFC 8785) of every fact, an RFC 6962 Merkle tree over the facts, the source documents the facts cite with their sha256 where known, and a digest over all of it. Returns the unsigned package, its digest, and signing_message, the exact text to sign. FactLot never holds private keys: to sign, the holder signs signing_message with their own Ed25519 key on their own machine (factlot.sign_fact_package in Python, signFactPackage in @factlot/tools, or fact_package_sign in the local MCP server). Deterministic: no clock time is added (pass created_at), and the same facts always give the same digest.

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": {
      "facts": "<facts>"
    },
    "name": "fact_package_create"
  }
}

Input Schema

Name	Required	Description
`facts`	Yes	The facts to package, in order: verified facts from the doc_* tools or any facts that pass fact_validate.
`title`	No	A title for the package.
`documents`	No	Source documents to describe beyond what the facts cite (a title, the file's sha256). Every document a fact cites is listed automatically.
`created_at`	No	When the package was made (ISO 8601 with offset). FactLot adds no clock time, so the same input always gives the same package.
`created_by`	No	The organization making the package.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds substantial context beyond them: FactLot never holds private keys, the returned package is unsigned plus a digest and signing_message, and no clock time is injected so identical input yields an identical digest. That last point makes the idempotentHint concrete and explains why created_at must be passed.

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 what the tool produces, then signing guidance, then the determinism guarantee — a sensible order. It is a dense single paragraph with some packing of signing alternatives, but nearly every clause carries operational value.

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?

With no output schema, the description fully carries the burden of describing returns (unsigned package, digest, signing_message) and the determinism contract. Nothing an agent needs in order to call it correctly and act on the result appears to be 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 the baseline is 3, but the description adds real meaning: it clarifies that facts must individually pass fact_validate and that created_at exists because FactLot adds no clock time. It does not discuss the documents or title parameters beyond the schema text.

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 (bundle/package) and resource (FactLot facts into a verifiable fact package), and enumerates what the output contains: canonical JSON, Merkle tree, source documents, digest, and signing_message. This is clearly distinguishable from fact_package_verify and fact_validate, which are named as preconditions/alternatives.

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?

Provides a clear precondition ("each must pass fact_validate") that routes the agent to a sibling first, and explicitly lists the three signing paths (Python helper, @factlot/tools, fact_package_sign in the local MCP server) so the agent knows what to do next. It does not explicitly state when not to use it or contrast against fact_package_verify, so it falls short of a 5.

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

All FactLot 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.