TTCraft MCP

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description still adds real behavior: it streams to disk rather than buffering in memory, and it refuses to overwrite unless explicitly requested, which directly explains the guard behind the overwrite flag. It does not mention export size limits or what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each carrying distinct information (what, when, safety behavior), with scope stated first. No filler or restatement of the title.

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

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

For a 3-parameter mutation tool with no output schema, the description covers the write destination, overwrite behavior, and streaming semantics. The remaining gap is what the call returns on success (the path? a manifest?) and whether the destination directory must already exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 33% — only table_id is documented. The description compensates for output_path by specifying it must be an absolute local ZIP path, and for overwrite by explaining the refusal-to-overwrite default. Adding return-value or path-validation detail would round this out.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (export), the exact resource set (whole table and assets), and the output artifact (absolute local ZIP path). This is cleanly separable from the inverse sibling archives_import without needing to open either schema.

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

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

Gives an explicit usage context: 'Useful as a backup before major edits.' That tells the agent when to reach for it, but there are no exclusions or named alternatives (e.g., when to prefer per-object export or archives_import for the reverse direction).

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

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

Annotations already flag destructive=true and idempotent=false, but the description adds material context beyond them: the admin requirement, that it reconnects the session after success (a side effect on connection state), and that it never auto-retries. It does not say what state the table is left in if the import fails partway, which matters for a destructive non-idempotent operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, front-loaded with the operation and its destructive scope, then permissions, prerequisite, and failure semantics. No sentence is filler; each one carries a distinct operational fact.

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

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

No output schema exists, and the description covers the safety-critical facts (replacement, admin, backup, reconnect, no retry). Remaining gap is failure/partial-import behavior and what a successful return looks like, which for a destructive import tool would be worth one more sentence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

With only 50% schema description coverage, file_path is undocumented anywhere; the description implies a 'local' path but adds no format, path-style, or ZIP-content constraints. table_id is fully explained in the schema ('Omit to use the active connected table'), so the schema carries most of the weight here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: load a local TTCraft ZIP archive into the shared table, with the destructive scope declared up front ('REPLACING current objects'). This is clearly distinct from archives_save and modules_import, so an agent can tell what it does without consulting the schema.

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

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

'Requires Admin' and 'Export a backup first' give concrete preconditions and a required ordering step before invocation. It does not explicitly name the alternative tool (archives_save) or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is structured. The description adds only that results are paginated and which media types appear, with no detail on ordering, total counts, or how pagination interacts with search results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource and adds the two key modifiers (asset types, pagination). Zero filler.

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

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

With no output schema, the description should say what an asset record looks like and how search matching works. It covers scope and asset types adequately but leaves the query semantics and result shape undefined for a four-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 25% — just table_id is documented. The description mentions 'search' and 'pagination', weakly implying query and limit/offset semantics, but never explains whether query matches filenames, types, or tags, nor how limit/offset apply. It does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair ('read/search') and resource ('uploaded asset gallery'), and enumerates the asset types covered (images, models, fonts, audio, PDFs). This clearly distinguishes it from sibling asset_upload, though it doesn't name the sibling explicitly.

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

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

No indication of when to use this versus asset_upload, library_list, or docs_search, and no prerequisites or exclusions. Usage is only implied by the 'read/search' verb.

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

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

Adds real value beyond the annotations: bounded-memory chunked uploads signals large-file safety, and the returned library/assets path explains the post-call workflow. However, the annotations declare destructiveHint=true and idempotentHint=false, and the description never explains what gets destroyed (overwrite on name collision?) or what makes a repeat call non-idempotent — the most important behavioral question for this tool is left unanswered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, purpose front-loaded, no filler. The chunked-upload detail and the path-format rule each earn their place; only slight tightening would improve it.

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

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 fills the void by explaining the return value and how to reference it later. Missing for a destructive, non-idempotent upload: size/type limits, overwrite semantics, and any auth or table-scoping caveats.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

At 33% schema coverage only table_id is documented in the schema, so the description carries extra burden. It compensates for file_path with "Path must be absolute", but says nothing about the optional `name` parameter (format, default derivation, or whether it drives overwrite), leaving a real gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Upload") and resource ("local image/model/model ZIP/font/audio/PDF to the table gallery") with enumerated file types, which is far more specific than the bare name. It does not name its sibling counterparts (e.g., assets_list, archives_import), so the agent must infer the boundary itself.

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

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

Usage is implied clearly enough for a single obvious job — push a local file into the gallery — but there is no explicit when-to-use/when-not, and no routing to alternatives such as archives_import or library_save for other kinds of asset movement.

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

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

Annotations declare openWorldHint=true and non-readonly, and the description adds real context beyond them: the flow opens a browser as a side effect, the URL and code must be surfaced to the user, and polling must wait an interval. It stops short of covering code expiry/re-invocation or what state is established on success, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each doing distinct work: identity, parameter guidance, and the required next action. Nothing is repeated from the schema or annotations.

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

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 states what the caller receives (a URL and code) and what to do with it. Minor gap: it does not say whether credentials persist after a successful poll, which matters for an auth entry point.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 0% for the single parameter, but the description compensates fully: it states the default (browser opens) and the exact condition to flip it (headless host). Only the parameter name itself is left implicit, which is inferable from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Start) and resource (browser device-code sign-in), and anchors it to a known reference point ('same ... as the VS Code extension'). It also names the required follow-up sibling auth_poll, so an agent can place the tool in the auth flow without opening the schema.

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

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

