Skip to main content
Glama
bloriner

Terse

by bloriner
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Terse

License: Apache-2.0 Tests Python Token ratio

An AI-native code language: a machine-designed prefix HIR for AI coding agents.

AI agents write human-designed languages — verbose, infix, and syntax-error-prone. Terse is a canonical prefix intermediate representation designed for machines: fixed-arity ops, one spelling per construct, structured errors built for repair loops, and a surface syntax measured to be token-cheaper than Python.

Why

Every mainstream language was designed for human eyes: infix operators with precedence tables, multiple spellings for the same construct (if vs ternary vs statement), significant whitespace, and error messages written for people. When an AI coding agent emits code, each of those is a failure mode — a misplaced paren or a precedence guess costs a repair iteration.

Terse removes the decisions a model shouldn't have to make:

  • Prefix, always. (add a (mul b c)) — the op comes first, so the structure of every form is known after one token. No precedence tables, no associativity, exactly one way to parenthesize anything.

  • Canonical. One spelling per construct, enforced by the parser. if is always prefix; true/false/null are always lowercase; bare symbols are always variable references. Canonicality shrinks the output distribution a model must learn and makes diffs, caches, and dedup exact.

  • Dense. The v0.2 syntax was shaped by cl100k_base measurements: juxtaposed parens, head-position calls, n-ary if, and fusion ops for hot patterns. Reference solutions measure 0.60–1.00× Python tokens across 8 bench tasks (see bench/).

  • Fixed arities, checked at parse time. (add 1) fails with E103 arity-mismatch before anything runs.

  • Structured errors for repair loops. Every failure is a TerseError with a stable code (E100–E300), phase, op, source position, expected/got, and a concrete hint. Feed err.to_dict() back to the model and the fix is usually one shot.

  • Constrained-decoding grammar. terse/grammar.gbnf is a GBNF grammar for the full language — under constrained decoding, syntax errors become impossible, and the only remaining failures are semantic ones the error protocol already covers.

Related MCP server: @hyperscript-tools/mcp-server

Quickstart

import terse

# Parse: surface syntax -> AST tuples
ast = terse.parse("(let x 40 (add x 2))")   # ("let", "x", 40, ("add", ("var", "x"), 2))

# Run: (value, printed_output)
value, output = terse.run(ast)               # (42, "")

# Transpile: AST -> readable Python, verified by exec
src = terse.to_python(ast)
ns = {}
exec(compile(src, "<terse>", "exec"), ns)
ns["_terse_result"]                          # 42

CLI:

python -m terse run examples/fib.terse          # run; prints program output, "=> <value>" to stderr
python -m terse run prog.terse --gas 1000000   # with a custom gas budget
python -m terse transpile prog.terse           # print the generated Python
python -m terse check prog.terse               # parse only; prints OK or error JSON (exit 0/1)

Errors are machine-readable JSON on stderr:

$ python -m terse check broken.terse
{"code": "E103", "phase": "parse", "op": "add", "pos": {"line": 1, "col": 1, "index": 1}, ...}

A taste of the language:

; recursive fibonacci via def
(def fib(n)(if(lt n 2)n(add(fib(dec n))(fib(dec(dec n))))))
(print(fib 10))                               ; => 55

; fizzbuzz: n-ary if, divisibility op, juxtaposed parens
(for i(range 1 21)(print(if(divis i 15)"fizzbuzz"(divis i 3)"fizz"(divis i 5)"buzz"i)))

; wordcount: fold + inc, no pre-seeding needed
(print(fold(acc w)(dict)(list "a" "b" "a")(inc acc w)))  ; => {'a': 2, 'b': 1}

Repo layout

terse/               the language package (pure Python 3.10+, stdlib only)
  parser.py          .terse surface syntax -> AST (tokenizer + recursive descent)
  errors.py          TerseError hierarchy + the E100–E300 code registry
  interp.py          tree-walking interpreter: run/run_source, gas sandbox
  to_python.py       AST -> readable Python transpiler (emits _terse_result)
  grammar.gbnf       GBNF grammar for constrained decoding
  __main__.py        CLI: run / transpile / check
