Skip to main content
Glama
talonicdev

talonic-mcp

Official
by talonicdev
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

Get a field's concept card

talonic_get_field
Read-onlyIdempotent

Retrieve a field's concept card with definition, synonyms, occurrence stats, and value examples to verify a field's meaning or match a user's field name to the live concept.

Instructions

Get the CONCEPT CARD for one Field Registry field: what it means (curated description + extraction instruction), its synonyms and aliases, maturity, where it occurs (document/occurrence counts, first/last seen, document-type spread), its value distribution (top values with counts, distinct count, examples), schema usage, and identity links (superseded_by, absorbed concepts).

USE WHEN: you must decide whether a field is the right concept for a question, need example values or the value shape before writing a filter, or hold a field NAME from the user and need the live concept behind it. NOT FOR: listing many fields (talonic_list_fields) or reading every value (talonic_field_values).

ARGS: exactly one of field_id or name. Names are resolved through canonical name → spelling fold → merge aliases → synonyms (then case-insensitive fallbacks) and followed to the live concept; the response says which arm matched. include_history: true appends the curation trail (merges, renames, maturity moves). RETURNS: the card { id, canonical_name, maturity, data_type, definition, identity, occurrence, values, usage, links } plus resolution when a name was given and history when requested.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoField NAME instead of an id — resolved through canonical name, synonyms, merge aliases and the registry's spelling fold, then followed to the live concept. Use the user's wording ('Invoice No', 'Vertragsnummer').
field_idNoField UUID (from talonic_list_fields / talonic_search).
include_historyNoAppend the concept's curation history (tier changes, merges, renames), newest first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.76

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive hints, but the description adds meaningful behavioral detail beyond those: the name resolution order, the fact that the response reports which resolution arm matched, and the effect of include_history. This is context annotations cannot convey.

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 structured into clear labeled sections (USE WHEN, NOT FOR, ARGS, RETURNS) and every sentence carries meaningful information. Nothing is redundant with the schema, and the content is front-loaded with the core purpose before usage guidance.

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?

For a tool with no output schema, the description supplies the full response shape, resolution behavior, history behavior, and sibling routing. Combined with 100% schema coverage and strong annotations, an agent has everything needed to select and invoke this tool correctly.

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 schema already documents each parameter in detail. The description adds the crucial exclusivity rule ('exactly one of field_id or name') and clarifies that resolution follows to the live concept, plus the response's resolution field behavior, which goes beyond the 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?

The description states a specific verb and resource ('Get the CONCEPT CARD for one Field Registry field') and enumerates exactly what the card contains. It also explicitly distinguishes itself from siblings by naming talonic_list_fields and talonic_field_values in the NOT FOR clause.

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?

USE WHEN gives three concrete decision triggers, and NOT FOR names the two sibling tools to use instead. This leaves no ambiguity about when to select this tool over alternatives.

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