Gives concrete when-to guidance for the parameter ('Opens a browser by default; disable on a headless host') and prescribes the next step ('call auth_poll after the indicated interval'). It does not explicitly contrast with auth_status or auth_logout, but the sequence for this tool is unambiguous.

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

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

Annotations already declare destructive=true and openWorld=true. The description adds important context beyond that: it disconnects all tables (scope of impact) and only removes the local login, not the website session. It stops short of stating whether credentials/tokens are cleared or whether it requires an authenticated session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the key caveat. No wasted words.

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

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

For a zero-param, no-output logout tool with rich annotations, the description covers the essential scope and the crucial web-revocation distinction. It could say more about what happens to local credentials or sessions, but nothing critical for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Zero parameters, so baseline 4 applies. The description correctly reflects that no inputs are needed and adds no misleading parameter hints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: disconnect all tables and remove the local login. The scope ('all tables') differentiates it from table_disconnect, and the note about website revocation distinguishes it from auth-related siblings.

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

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

Clearly implies this is the local logout path and warns that web revocation is a separate operation, which prevents an agent from using it expecting a full revoke. It doesn't name alternatives explicitly, but the scope distinction is enough context.

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

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

Annotations already declare this is not read-only, is open-world, and is not idempotent, so the mutation profile is partly covered. The description adds genuinely new context: the token is stored securely and deliberately withheld from the model, which explains why a successful poll produces no visible secret and reinforces why repeated calls are safe to sequence. It stops short of describing what happens on pending/denied states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, each carrying distinct information: one about the call semantics, one about the security behavior of the result. Nothing is repeated from annotations or the schema, and the operational guidance is front-loaded.

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

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

With no output schema, the description carries the burden of explaining what a poll returns, and it only covers the token-storage side effect. It never states how pending, approved, or expired states are surfaced to the agent, which is the key thing a polling tool must communicate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

With zero parameters and 100% schema coverage, there is nothing for the description to disambiguate; a baseline 4 applies. The description doesn't need to and does not restate any parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb and resource ('Check browser approval') with the scope qualifier 'once', so an agent knows this is a single poll of a pending auth flow rather than a status read or an initiation. It does not explicitly distinguish itself from the sibling auth_status, so distinguishing which one to call is left partly to inference.

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

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

'Check ... once, respecting server polling intervals' implies this should be called repeatedly on an interval while waiting for approval, which is useful but phrased as a constraint rather than guidance. There is no explicit statement of when to prefer this over auth_status, auth_begin, or auth_logout, so the agent must infer the sequence.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact, 'Never returns credentials,' but does not say what the response actually contains (login state vs. identity fields) or whether it makes a network call, which matters given openWorldHint is true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core purpose front-loaded and a security reassurance appended. Every clause earns its place; there is no filler or restated title text.

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

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

For a zero-parameter read tool with full annotation coverage, this is nearly complete. The only gap is that there is no output schema and the description never indicates what shape the status/identity result takes, so an agent must call it blind to learn the return fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 of 4 applies. Nothing in the description misrepresents or omits parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Check) and resource (TTCraft login and identity), which is more precise than a tautology. It does not explicitly differentiate itself from the auth_begin/auth_poll/auth_logout siblings, though the name and phrasing make the status-check role inferable.

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

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

Usage is implied: an agent would call this to determine current login/identity state. There is no explicit when-to-use guidance, no mention of auth_begin as the way to start a login flow, and no stated preconditions or exclusions relative to siblings.

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

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

Annotations already flag destructive/non-idempotent/open-world, and the description adds substantial value beyond them: default dry-run safety, non-atomicity, returns completed steps on failure, no automatic replay, and name prevalidation. This is exactly the behavioral context an agent needs before a destructive batch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, front-loaded with the core operation and safety default; every sentence carries distinct information with no waste.

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

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

For a destructive, non-atomic batch tool with no output schema, the description covers safety default, failure semantics, and prevalidation well. It falls short of full completeness by omitting stop_on_error behavior and the table_id targeting already noted in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 25%, so the description must compensate. It explains dry_run (defaults true, set false to apply) and commands (up to 100, prevalidated names), but says nothing about stop_on_error or table_id, leaving two parameters undocumented in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Run) and resource (up to 100 native commands) plus scope (sequentially, no interleaving). This clearly distinguishes it from the single-command sibling table_command by emphasizing batch size and ordering.

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

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

Gives concrete guidance: prevalidates names, dry_run defaults true and must be set false to apply, non-atomic with no automatic replay. Clear context for safe use, though it never explicitly names alternatives or states exclusions for when not to batch.

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

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

Adds substantial context beyond annotations: omitted objects are not deleted, there is no atomic rollback, templates are cloned into standalone objects, and stable id/key mappings persist locally across applies. These are precisely the mutation risks an agent needs to weigh before calling a destructive write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly six short sentences, each carrying a distinct fact, with the core action and the dry-run safety step front-loaded. No filler or restatement of the name.

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

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

