Skip to main content
Glama

Anachronism Guard

archive_cultural_anachronism
Read-only

Check a list of colour entries for anachronism risk. Detects whether the primary source date falls outside the requested period, whether the archive is a known modern source (RacingSilks, FootballStrips), and returns a period_relevance score and safe phrasing. Essential for historical documents: prevents a 2011 Jockey Club racing silk registration being presented as Georgian evidence. Returns anachronism_risk (none/low/medium/elevated/high), period_relevance score 0-1, safe_phrasing, and unsafe_phrasing for each entry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entriesYesColour entries to check
period_endNoEnd year e.g. 1830
period_startNoStart year e.g. 1714
target_periodNoPeriod description e.g. 'Georgian England 1714-1830'

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the bar is lower. The description adds useful behavioral context: it detects whether primary_source date falls outside the period, flags known modern archives (RacingSilks, FootballStrips), and returns specific fields (risk level, period_relevance, safe/unsafe phrasing). This goes beyond the annotation without contradiction.

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 composed of four purposeful sentences covering definition, detection logic, a use-case example, and output fields. No wasted words, though it is a bit longer than strictly necessary.

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 an output schema and read-only annotation present, the description adequately explains the tool's role and return values. It could be more explicit about expecting entries to contain archive and primary_source fields, but that is inferable from the schema.

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 covers 100% of parameters, so baseline is 3. The description adds semantic value by explaining that 'archive' values like 'RacingSilks' are known modern sources and linking 'primary_source' to date checking, giving meaning beyond the schema's bare descriptions.

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 states a specific verb ('check') and resource ('colour entries') and defines the exact risk detection criteria (source date vs period, known modern archives). It clearly distinguishes from sibling tools like archive_coverage_gap or colour_cultural_risk by focusing on anachronism, with a concrete example.

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?

The description provides clear usage context: 'Essential for historical documents' and a tangible example of a 2011 racing silk being misdated as Georgian. However, it does not explicitly mention alternatives or when NOT to use the tool, which would elevate it to a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

Multiple tool clusters have unclear boundaries: colour_passport, colour_dna, colour_metrics, and colour_cultural_risk overlap heavily; palette_extract, extract_image_colours, image_palette, and ingest_image cover similar image-colour extraction territory; and compound tools like design_session, image_brief, session_brief, and archive_report_brief duplicate chains of component tools. The descriptions are detailed and occasionally state 'use this instead of X', but an agent still faces many near-duplicate choices.

Naming Consistency3/5

Names are consistently snake_case and often use domain prefixes (colour_, palette_, archive_, brand_, accessibility_), but verb placement is mixed: some are verb_noun (extract_image_colours, query_hex, style_match), others are noun_verb (colour_dna, palette_generate, brand_audit), and a few standalone names (ui_states, tool_guide, meta_capabilities) don't fit either pattern. The convention is readable but not uniform.

Tool Count1/5

At 88 tools, this is far beyond the reasonable well-scoped range and exceeds the 50+ extreme mismatch threshold. Many tools are compound wrappers that consolidate chains of simpler tools, adding redundancy and cognitive load rather than genuine coverage.

Completeness5/5

For the apparent domain, the tool surface is extremely comprehensive: colour extraction, analysis, naming, accessibility, cultural/provenance research, palette generation, brand systems, interior design, ecommerce copy, image briefs, project lifecycle, exports, and diagnostic tools are all present. Persistent objects have list/get/versions/delete/export support, so there are no obvious dead ends.

Resources