koine_provenance
Lineage of a KOINE piece from the on-chain derivation graph: parents, full ancestry, and downstream adoption (which pieces build on it).
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | token id |
DAEMON — on-chain generative art (8004 NONCE + KOINE)
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the data source and output scope, and clearly implies a read-only query. However, it does not mention error behavior, traversal limits, ordering, or the exact response structure.
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?
One tightly worded sentence that front-loads the purpose, then gives concrete output categories. Every part of the sentence adds useful information with no filler.
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?
Despite having no output schema, the description conveys the key return categories: parents, full ancestry, and downstream adoption. It is adequate for a simple one-parameter lookup, though edge-case behavior and output details are not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single `id` parameter as a token id, so schema coverage is 100%. The description adds no additional parameter semantics, but none are necessary at this baseline.
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 clearly identifies the operation: retrieving lineage/provenance of a KOINE piece from the on-chain derivation graph. It enumerates the concrete outputs—parents, full ancestry, and downstream adoption—which distinguishes it from siblings like koine_get_piece or koine_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent can infer this tool is for provenance/lineage questions. However, there is no explicit statement of when to prefer it over alternatives or when not to use it, so the routing guidance remains implicit.
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
A4/5.0
Disambiguation5/5
The koine_ and nonce_ prefixes cleanly separate two distinct collection workflows, and within each prefix every tool addresses a unique action or resource. Even the two verify tools are easily distinguished by collection prefix and their exact verification behavior.
Naming Consistency4/5
Tool names share a clear collection-prefix snake_case scheme, making grouping and selection predictable. However, not every name follows the same verb_noun form—info, census, spec, listings, and provenance are noun-style while mine, get, list, and verify are verb-style—so the pattern is consistent but not perfectly uniform.
Tool Count5/5
13 tools is well-scoped for a server covering two distinct on-chain art collections with read, discovery, verification, and minting workflows. Each tool maps to a real operation, with no obvious filler or redundant entries.
Completeness4/5
The NONCE half covers the full lifecycle well: spec, mine, mint_packet, verify, info, census, and get_piece. The KOINE half covers discovery, provenance, listings, and verification, but the only acquisition route is external Seaport fulfillment, with no KOINE purchase or fulfillment packet equivalent to nonce_mint_packet—a minor but real gap.