Given a deeply nested schema and a destructive write, the description covers the important caveats (no rollback, no deletion of omitted objects, idempotent-style reapply behavior). The remaining gap is return behavior: with no output schema, the agent gets no hint about what a dry-run report contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Only 3 params and 33% schema coverage, so the description has to compensate — and it largely does: it explains dry_run's role, the meaning of persistent ids/keys, and that templates are cloned (clarifying the '$key' vs library-id template field). It still doesn't explain how objects are matched on reapply or what 'poses' map to (position/rotation), so it stops short of full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Build/update a complete table from a validated blueprint') and enumerates exactly what the blueprint contains (plan, templates, tracked objects, poses, properties, scripts). The 'complete table' scope implicitly separates it from single-object siblings like objects_spawn and objects_patch.

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

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

Gives an explicit operating sequence: 'Dry run first; set dry_run=false to apply,' which tells the agent the safe default and how to commit. It does not, however, name an alternative tool (e.g. table_plan_apply or objects_spawn) or state when not to use this tool.

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

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

Annotations already cover read-only, idempotent and non-destructive semantics, and the description adds real value on top: fields are 'inferred hints' rather than authoritative, and 'native commands may return no acknowledgement' warns that a call can succeed with no response. It omits how the snapshot source affects freshness, but the caveats are substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences, each doing distinct work: what is read and from where, the reliability caveat, and the no-acknowledgement warning. Nothing repeats the annotations or the schema.

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

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

No output schema exists and the return shape ('fields') is not characterized beyond the caveat that values are inferred. Combined with 0% parameter coverage and no mention of the offset/max_characters truncation model, an agent lacks the paging contract needed to call it reliably on large commands.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 0%, so the description carries the full burden, yet it explains none of the three parameters. The 'command' string is only obliquely implied, and 'offset' and 'max_characters' (pagination/truncation of the returned fields) are never mentioned, leaving an agent to guess how a large field set is retrieved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb ('Read') plus a precise resource ('exact native command fields, required capability and reference handler'), and the source is named ('bundled server source snapshot'), which separates it from commands_search. It never names a sibling, so an agent must infer that this is the describe counterpart to commands_search.

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

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

Usage is only implied: it redirects to 'docs and the handler for types/defaults', which points loosely at docs_search/docs_read, but it never states when to call this instead of commands_search or table_command, nor any prerequisite such as needing a command identifier from a search first.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds useful scope information (which command categories exist), but says nothing about result volume, pagination, or what a catalog entry contains — relevant since limit/offset exist and default to 100.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with purpose and scope, ending with the actionable next-step rule. No filler or restatement of the name.

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

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

For a read-only search tool with no output schema, the description covers what is searchable and the follow-up step, which is the core need. It stops short of explaining pagination behavior or result shape, both of which an agent needs to page through a large catalog correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 0% across four parameters, so the description must carry the burden. 'By name/domain/field' loosely gestures at query and domain, but query matching behavior (substring? fuzzy?), field semantics, and the limit/offset pagination contract (default 100, max 500) are entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Discover the native TTCraft command catalog' — and names the search facets (name/domain/field). The category list makes it immediately distinguishable from sibling command_describe, which returns detail on a single command rather than listing them.

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

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

Explicitly routes the agent to command_describe 'before using an unfamiliar command,' establishing the discover-then-describe workflow. It does not, however, say when to prefer this over docs_search for lookup-style questions, so one sibling relationship is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no repetition. The description's real contribution is telling the agent what information surfaces (protocol versions, granted capabilities), which matters for a discoverability tool, but it says nothing about whether it reflects live state, requires an existing connection, or costs a round trip.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; every listed item (table, connections, protocol versions, capabilities) carries information about the result set. Nothing is repeated from the schema or annotations.

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

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

With no output schema, the description takes on the job of describing what comes back and does so by naming the four returned categories. For a zero-argument read-only status tool with rich annotations, that is close to sufficient; only the shape/nesting of the response is left unknown.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumeration of returned categories is a small bonus for an agent deciding whether the call answers its question.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Show' plus an enumerated set of resources (active table, connections, protocol versions, granted capabilities) tells an agent exactly what this returns, which is more specific than a generic 'status' tool. It does not explicitly distinguish itself from siblings like auth_status or state_read, but the named fields (protocol versions, granted capabilities) do imply a different payload.

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

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

Usage is implied rather than stated: the phrase 'granted capabilities' and 'connections' suggests a diagnostic/health-check call after connecting or when auth seems wrong. There is no explicit when-to-use, no exclusion, and no pointer to auth_status or tables_list as alternatives, so the agent must infer the trigger.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds value beyond that by disclosing the bounded-result behavior, cursor continuation semantics, and the maximum blocking duration — traits an agent would otherwise not know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, front-loaded with the purpose before the parameter guidance. Every sentence carries distinct information.

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

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

For a read-only, no-required-parameter tool with no output schema, this covers purpose, polling behavior, and pagination adequately. The main residual gap is not stating that the returned cursor must be read from the response body before the next call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 33% (just table_id), so the description must compensate — and it does, explaining after_cursor's continuation role and that wait_ms blocks up to 20 seconds, which resolves the schema's unit-ambiguous maximum of 20000. It stops short of stating what value the response returns as the next cursor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Read bounded console logs") and narrows scope by naming the content type ("compilation/runtime errors"), which separates it from generic event streams. It does not, however, explicitly name or contrast with a sibling such as events_read, so the differentiation is inferred rather than stated.

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

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

