Skip to main content
Glama

tokenprune_wasm_trim

Read-onlyIdempotent

Prunes TypeScript and JavaScript source via AST parsing, extracting public interfaces, signatures, and exports while summarizing implementations to cut LLM context tokens 50%-70% preserving structure.

Instructions

Prunes TypeScript and JavaScript source code using AST parsing to extract public interfaces, type signatures, and exports while collapsing method implementations into concise summaries. Saves 50%-70% of LLM context window tokens without losing structural semantic information. Use when: Feeding large codebase files or libraries into LLM prompts for high-level architecture reasoning or planning. Do not use when: Auditing git diffs for security vulnerabilities or linting container configurations. Alternative: Use agentpr_guard_audit for PR security verification, or dockerlean_wasm_audit for container optimization. Execution: Runs locally in-memory (<10ms), read-only, idempotent, zero network calls, zero telemetry, air-gapped deterministic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sourceCode": "<sourceCode>"
    },
    "name": "tokenprune_wasm_trim"
  }
}

Input Schema

NameRequiredDescriptionDefault
filenameNoSource filename with extension for AST dialect resolution (e.g., 'service.ts', 'component.tsx'). Defaults to 'source.ts'.
licenseKeyNoOptional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).
sourceCodeYesRaw TypeScript or JavaScript file content to prune and condense.

Output Schema

NameRequiredDescriptionDefault
roiNoticeYesHuman-readable summary of prompt efficiency gains.
tokensSavedYesEstimated number of LLM prompt tokens saved by AST pruning.
prunedContentYesCondensed TypeScript/JavaScript content preserving signatures and interfaces.
savingsRatioPercentYesPercentage of tokens pruned from original source (0-100).
estimatedCostSavingsUsdYesEstimated USD savings per LLM call at reference prompt rates ($3/1M tokens).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.6
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / filename / description
      Previous value: -"Filename for context (e.g. service.ts)"New value: +"Source filename with extension for AST dialect resolution (e.g., 'service.ts', 'component.tsx'). Defaults to 'source.ts'."
    • addedInput schema / properties / licenseKey
      Added value: +{
      +  "description": "Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).",
      +  "type": "string"
      +}
    • changedInput schema / properties / sourceCode / description
      Previous value: -"Source code content to prune"New value: +"Raw TypeScript or JavaScript file content to prune and condense."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "estimatedCostSavingsUsd": {
      +      "description": "Estimated USD savings per LLM call at reference prompt rates ($3/1M tokens).",
      +      "type": "string"
      +    },
      +    "prunedContent": {
      +      "description": "Condensed TypeScript/JavaScript content preserving signatures and interfaces.",
      +      "type": "string"
      +    },
      +    "roiNotice": {
      +      "description": "Human-readable summary of prompt efficiency gains.",
      +      "type": "string"
      +    },
      +    "savingsRatioPercent": {
      +      "description": "Percentage of tokens pruned from original source (0-100).",
      +      "type": "number"
      +    },
      +    "tokensSaved": {
      +      "description": "Estimated number of LLM prompt tokens saved by AST pruning.",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "tokensSaved",
      +    "savingsRatioPercent",
      +    "prunedContent",
      +    "estimatedCostSavingsUsd",
      +    "roiNotice"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, and the description partly repeats those ('read-only, idempotent'). It does add genuine new traits: in-memory local execution under 10ms, zero network calls, zero telemetry, deterministic output, and an expected 50-70% token reduction. It omits any mention that a license key gates 'Pro' behavior, which is left for the schema to imply.

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?

Front-loaded with the core action, then cleanly split into Use when / Do not use when / Alternative / Execution blocks. Slightly over-stuffed with unverifiable marketing numbers ('Saves 50%-70%... without losing structural semantic information'), but few sentences are pure waste.

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?

An output schema exists so return shape needn't be explained, params are fully documented, and safety/idempotency are covered. The one loose end is licensing: licenseKey is described as an optional Pro key, but the description never explains whether or what functionality is gated, which matters in an air-gapped offline context.

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 each of the three parameters carries a clear description, so the schema already does the heavy lifting. The description adds no filename/AST-dialect or license semantics beyond what is in the schema, which is the expected baseline when coverage is complete.

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 ('Prunes TypeScript and JavaScript source code using AST parsing') and names concrete outputs (public interfaces, type signatures, exports, collapsed method bodies). The alternative sentence explicitly distinguishes it from agentpr_guard_audit and dockerlean_wasm_audit, so an agent can route correctly 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 Guidelines5/5

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

Explicit 'Use when' (feeding large files into LLM prompts for architecture reasoning) and 'Do not use when' (git diff security auditing, container linting) sections, plus named alternatives for the excluded cases. This is the full when/when-not/alternative pattern.

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