mcptoon

Overview Schema Source Related Servers Discussions Admin

Index a tool set by name only

demo_build_tool_manifest

Read-onlyIdempotent

Builds a names-only index of MCP tool definitions, one line per server, and reports the estimated token drop versus the supplied text.

Instructions

Reduces a set of MCP tool definitions, grouped by server or flat, to the names-only index mcptoon puts in front of an agent — one line per server listing its tool names, no schemas — with the estimated token drop against the text you supplied. ...

Input Schema

TableJSON Schema

Name	Required	Description	Default
`manifest`	Yes	Either {server_name: [tool_definition, ...]} or a flat [tool_definition, ...] array, as JSON text; string entries are accepted as bare tool names and put under their group's name.
`include_slim`	No	When true, also returns each tool's slim definition under 'slim_tools'; omitted or false returns the name index only. Has no effect on the reported token drop, which always measures the name index.

Output Schema

TableJSON Schema

Name	Required	Description
`name_index`	Yes	The compact index: server, then its tool names.
`slim_tools`	No	Compacted definitions; present only when asked for.
`tool_count`	Yes	Names indexed across every server.
`full_tokens`	Yes	Tokens the submitted manifest would have cost.
`empty_servers`	Yes	Servers that contributed no names at all.
`reduction_pct`	Yes	Percentage saved, zero when nothing was indexed.
`skipped_entries`	Yes	Positions of entries carrying no usable name.
`simplified_tokens`	Yes	Tokens the name index costs instead.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.14Sep 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond them: it emits a names-only index plus an estimated token drop measured against the supplied text, and notes include_slim does not affect that measurement.

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 front-loaded sentence that leads with the transformation and the resulting artifact, with no filler. It is slightly long and the trailing ellipsis suggests the text may be cut off, but the core content is efficient.

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 full schema coverage, an output schema, and complete annotations, the description need not explain return values or safety. It covers inputs, output shape, and the token-drop metric adequately; the only gap is the absence of sibling-routing guidance.

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 reiterates the names-only index and token-drop behavior but adds no syntax or format detail about the 'manifest' string or 'slim_tools' beyond what the schema already documents.

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 (reduces/indexes) and resource (a set of MCP tool definitions, grouped by server or flat) and names the exact output artifact: the names-only index, one line per server, no schemas. This distinguishes it from siblings like demo_simplify_tool_schema (slim definitions) and demo_estimate_tokens.

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 description explains what the tool produces and the effect of include_slim, but never states when to choose it over the closest alternatives (e.g., mcptoon_manifest, demo_simplify_tool_schema, demo_estimate_tokens). Usage is implied by the output shape rather than stated.

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

Deploy Server