Gives concrete operational guidance: pass after_cursor from the previous call for pagination, and use wait_ms to poll for new logs with a stated 20-second ceiling. There are no explicit exclusions or named alternatives, but the polling/pagination context is clear enough to act on.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds one genuinely behavioral fact — that content is paginated by characters rather than lines or pages — but says nothing about what happens for an unknown slug, an offset past the end, or whether responses indicate truncation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and pagination trait before the example list. The example run is long but arguably earns its place as the only signal about valid slug values.

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

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

No output schema exists and none of the three parameters are described in the schema, so the description should say what a page read returns (content plus whether more remains). Pagination is named but its mechanics and return shape are left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 0%, so the description must carry the load. The example slug list effectively documents the slug parameter, and 'character pagination' conveys the intent of offset/max_characters, but no format or default behavior is described beyond what the schema's types and bounds already show.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: reading a bundled TTCraft manual page, plus the notable trait of character-based pagination. It doesn't explicitly contrast itself with the sibling docs_search, so the boundary between looking up docs and reading a page is left implicit.

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

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

The list of example slugs (table-plan, scripting-ui, etc.) implies when the tool applies and hints at valid inputs, but there is no explicit 'use this when… / use docs_search instead when…' guidance or prerequisite statement.

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

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

The description says the docs are bundled and searchable without internet/login, while annotations declare openWorldHint=true, which implies external open-world interaction. This is a direct contradiction with the stated local/offline behavior, so the rubric requires a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is two sentences, front-loaded with the core search capability and followed by the key empty-query behavior. There is no wasted text.

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

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

For a simple read-only search tool with one optional parameter and no output schema, the description covers the important offline context and empty-query behavior. It could mention result format or the docs_read handoff, but those are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The schema has 0% description coverage for the single query parameter, so the description carries the burden. It adds useful meaning by explaining that an empty query lists document slugs, but it does not define matching behavior or search syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: search the bundled TTCraft manual and Lua API. It also states the empty-query behavior, but it does not explicitly distinguish itself from the sibling docs_read tool.

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

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

The empty-query behavior implies a slug-discovery workflow, but there is no explicit guidance on when to use this versus docs_read or other sibling tools. Usage is inferable but not fully stated.

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

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

Annotations already declare a safe, idempotent read, so the bar is lower; the description goes beyond them by disclosing the 500-message retention window and truncation reporting, which materially affect interpretation. It does not disclose that the call can block for up to 20 seconds via wait_ms, a meaningful behavioral trait left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, each doing distinct work: what it reads and its bound, the filter, then the truncation caveat and alternative routing. Purpose is front-loaded with zero filler.

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

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

With no output schema and four params, the description should say what an event records (type, payload, cursor) and how to advance the cursor; it instead only bounds the buffer and mentions truncation. It is workable for a safe read, but an agent cannot predict the response shape or the meaning of wait_ms from anything provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 25% (only table_id is documented), so the description must carry the rest. It conceptually covers two params — cursor-based advancement ('with a cursor') and message-type filtering ('Filter by message types') — but gives no accepted type values, cursor semantics, or token format, and leaves wait_ms entirely unexplained despite its 0–20000 range.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read table event history') plus an explicit scope ('up to 500 retained messages') and mechanism ('with a cursor'). It also names the sibling tools that serve the different purpose ('state_read/objects_list are the authoritative current state'), so an agent can distinguish it from those 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.

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

The closing clause routes the agent: use this for history, use state_read/objects_list for current state, and it explicitly flags that this tool's view may be truncated. That is real guidance, but it never says positively when to prefer this tool (e.g., 'to poll for changes since a cursor') and omits any long-poll/wait behavior that would change usage.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered; the description adds real behavioral context by disclosing that default results omit scripts and large geometry (payload weight depends on details). It still omits pagination behavior and what refresh actually re-fetches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the search scope and followed by the one non-obvious flag and the sibling handoff. No filler.

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

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

For a 6-parameter, read-only list tool with no output schema and thin schema descriptions, the description covers the two most consequential parameters but leaves paging (limit/offset) and refresh unexplained, so an agent cannot confidently scope large result sets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 17% (only table_id documented), so the description must compensate. It does explain query's searchable fields and details' effect on payload content, but limit, offset, and refresh are left with no semantics in either place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search library templates') and enumerates the searchable fields (name/category/id/kind), which clearly separates it from library_save and objects_list. It doesn't explicitly contrast itself with objects_list/objects_spawn, but the 'library templates' resource scope is distinct enough to identify the right tool.

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

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

Gives one concrete routing rule: use details=true to get scripts and large geometry, otherwise defer to script_read for template scripts. That is genuine alternative-routing guidance, but there is nothing on when to use library_list vs objects_list, nor when to use refresh or how to page.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds non-obvious behavior the annotations cannot convey: omitted fields are preserved from the cached full template (partial-merge semantics) and changes may propagate to linked instances. It does not say what happens on failure or whether changes are reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, no waste, front-loaded with the create/update distinction followed by the two highest-risk behaviors (linked-instance propagation, locked built-ins). Every sentence earns its place.

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

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

For a destructive mutation with a nested free-form object and no output schema, the description covers the crucial merge and side-effect semantics. The remaining gap is the shape of spec — an agent still needs external knowledge of template fields — but the risk-bearing behavior is disclosed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 33% — just table_id is documented, and id and the free-form spec object are bare. The description partially compensates by explaining id's role and that omitted spec fields are retained from the cached template, but it never says what keys spec accepts or what the merge granularity is. Partial compensation, not full.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair and resource: create a template or update one by id. It also names the governing constraints (merge with cached template, locked built-ins). It does not differentiate itself from siblings like library_list, but the purpose itself is unambiguous.

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

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

Clearly explains the create-vs-update branch (omit id to create, supply id to update) and gives an explicit exclusion: locked built-ins cannot be overwritten. It does not point to library_list for discovering ids or to any alternative write path, so it stops short of full routing guidance.

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

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

Annotations already flag destructive, non-idempotent, open-world behavior; the description adds real value on top: it specifies additive merge semantics, Admin authorization, and that the connection reconnects after success. It stops short of describing conflict handling or partial-failure behavior, which matters for a destructive batch import.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each carrying distinct information: operation type, supported options, prerequisite, and post-call side effect. Front-loaded with the core verb+resource and no filler.

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

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

For a destructive, non-idempotent batch import with nested package objects (key, path, applyLayout) and no output schema, the description covers the safety essentials but leaves the semantics of nested package fields and failure behavior unexplained. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

With schema coverage at only 25%, the description does compensate somewhat by naming per-package layout and optional table shape/global-script selection, mapping to applyLayout, table_shape_from and apply_global_script. But it never explains the package 'key' vs 'path' distinction, the meaning of table_shape_from (an integer with no schema description), or the 30-item cap implied by maxItems.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and scope: 'additively merge ... local TTCraft module ZIP archives', which is clearly a write/import operation distinct from reads. It does not explicitly differentiate itself from the sibling archives_import or blueprint_apply, so an agent must infer the boundary.

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

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

The 'Requires Admin' prerequisite gives a usable gate, and 'Additively merge' hints at the non-replacing behavior. However, no when-not-to-use condition or named alternative (e.g. archives_import) is offered, so routing between similar import tools is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld. Beyond that, the description discloses the refresh round-trip to the server and that output is paginated JSON text, which annotations do not cover and which matters for callers handling large payloads.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the identifier contract, then refresh, then return shape. Every sentence carries information and nothing is repeated from the schema verbatim.

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

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

With five parameters, no output schema, and no annotations covering pagination, an agent still lacks details on how offset/max_characters interact (truncation and continuation), and whether table_id is required in multi-table sessions. Adequate but not complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 40%, so the description must compensate and it partially does: it clarifies refresh semantics and implies pagination (offset/max_characters) via 'Returns paginated JSON text'. But offset, max_characters truncation behavior, and table_id versus the active connected table are not explained in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Read one object') plus the two identifier forms accepted. It is clearly distinct from objects_list and docs_read, though it never explicitly names a sibling or states the read-vs-list boundary.

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

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

'refresh asks the server for current properties' implies when to set refresh=true, but there is no guidance on when to use this over objects_list, objects_patch, or state_read, and no stated prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real value beyond that: results include live positions and rotations, results are paginated, and the details flag expands to full properties (implying a heavier payload). It omits the default limit of 100/max 500 and any ordering guarantee.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short fragments, front-loaded with the core search capability, with zero filler. The telegraphic style slightly hurts readability but nothing is wasted.

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

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

For a 5-parameter listing tool with no output schema and thin schema coverage, the description covers return contents and pagination but not result ordering, what happens with an empty query, or how table_id defaulting interacts with results. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 20% (table_id alone is documented), so the description must compensate. It does explain query's accepted key types (name, kind, GUID, id) and details' effect, and 'Paginated' implies limit/offset, but defaults, maximums, and empty-query behavior are left unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (find) and resource (objects), plus the searchable keys: name, kind, GUID, id. It is clearly distinguishable from object_read and objects_spawn by implication, though it never names 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.

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

The description gives no when-to-use or when-not-to-use guidance, and never points to object_read for a single-object fetch or explains how this differs from objects_list versus asset/library lookups. 'Paginated' hints at bulk listing but leaves selection criteria to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety burden is partly carried. The description adds nothing beyond them — it does not say whether locks persist across sessions, whether replacing an existing lock is possible, what permissions are needed, or what gets destroyed, which matters for a flagged-destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the operation front-loaded and zero filler. It is efficient, though the terseness comes at the cost of specification rather than from tight editing.

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

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

For a destructive, non-idempotent batch mutation with no output schema and weak parameter documentation, the description is far too thin. An agent has no information on effect scope, lock semantics, or response behavior before performing a flagged-destructive call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 33%; table_id and the objects item type are documented in the schema, but the top-level `locked` and `objects` have no descriptions. The prose at least implies both required parameters ('Lock or unlock' → locked, 'a list of objects' → objects), but it does not clarify the boolean direction (true = lock) or the 500-item cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a verb ('Lock or unlock') and a resource ('a list of objects'), so the basic operation is identifiable, but it is close to a restatement of the tool name objects_lock. It does not explain what 'locking' means in this domain (edit protection? transactional lock? exclusivity?) nor differentiate the operation from siblings like objects_patch or objects_move.

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

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

There is no when-to-use guidance, no exclusions, and no reference to alternatives. An agent cannot tell from the text when locking is appropriate over, say, patching a field, nor when to omit table_id.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the mutation and irreversibility profile is known. The description adds real value beyond that — metres as the unit, quaternion component order [x,y,z,w], and the locking prerequisite — but never says what happens to unspecified transforms or how physics/clamping alters the requested pose. With annotations carrying the safety profile, a 3 is fair.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences: the payload and units come first, the blocking precondition second, and verification last. No filler and nothing buried.

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

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

For a destructive, non-idempotent mutation with no output schema, the description covers units, encoding, prerequisites, and how to confirm the result. The remaining gap is whether position is required versus optional and the effect of omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 40%, and the description compensates for the undocumented ones: position is in metres, rotation is a quaternion ordered [x,y,z,w], scale is [x,y,z]. It does not clarify that position is optional or what omitting it does, and object/table_id are already covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (place) and resource (object) with units (metres) and the optional rotation/scale payloads, so the agent knows exactly what operation this is. It does not explicitly contrast with objects_patch, which is the obvious nearby sibling for changes to an object, so differentiation is inferred rather than stated.

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

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

Gives a clear precondition — locked objects must be unlocked with objects_lock first — and a follow-up step, inspecting state to verify clamping/physics. It stops short of naming when to prefer objects_patch over this tool, so the routing is clear but not exhaustive.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful semantics (partial patch of the given properties only, label is the display name), but says nothing about failure/atomicity behavior across up to 500 objects or whether omitted properties are preserved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, with the operation stated first and the field-discovery pointer immediately after. Every clause carries information the agent needs.

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

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

For a destructive, non-idempotent mutation with an arbitrary nested payload property bag, the description covers field discovery but omits multi-object failure semantics and there is no output schema to explain results. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 33% and the nested `properties` bag is untyped with no description in the schema. The description compensates well by pointing to setprops and command_describe and by disambiguating `label`, while `objects` and `table_id` are already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (patch) plus the resource and the field categories affected (appearance/physics/name), which implicitly separates it from siblings like objects_move, objects_lock and objects_remove. It stops short of naming or excluding those siblings explicitly.

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

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

"Properties follow setprops; use command_describe for exact fields" gives concrete routing for field discovery, which is the main ambiguity here. However, there is no guidance on when to patch versus spawn/move objects, and no mention of prerequisites for the destructive operation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the description's real contribution is the cascade semantics: attached contents are removed along with the object, which is non-obvious and materially affects the decision. It still doesn't state irreversibility or whether partial failures are atomic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded on the action and its consequence, with the safety note last. The backup clause is slightly soft but not padding.

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

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

Covers the destructive action, cascade behavior, and a pre-step, which is reasonable for a 2-param tool with no output schema. Missing are failure/atomicity semantics and any hint at confirmation, which matter for a 500-item bulk destructive call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 50% and the existing field descriptions already explain the GUID-vs-runtime-id preference and the 'omit to use active table' default. The description adds nothing about the parameters, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (remove) and resource (objects) with scope ('from the live shared table'), which clearly separates it from objects_patch and objects_move. It stops short of naming a sibling alternative directly, so an agent must infer the routing.

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

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

'Export a backup first when needed' implies a prerequisite but leaves 'when needed' undefined, and there is no explicit guidance on when to choose removal versus objects_patch for edits. Usage is implied rather than prescribed.

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

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

Annotations already declare this as a destructive, non-idempotent, open-world mutation. The description adds valuable context beyond annotations: it discloses that the return may include concurrent spawns by others and explains the template-based spawn flow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four well-structured sentences, front-loaded with the core action, no wasted words. Each sentence contributes useful information.

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

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

The tool is complex (mutating, nested spec object, no output schema), but the description omits key details: what fields the spec object should contain when not using a template, and any failure behavior. It covers template usage and return concurrency but leaves gaps for a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is low (25%), but the description adds some meaning for the template parameter ('spawn fields come from the template'). It does not explain the spec object structure, position format, or table_id beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Spawn an object or a native linked library template.' It distinguishes itself from siblings by naming objects_patch and blueprint_apply and describing when each applies.

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

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

Gives clear usage context for templates ('use objects_patch afterwards') and for repeated builds ('use blueprint_apply'). However, it does not state general prerequisites or when not to use the tool.

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

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

This is valuable: readOnlyHint=false would otherwise puzzle an agent for a tool named script_read, and the description explains why — it can write source to output_path — plus the reassurance 'Existing files are never overwritten', which explains the non-destructive hint. It also discloses the SHA-256 conflict-detection behavior, adding context the annotations do not carry. It omits auth/connection requirements and truncation behavior, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action, then the two operational options, then the safety guarantee. No filler or restatement of the tool name.

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

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

For a 7-parameter tool with no output schema and no required fields, the definition leaves important gaps: which id parameter pairs with which target value, whether a connected table is mandatory, and what the returned payload contains (source, hash, truncation indicator). The behavioral side-effects are well covered, but structural completeness is not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

With only 29% schema coverage across 7 parameters, the description does some compensating work: it maps the three 'target' values, explains offset/max_characters indirectly via 'page large source', and clarifies the semantics of output_path. But object, template_id, table_id, and the 16k/64k character limits are never explained, leaving several parameters documented nowhere meaningful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read a Global, object or template Lua script') and the three retrieval targets, which makes it easy to distinguish from script_write. It stops short of explicitly naming script_write as the mutation counterpart, but the read semantics are unambiguous.

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

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

'Page large source or write to an absolute output_path for local editing' gives two concrete usage modes, which is real guidance. However, it never states when to prefer this tool over siblings (e.g., script_write for edits, object_read for non-script object data) or any prerequisites such as needing an active table connection.

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

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

Annotations already flag destructive=true and idempotent=false, so the safety bar is partly covered. The description adds genuinely non-obvious behavior: atomicity on compile failure ('the previous script stays active'), the isError return signal, and optimistic concurrency via expected_sha256. It does not say whether the install is reversible or what permissions are required against the live table, leaving one meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, each carrying distinct information: action, input constraint, concurrency check, failure semantics, follow-up. The action is front-loaded and nothing is repeated from the schema or annotations.

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

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

For a destructive, non-idempotent write to a live production script with 7 loosely documented parameters and no output schema, the description covers failure and concurrency well but leaves the targeting model unexplained. An agent cannot tell from this text whether it needs object or template_id for a given target, which is a real gap before invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 29%, so the description must carry weight; it does explain the code/file_path mutual exclusion and the purpose of expected_sha256, neither of which is documented in the schema. But the most consequential parameter, target (global/object/template), is never explained, and its interaction with object, template_id, and table_id is left entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb+resource pair is concrete: 'Compile and install Lua source on the live table' tells an agent exactly what happens, and 'Read console afterwards' points at the follow-up. It stops short of distinguishing this from adjacent write paths such as table_command, blueprint_apply, or modules_import, which an agent could plausibly confuse with installing code.

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

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

'Supply exactly one of code/file_path' and 'Read console afterwards' give a usable call recipe and a post-call workflow. However, there is no explicit statement of when to prefer this over sibling write tools, nor any precondition (connection state, permissions) that selects it. Usage is implied by the mechanics rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds non-obvious behavior beyond that: the data is a cache (implying possible staleness relative to live server state), large sections are paged, and results come back as JSON text rather than structured objects. It omits refresh/invalidation semantics for the cache, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each doing distinct work: scope, the omit-section shortcut, and the paging/return format. The section list and the overview hint are front-loaded where an agent will read them first.

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

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

With no output schema, the description handles the return side by naming the JSON-text paged format and the compact-overview mode, which is the essential thing an agent needs. For a 4-param, mostly-optional read tool this is nearly complete; only cache freshness behavior against live state is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 25%, so the description must carry weight, and it does: it enumerates valid 'section' values and explains that omitting it yields a compact overview, and it links the paging sentence to offset/max_characters. It never states that offset/max_characters are the paging controls by name or their units/limits, leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Read a cached authoritative state section', with a concrete enumeration of the section keys (table, zones, snaps, drawings, decals, players, groups, timemachine, policy, lighting, music). An agent knows exactly what this returns. It does not explicitly contrast with nearby read siblings such as object_read or objects_list, so it stops short of 5.

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

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

It gives one piece of genuine routing guidance — 'Omit section for a compact overview' — which is a usable when-to-do-what rule. But there is no statement of when to prefer this over object_read/objects_list/events_read, nor any prerequisites or exclusions. Usage is implied rather than prescribed.

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

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

Annotations already declare destructive/openWorld/non-idempotent, and the description adds real value beyond them: server-side permission enforcement and script vetoes, plus a warning that processed_unverified is not a success acknowledgement. It still doesn't say what happens on veto/failure or how partial results surface.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Short, front-loaded sentences with no filler; the action and the prerequisite lead. The telegraphic phrasing of fields like processed_unverified is compact but slightly under-explained.

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

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

No output schema and a freeform arguments bag make behavior hard to predict, and the description covers permissions and the processed_unverified trap but not timeout semantics, response_type options, or failure modes. Adequate, with clear remaining gaps for a destructive open-world tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is only 20% (only table_id is documented), so the description must compensate; it does partially by explaining that arguments carries protocol fields and that object ids must be current runtime ids. But command, response_type, and timeout_ms get no explanation of accepted values or effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Run a native TTCraft command from the catalog"), which is clearly distinct from commands_search and command_describe. It doesn't contrast itself with batch_execute, another likely-looking sibling, so it stops just short of full differentiation.

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

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

Gives an explicit prerequisite ("Read command_describe first") and a constraint on argument contents (protocol fields, current runtime id). It provides no explicit 'when not to use' or guidance on when to prefer commands_search or batch_execute instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds useful session-level semantics (multiple connections coexist; table_id selects among them) but does not say what happens if the table is not running or how long the active selection persists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, the core action front-loaded, and the second sentence adds only non-redundant multi-connection detail. Nothing to trim.

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

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

For a one-param tool with annotations covering the safety profile and no output schema, this is nearly sufficient. The remaining gap is failure behavior when the target table is not running.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

There is one parameter with 0% schema description coverage, so the description carries the burden. It does explain that table_id selects among already-connected tables, which is meaningful, but it never clarifies whether the first call's table_id opens a new connection or must match an existing one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Connect to a running table and make it active.' An agent can tell this apart from table_disconnect, but the sibling table_reconnect is never mentioned, so the connect-vs-reconnect distinction is left to inference.

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

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