SPEC.md              the language specification (syntax, ops, semantics, errors)
examples/            8 sample programs + expected.json (exact expected stdout)
bench/               TTCP benchmark: `python -m bench.run` (8 tasks, token ratios)
tests/               pytest suite (160 tests)
mcp/                 MCP server: eval/transpile/tokens/parse as agent tools (stdio)
api/                 metered execution API: POST /meter -> HMAC-signed receipts (see notes/metered-api.md)
billing/             Stripe usage reporting: verify receipts, aggregate tokens-saved
                     per customer per month, report to billing meter events
                     (see billing/README.md for the honest status)
LICENSE              Apache-2.0

Key semantics: div is true division; and/or are n-ary and short-circuit; let is letrec for closures and def defines named (recursive) functions; put/push/inc are functional; print returns null; evaluation is gas-metered (E205 on exhaustion). See SPEC.md for the full contract.

Status

v0.3 — 160 tests green. New: fmt string interpolation ((fmt "hi {}" name) — ties Python f-strings, beats cat on sentences; see notes/density-v0.3.md for the measured decision rule). Rejected after measurement: -> threading macro (13 tokens vs 9 nested — BPE doesn't fuse (->). v0.2 density ratios hold: 0.60–1.00× Python tokens across the 8-task benchmark, all stdout MATCH. MCP server (mcp/) exposes eval/transpile/token-count/parse as agent tools over stdio.

Roadmap

  • TTCP leaderboard — live in leaderboard/ (methodology, scoring tool, static page): models compete on token-efficiency vs Python across the 8 fixed bench tasks, stdout-verified. First-try validity with live repair loops is the defined-but-unmeasured second metric.

  • Paired training corpora: Terse↔Python parallel programs for fine-tuning.

  • Fine-tuning open models on Terse for direct generation.

  • More backends: additional transpile targets beyond Python.

License

Apache-2.0 — see LICENSE.

Available Tools

7 tools
terse_alias_clearB

Clear all session $aliases.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys session-scoped blast radius, but omits that the operation is destructive/irreversible, whether it affects only the current session vs persisted aliases, and what happens if no aliases are defined.

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?

One short sentence with zero waste and the target scope front-loaded. It is arguably too terse for a destructive no-argument operation, but nothing is padded or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter destructive tool with no annotations and no output schema, the description gives the operation and its scope but not the risk profile an agent needs before invoking it. The missing irreversibility warning keeps it at minimum-viable rather than complete.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline applies. The description usefully clarifies that the target set is all session aliases rather than a named subset.

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 ("Clear") and resource ("session $aliases"), scoped to session rather than global state. It is clearly distinguishable from a define or list operation by verb alone, though it never names or contrasts a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative is given. Nothing tells the agent whether this is a reset between runs, a cleanup step, or how it relates to terse_alias_define/terse_alias_list.

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

terse_alias_defineA

Define a session macro: $alias expands to the given Terse form everywhere it appears as a variable afterwards. Define a repeated subtree once, then write $alias (1-2 tokens) instead of the full form. $names are reserved for aliases — do not bind them with let/def/fn.

ParametersJSON Schema
NameRequiredDescriptionDefault
aliasYesAlias name, e.g. $1.
expansionYesTerse source the alias expands to.

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that aliases are session-scoped, expand everywhere the $name appears as a variable, and that $names are reserved ('do not bind them with let/def/fn'). It does not cover redefinition/overwrite semantics or error behavior, leaving meaningful gaps for a state-mutating define.

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?

Three sentences, core definition front-loaded, with the reserved-namespace warning last where it belongs. Mostly efficient, though the middle sentence partly explains the alias feature rather than this tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with full schema coverage and no output schema, the basics are covered and return values need no explanation. However, it omits what happens if an alias already exists or if the expansion is invalid, which an agent would want to know before calling.

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 both parameters are already documented (the $1 example for alias, 'Terse source' for expansion). The description restates that $alias maps to the given Terse form but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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: 'Define a session macro'. The session-scoped framing implicitly separates it from terse_alias_list and terse_alias_clear, but it does not name any sibling to sharpen the distinction.

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?

Gives a concrete use case ('Define a repeated subtree once, then write $alias... instead of the full form') that tells the agent when this tool is worthwhile. It stops short of explicit when-not guidance or routing to alternatives like terse_eval.

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

terse_alias_listA

List the session's defined $aliases and their expansions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'List' and scopes results to the session, which is useful. However, it says nothing about return structure, ordering, or whether it requires an active session, so behavioral disclosure is thin but adequate for a zero-parameter read.

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?

A single front-loaded sentence with no filler. Every word (session scope, aliases, expansions) earns its place.

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?

For a trivial zero-param list tool with no output schema, the description covers what is returned at a high level. A brief note on return shape would make it fully complete, but little is missing for correct invocation.

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?

There are zero parameters, so the baseline of 4 applies. The description correctly adds no parameter detail because none exists to explain.

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?

States a specific verb (list) and resource ($aliases with their expansions), scoped to the session. It is easily distinguishable from the sibling define/clear tools without opening any schema.

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?

The purpose implies when to use it (inspecting currently defined aliases), but there is no explicit when/when-not guidance or reference to alternatives like terse_alias_define or terse_alias_clear. Usage is inferred rather than stated.

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

terse_evalA

Evaluate Terse source with the tree-walking interpreter. Returns the result value (JSON-safe) and captured print output lines. Session $aliases (see terse_alias_define) are expanded before evaluation.

ParametersJSON Schema
NameRequiredDescriptionDefault
gasNoEvaluation gas limit (default 100000).
sourceYesTerse source code to evaluate.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape (JSON-safe result plus captured print output) and that session $aliases are expanded before evaluation, but it is silent on what happens when the gas limit is exhausted, whether evaluation is isolated/side-effect free, and how errors surface. That is meaningful disclosure but incomplete for an execution tool.

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?

Three tight sentences, front-loaded with the core action, then return shape, then the alias caveat. No filler and each sentence adds distinct information.

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 no output schema, the description correctly compensates by describing the return value and print output lines. With no annotations, it partially covers behavior via alias expansion, but omits gas-exhaustion and error semantics. Complete enough for a simple eval tool, though not fully self-sufficient.

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 coverage is 100% and the schema already documents both 'source' and the 'gas' limit with its default and minimum, so the baseline is 3. The note that session $aliases are expanded before evaluation adds a genuine behavioral nuance about how 'source' is interpreted, but it is the only addition and gas behavior is left entirely to 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?

States a specific verb and resource ('Evaluate Terse source') and names the mechanism ('tree-walking interpreter'), which distinguishes it from sibling tools like terse_parse, terse_transpile, and terse_tokens that operate on source without executing it. An agent can tell this is the execution tool without opening any schema.

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 by the verb 'evaluate' and reinforced by the reference to terse_alias_define for alias behavior, which tells the agent this tool consumes aliases set up elsewhere. However, there is no explicit when-to-use guidance against terse_parse/terse_transpile or any statement of prerequisites, so the agent must infer the selection logic.

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

terse_parseA

Parse Terse source and return the AST as JSON (tuples become lists). Session $aliases are expanded first.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesTerse source code to parse.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses two non-obvious behaviors: JSON conversion turns tuples into lists, and session $aliases are expanded before parsing (a dependency on session state set by terse_alias_define). It says nothing about failure behavior on invalid source or whether parsing mutates session state.

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?

A single sentence with the primary action front-loaded, followed by the two caveats that actually change agent expectations (tuple-to-list, alias expansion). 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?

There is no output schema, so the description correctly characterizes the return value as an AST in JSON and flags the tuple/list representation quirk. The alias-expansion note covers the session-state interaction, leaving only error/edge-case behavior undocumented for a single-parameter tool.

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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents 'source'. The description adds no syntax, format, or encoding detail beyond what the schema provides, making the baseline 3 appropriate.

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?

States a specific verb (parse) and resource (Terse source) plus the exact output form (AST as JSON), which cleanly separates it from terse_tokens (lexing), terse_transpile (compilation) and terse_eval (execution) without naming them. An agent can pick this tool from the sibling list on purpose alone.

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 by the output ('return the AST'), so an agent can infer this is the tool for structural inspection rather than evaluation or transpilation. However, there is no explicit when-to-use, when-not-to-use, or named alternative, and no note about whether parsing is side-effect free.

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

terse_tokensA

Count tokens of Terse source with tiktoken cl100k_base; falls back to a ceil(len/4) character estimate when tiktoken is unavailable.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesTerse source code to measure.

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose two behaviorally important facts: the exact encoding used and a deterministic fallback (ceil(len/4)) when tiktoken is unavailable, which directly affects result accuracy. It does not mention performance or that results are approximate in fallback mode in absolute terms, but the key correctness caveat is present.

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?

A single tight sentence that front-loads the primary behavior (tiktoken cl100k_base) before the fallback caveat. Every clause earns its place, 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?

For a one-parameter, annotation-free, no-output-schema tool, the description covers purpose, encoding, and a fallback path. The only minor gap is that it does not state that the return value is a single integer count, though 'Count tokens' strongly implies it.

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 single 'source' parameter is already fully documented in the schema. The description adds no syntax, size limits, or format detail beyond restating that the input is Terse source, so the baseline 3 applies.

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?

States a specific verb (count tokens) and resource (Terse source) and even names the exact tokenizer (tiktoken cl100k_base). This is unmistakably distinct from the parse/transpile/eval/alias siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is offered — nothing about why an agent would count tokens (context budgeting, cost estimation) or any alternative for measuring size. Usage must be inferred entirely from the tool name and purpose.

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

terse_transpileC

Transpile Terse source to readable, executable Python.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesTerse source code to transpile.

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether transpilation requires aliases to be defined first (the alias_* siblings imply shared state), whether the operation is pure/read-only, what happens on invalid source, or what the returned value looks like.

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?

A single front-loaded sentence with zero padding; nothing is wasted. It is arguably terse to the point of under-specification, but as structure and economy go it is well formed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-input, one-output conversion tool this is nearly sufficient, but with no output schema the description should state what is returned (the Python source text? a status?) and whether alias context affects the result. Those gaps leave the agent guessing about the return contract.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'source' fully. The description adds no syntax, format, or size guidance beyond the schema, which is the expected baseline 3 when structured data does the heavy lifting.

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 ('Transpile') and resource ('Terse source') plus the output target ('readable, executable Python'), which implicitly separates it from terse_eval (which would execute) and terse_parse (which would only parse). It stops short of naming siblings or stating the relationship explicitly, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative tool is mentioned. With terse_eval and terse_parse in the sibling set, an agent is left to infer on its own that this converts source rather than executing or inspecting it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updates
    • First observedterse_alias_clear
    • First observedterse_alias_define
    • First observedterse_alias_list
    • First observedterse_eval
    • First observedterse_parse
    • First observedterse_tokens
    • First observedterse_transpile

This server cannot be deployed

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct operation: eval (run code), parse (produce AST), transpile (emit Python), tokens (count), and three clearly-scoped alias operations. There is no meaningful overlap—parse vs eval vs transpile are different outputs despite all consuming Terse source. An agent can pick the right tool unambiguously.

Naming Consistency4/5

Every tool carries the terse_ prefix, which gives strong family cohesion. The alias group (terse_alias_list/define/clear) uses a group_verb form while the core operations (terse_eval/parse/transpile/tokens) use prefix_verb, a minor deviation but still readable and predictable.

Tool Count5/5

Seven tools is well within the ideal range and each earns its place: four core language operations plus three alias lifecycle tools. Nothing feels padded or missing at the count level.

Completeness4/5

The language-tooling domain is well covered: eval, parse, transpile, token counting, plus alias define/list/clear. The one gap is granular alias management—there is no way to remove or inspect a single alias, only clear-all—but this is a minor workaroundable omission.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers