Skip to main content
Glama

import_facts

Bulk-save up to 200 facts at once, deduping and validating each. Run a dry run first to preview accepted, rejected, or superseded items before writing.

Instructions

Bulk-save facts (up to 200), e.g. to curate the legacy facts. Each item is an object with the same fields as remember_fact: text, kind, category, and optional severity, scope, supersedes, expires_days, source. Every single-write rule applies to every item, in order (an item is also deduped against items accepted earlier in the batch). Returns {accepted, deduped: [{input, matched_existing_id}], rejected: [{input, reason}], superseded: [ids], dryRun}. dry_run=true returns the identical report and writes nothing — use it first, show the user, then run it for real.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
factsYes
dry_runNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the 200-item limit, in-order processing, deduplication against earlier accepted items, return fields, and that dry_run writes nothing while returning an identical report. It does not enumerate the referenced 'single-write rules' or mention permissions/rate limits, so it is strong but not fully self-contained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficiently front-loaded: bulk-save purpose first, then item shape, then batch rules, then return shape and dry-run recommendation. Every sentence supplies operational information.

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?

No output schema or annotations exist, so the description must cover behavior, parameters, and returns. It does: it defines batch limits, item fields, dedupe/order behavior, the full return shape, and dry_run semantics, which is complete enough for an agent to call it correctly.

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

Parameters5/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 compensate and does: it lists the fields for each fact item (text, kind, category, severity, scope, supersedes, expires_days, source) and explains dry_run's behavior and reporting. This adds substantial meaning beyond the generic array/object and boolean 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: 'Bulk-save facts (up to 200)'. It also distinguishes the tool from sibling remember_fact by describing bulk items with the same fields and by noting batch ordering and deduplication behavior.

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?

Gives a clear use case ('curate the legacy facts') and an explicit dry-run workflow: use dry_run=true first, show the user, then run it for real. It implies single writes should use remember_fact by contrasting bulk-save with per-item single-write rules, though it does not state that alternative explicitly.

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