'Supports multiple connected tables; pass table_id on later calls to select explicitly' gives real usage context for the multi-table case. However, there is no guidance on when to use table_reconnect instead, or on prerequisites such as the table needing to be running.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds real value beyond that by clarifying scope: only this client's connection is dropped, and the shared table stays alive for other clients. It does not cover behavior when no connection exists or whether local unsaved state is affected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste. The primary action is front-loaded and the scope qualifier follows immediately, which is the right order for an agent scanning definitions.

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

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

With one optional parameter, full schema coverage, explicit annotations, and no output schema, the description covers everything an agent needs: the action, its scope, and the fact that the shared table survives. Nothing necessary to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and the single parameter already carries the key note 'Omit to use the active connected table.' The description says nothing about table_id, so it adds no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Disconnect this MCP client from a table.' The verb+resource pair is unmistakable and clearly sits opposite table_connect/table_reconnect. It does not explicitly name those siblings, so differentiation is inferred from the verb rather than spelled out.

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

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

Usage is implied by the verb: you call it when you want to leave a table. However, there is no explicit guidance on when to prefer table_reconnect (e.g., switching tables), nor any mention of preconditions such as whether a connection must exist first. The agent must infer the boundary cases.

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

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

Annotations already declare destructive=true, idempotent=false, openWorld=true; the description adds genuinely non-redundant behavior: it returns server validation errors/warnings and that merge patches the stored plan (versus the implied full replace otherwise). It still does not state what exactly is destroyed on a non-merge apply or whether partial validation failures leave the table mutated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four terse, front-loaded sentences with no filler; the effect and return behavior come before the merge detail. The 'shape, seats, areas, snaps' fragment is jargon-dense but does real work.

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

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

For a destructive, open-world tool with a nested free-form parameter and no output schema, the description covers the return contract and merge semantics but not the plan's shape, permissions, or failure atomicity. Pointing at table-plan docs mitigates this, but the delegation is the main reason it is not a 2.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 33% and 'plan' is an undescribed free-form nested object, so the description has to compensate. It does so partially by naming the plan's content domains and by explaining merge's patch semantics, but the plan's actual key structure is left entirely to external docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Apply the TTCraft declarative table plan') and enumerates the plan's domain contents (shape, seats, areas, snaps), which is far more informative than the bare tool name. It does not explicitly distinguish itself from the closest sibling, blueprint_apply, but the resource is concrete enough to be selectable.

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

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

Gives one real precondition — 'Read table-plan docs first' — which correctly routes the agent to the docs_search/docs_read siblings. However it never says when to use this versus blueprint_apply, table_save, or objects_patch, nor when not to apply a plan.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the call resynchronizes to a full state and explicitly does not replay missed commands, which sets agent expectations about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the purpose and followed by the one behavioral caveat that matters. No filler.

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

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

With no output schema, the description carries the return-value burden and does so at a high level ('fresh full state'). The main omission is any mention of the required table_id or what the state includes, but for a single-parameter resync tool this is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

There is one required parameter (table_id) with 0% schema description coverage, and the description says nothing about it. The name is largely self-explanatory, but nothing clarifies what a table_id refers to or how to obtain one, so the gap is uncompensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (reconnect a table session) plus the outcome (fresh full state). It's distinguishable from siblings like table_connect and table_disconnect, though it never names them directly.

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

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

Gives an explicit trigger condition: 'after connection loss.' That clearly separates it from table_connect (initial connection), but it doesn't state when NOT to use it or name the alternative to call when a connection is still healthy.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is carried by structured data. The description adds useful scope context (native savetable, not account save slots) but never explains the destruction semantics the annotations imply, e.g. whether reusing an existing name overwrites it or whether auth/connection is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, purpose front-loaded, each following sentence doing disambiguation work that earns its place. No filler.

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

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

For a two-parameter destructive write with no output schema, the description covers purpose and sibling routing but omits the behaviors an agent most needs: duplicate-name handling, required connection/auth state, and what the call returns. Adequate but with clear gaps for a destructive mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The description mentions no parameters at all. Schema coverage is 50%: table_id is documented ('Omit to use the active connected table') but the required 'name' parameter has only min/max length constraints and no semantics, and the description does not fill that gap (uniqueness, collisions, naming rules).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a named snapshot in the table server database') and immediately disambiguates two near-neighbors: TTCraft account save slots and the sibling tool archives_export. An agent can tell what this produces without reading the schema.

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

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

Names an explicit alternative ('Use archives_export for a portable backup') and a conceptual exclusion (account save slots), which gives real when-to-use routing. It stops short of stating general preconditions, e.g. whether a table must be connected first, so it is not a full when/when-not matrix.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by saying results are scoped to manageable tables and include running status, room, and channel, but it does not mention pagination, ordering, or result limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every phrase contributes either scope, returned fields, or the resource being listed.

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

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

For a zero-parameter read-only list tool with rich annotations and no output schema, the description is nearly complete: it states the resource, account scope, and key returned attributes. Minor gaps remain around pagination or result-size behavior, but they are not critical for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The empty schema is fully described at 100% coverage, and the baseline for zero-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List TTCraft tables.' It also narrows scope with 'that your account can manage' and names returned fields. However, it does not explicitly distinguish this tool from related siblings such as objects_list or library_list.

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

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

The description states what the tool returns but gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is the listing tool for manageable tables.

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