Skip to main content
Glama
Sign In
Nabu

Nabu

by arvicco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Cuneiform sign desk

nabu_signs
Read-only

Resolve ATF transliterations token by token into cuneiform sign identities, sign names, and Unicode codepoints via the Oracc Sign List, with explicit ambiguity and encoding status.

Instructions

The cuneiform sign desk (P53-2): ATF transliteration resolved token by token through the local Oracc Sign List into sign identities — value → sign name → Unicode codepoint(s). Give EXACTLY ONE of: urn — a passage or document urn from the ATF corpora (cdli/oracc/ebl/etcsl; e.g. urn:nabu:cdli:p469841 — language read from the row, the catalog opened read-only) — or text — raw ATF transliteration (lang optional). C-ATF ASCII folds apply (sz→š, s,→ṣ, t,→ṭ, u2→u₂); dialect: "etcsl" adds the ETCSL romanization (c→š, j→ŋ), auto-selected for etcsl urns. Every token carries ONE honest status: deterministic · qualified (valueₓ(SIGN), the explicit sign resolved) · ambiguous (ALL candidate signs listed, never one silently) · no-codepoint (sign resolved, honestly unencoded upstream) · broken (x, [...]) · unknown (not in the OSL — said plainly). Determinatives are unbraced and flagged. The sign list adds IDENTITY, not curriculum. Bounded (default 40 lines, max 200); the restricted-exclusion stance applies to urn mode. sign_list carries the OSL license envelope; urn mode also carries the text's license_class.

Input Schema

NameRequiredDescriptionDefault
urnNoA passage or document urn out of the ATF corpora (urn:nabu:cdli:p469841, urn:nabu:oracc:…). Exactly one of urn/text.
langNoLanguage filter for %lang-qualified sign readings (sux, akk, …); urn mode defaults to the passage's language.
textNoRaw ATF transliteration text (one or more lines). Exactly one of urn/text.
dialectNoTransliteration dialect fold: etcsl (c→š, j→ŋ). Auto for etcsl urns; default C-ATF otherwise.
max_linesNoMaximum transliteration lines resolved per response.
include_restrictedNoAlso serve research_private/restricted material. Default false and deliberately so: this surface must never leak private or license-restricted texts casually. Set true only when the requester understands and will honor the restriction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds substantial behavioral context: every token carries one of the named statuses, ambiguous cases list all candidates, determinatives are unbraced and flagged, line output is bounded, and license envelopes are disclosed. It also explains the restricted-exclusion stance without contradicting the read-only annotation.

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 front-loaded and dense, with purpose stated before the mode constraints. Most sentences earn their place, but the parenthetical status taxonomy and packed punctuation make it slightly harder to scan than necessary.

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 carries the burden of explaining returned statuses, identity output, determinative handling, bounds, and license/restriction information. It is complete enough for a complex token-resolution tool with six parameters and a read-only safety profile.

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 all six parameters. The description still adds meaningful semantics for urn mode (language read from the row, catalog opened read-only), dialect folding rules, automatic ETCSL selection, and the caution around include_restricted.

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?

States a specific verb and resource: ATF transliteration is resolved token by token through the Oracc Sign List into sign identities, with the value → sign name → Unicode codepoint chain made explicit. The urn/text modes clarify scope, though the description does not explicitly contrast the tool with sibling nabu_char or other resolution tools.

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?

Specifies that the caller must give exactly one of urn or text, explains optional lang/dialect behavior, notes automatic ETCSL mode for etcsl urns, and gives a clear restriction on include_restricted. It lacks explicit sibling alternatives, but the usage conditions for this tool are clear.

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