Skip to main content
Glama
DHEBP

dero-mcp-server

by DHEBP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

tela_inspect

Read-only

Identify a TELA contract on DERO by SCID and auto-detect whether it is an INDEX app manifest or DOC file contract, returning all DOC references and decoded metadata.

Instructions

Composite: fetch a TELA contract by SCID (DERO.GetSC code + variables) and parse it as either a TELA-INDEX-1 app manifest or a TELA-DOC-1 file contract, auto-detecting which standard it is from the stored keys. TELA is DERO's on-chain web-app platform: an INDEX is the app manifest (like package.json) and DOCs are the individual files (HTML/CSS/JS) stored on chain.

When to call: as the FIRST step whenever a user references a TELA SCID, a .tela dURL app, or asks "what is this TELA contract/app", "what files does this TELA app have", or "is this a TELA INDEX or DOC". PREFER this over dero_get_sc + manual parsing or explain_smart_contract: explain_smart_contract treats TELA contracts as generic DVM and its surface CAPS stored keys at 50, which silently drops DOCn entries on large manifests — tela_inspect reads the raw stringkeys directly so it enumerates ALL DOC references, and it decodes the TELA header/mods/commit schema the generic tool does not understand.

Input Requirements:

  • scid is REQUIRED. Must be 64 hex chars (the TELA contract id).

  • topoheight is OPTIONAL. Provide to inspect at a specific topo height; omit for the latest committed state.

Output: a discriminated union on kind. tela_index → { scid, topoheight, kind, index: { name, description, icon, durl, mods[], docs:[{position, key, scid, is_entrypoint, malformed}], doc_count, commit, version_history[], current_commit_hash, owner, updateable:'unknown', updateable_note, parse_notes[] }, narrative, related_docs }. tela_doc → { ..., doc: { filename, doc_type, sub_dir, durl, signature, content_embedded, code_size_bytes, immutable }, narrative, related_docs }. not_tela → { ..., kind:'not_tela', reason, observed:{ stringkey_sample[], stringkeys_total, has_code, markers[] }, narrative } — returned (NOT an error) when the SCID is unknown or lacks TELA markers. Updateability cannot be derived from chain state (ringsize is not in GetSC) so it is honestly reported as 'unknown'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scidYes64-char hex Smart Contract ID of a TELA-INDEX-1 or TELA-DOC-1 contract
topoheightNoOptional topo height; omit for the latest committed state

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / topoheight / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / topoheight / minimum
      Added value: +-9007199254740991
  2. Addedv0.4.8

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal read-only and non-destructive behavior, and the description adds substantial context beyond that: it reads raw stringkeys, auto-detects the standard, returns not_tela as a normal result rather than an error, and honestly reports updateability as unknown. This gives the agent a clear model of the tool's behavior and edge cases.

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 long but tightly organized: purpose, when to call, input requirements, and output shape. Every sentence adds useful information, and the critical usage guidance is front-loaded before the detailed output contract.

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?

Despite having no output schema, the description fully documents the discriminated union result shapes, the not_tela fallback, and the known limitation about updateability. Combined with the rich annotations and complete param schema, 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description repeats the scid and topoheight requirements but adds minimal extra meaning beyond the schema, such as clarifying that the SCID refers to a TELA contract. No meaningful parameter behavior is undocumented.

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 defines a composite fetch-and-parse action with a specific verb and resource, and names the exact TELA standards it detects. It distinguishes itself from generic tools like explain_smart_contract and dero_get_sc by explaining its specialized parsing behavior.

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?

The description explicitly states when to call as the first step for TELA-related queries, and explicitly says to prefer it over dero_get_sc plus manual parsing or explain_smart_contract. It also explains the limitation of the alternative, making the selection criterion actionable.

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