Subtraq

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

No annotations are provided, so the description carries the full burden. It discloses real behavioral traits the schema does not: placement inheritance of the parent destination, placements carrying their own UTM, and the return of `shortUrl` ready to publish. It omits auth/permission needs and failure modes, but the core semantic quirks are covered.

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?

Front-loaded with the verb and resource, then the two modes, then the return value. Four dense sentences with no filler; every clause carries load-bearing 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 an 11-parameter creation tool with no annotations and no output schema, the description covers the critical branching logic and the return value. The rich schema handles domain/slug/label details, so little is missing, though auth requirements and failure behavior are absent.

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 already 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the `parentId`/`destination` interaction and the UTM inheritance for placements, which the schema's field descriptions only partially convey.

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 ('Crée un lien court') and immediately splits the tool into its two distinct modes (lien parent vs placement), which is exactly what distinguishes it from siblings like update_link and get_link. An agent can tell what this does 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 clear conditional guidance for the two modes: without `parentId` it's a parent link needing `destination`; with `parentId` it's a placement inheriting the parent's destination. However, it names no alternative sibling tools and gives no exclusions beyond the parent/placement split.

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?

With no annotations, the description carries the full burden, and it does disclose one concrete behavioral trait: the operation is refused with error code `space_limit_reached` when the plan is full. It remains silent on permissions/authentication, reversibility, and whether the new space id is returned, so the disclosure is partial.

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 first, failure condition second, with no filler. Every clause adds information the schema does not already contain.

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 one-required-parameter creation tool with full schema coverage and no output schema, the description covers purpose plus the key failure mode. It could still note auth requirements or what is returned on success, but nothing essential to calling 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 description coverage is 100% — both `name` and `slug` are documented in the schema, including that slug is derived from name when omitted. The description adds no parameter meaning beyond that, so the baseline 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 and resource ('Crée un espace client'), which distinguishes it from create_link and list_spaces by resource type. It does not explicitly name siblings, but the resource is unambiguous enough for selection.

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?

Implies usage (create a client space) but gives no when-to-use context, no prerequisites, and no alternatives such as list_spaces for inspecting existing spaces. The only conditional information is a failure case, not usage routing.

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?

No annotations are provided, so the description carries the full burden, and it does disclose non-obvious behavior: amounts are in CENTIMES, currencies are never converted and mixedCurrencies limits totals to one currency, and the response always echoes the attribution model used. It omits permissions/auth and any rate-limit or latency context.

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?

Front-loaded with the resource and its metrics, then the currency and attribution caveats. Dense but every clause carries information; the sequence of caveats makes it slightly run-on.

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?

There is no output schema, so the description must describe the return payload, and it does: metric list, attributed vs non-attributed revenue, placement breakdown, currency units and mixed-currency caveat. Auth/permission requirements are the only notable 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it clarifies the unit of returned amounts (centimes) and that the chosen `model` is always reported back in the response, which affects how an agent interprets results.

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 resource (un espace) and enumerates exactly what it returns: clics, prospects, ventes, revenu attribué/non attribué, and placement-level detail. It is the only analytics tool among siblings (create_link, get_link, list_links, track_sale, etc.), so no sibling confusion is possible.

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 (pull analytics for a space, choose a period/model), but there is no explicit when-to-use vs. when-not, no mention of prerequisites, and no alternative tool named. Adequate but with clear gaps.

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?

No annotations are provided, so the description carries the full burden. It does disclose two useful behavioral facts — that the URL returned is the resolved FINAL destination as received by the landing site, and that the click window is fixed at 30 days — but says nothing about permissions, rate limits, or behavior for an invalid/unknown id.

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 with zero padding, front-loading the resource and then the two returned data points. Every clause 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?

With no output schema and no annotations, the description must cover return values itself; it does so at a high level (final destination, 30-day clicks) but omits response shape, error behavior, and any auth context. Adequate for a trivial one-parameter read tool, 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 description coverage is 100% for the single id parameter, so the schema already carries the semantics. The description adds no format, sourcing, or lookup hints beyond what the schema provides; baseline 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 (détaille) and resource (un lien) and enumerates what it returns: the FINAL destination with UTM parameters plus 30-day click counts. This is enough to separate it from list_links, but it never names a sibling tool explicitly, so differentiation from get_analytics (which also surfaces click data) 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisite (e.g., that the id must come from list_links). The overlap with get_analytics on click metrics is a genuine ambiguity that goes unaddressed.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait: the parent/sublink inheritance model, which helps interpret results. However, it omits pagination behavior (cursor), the default status filter (active), and whether omitting space spans all spaces.

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 with the core action front-loaded and no filler. The second sentence is somewhat tangential to tool selection, though it does aid interpretation of returned links.

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-required-parameter list tool with a fully documented schema and no output schema, the description is nearly sufficient; the parent/sublink explanation usefully compensates for the missing output schema. Minor gaps remain on pagination behavior and default filtering.

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 100%, so every parameter (limit, space, cursor, status) is already documented in the schema, including defaults and ranges. The description adds no parameter-level detail beyond that, so the baseline 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 ("Liste") and resource ("liens"), and adds a useful domain distinction between PARENT links (destination) and PLACEMENT/sublink (UTM, inherits the rest). It does not distinguish itself from the sibling get_link, so a single-link fetch vs a bulk listing 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?

No statement of when to use this tool versus alternatives such as get_link (single link) or list_spaces, and no prerequisites or exclusions are given. Usage is only implied by the verb "Liste".

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?

No annotations are provided, so the description carries the full burden. It conveys the domain model (a space contains links, clicks, sales) but says nothing about pagination behavior, ordering, scope (own account only), or permissions — notable given the cursor/limit parameters imply a paged result.

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 action, and the second sentence earns its place by defining the core entity. No boilerplate or repetition.

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 no annotations, the description could state what a space record contains or that results are paginated via nextCursor. It supplies useful conceptual context but leaves return shape and pagination 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 100%, so both limit and cursor are already documented in the schema. The description adds no parameter-level detail, which is acceptable but not additive; baseline 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 and resource ("Liste les espaces du compte") and defines what a space is, which is genuinely useful domain framing. It does not distinguish itself against siblings like list_links or create_space, but the resource is distinctive enough for an agent to place it.

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 statement of when to call this versus alternatives, no prerequisites, and no note that it is the entry point for discovering spaces/IDs needed by create_link or get_analytics. The agent must infer usage entirely from the name.

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?

With no annotations, the description carries the full burden and does well: it discloses idempotency semantics via invoiceId ('le rejouer ne facture jamais deux fois') and a hard execution constraint (no browser). It omits auth requirements and what the call returns, 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?

Four sentences, purpose front-loaded, no filler. The CENTIMES sentence duplicates the schema's own description of the amount field, a minor redundancy that keeps it from a 5.

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 write-oriented tool with no annotations and no output schema, the description covers purpose, units, idempotency, and execution constraints well. It does not address authorization requirements or the effect of matching by email vs clickId vs externalId, leaving a small gap.

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%, so the schema already documents all 7 parameters including the CENTIMES convention and invoiceId's role. The description's 'Montant en CENTIMES' and idempotency notes merely reinforce what the schema states, adding no new syntax or format detail. Baseline 3 is correct.

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 (Enregistre) and resource (VENTE), plus the linkage to the person's original placement. None of the siblings (create_link, create_space, get_analytics, etc.) deal with sales, so an agent can immediately tell this apart.

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 invocation context: 'Une vente ne peut PAS être envoyée depuis un navigateur' tells the agent this must run server-side, which is genuine usage guidance. It does not, however, name alternatives or elaborate on when not to record a sale, so it stops short of explicit routing.

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?

With no annotations at all, the description carries the full behavioral burden and does so well: it discloses that changing the address preserves the old redirect, that old-address clicks still count on the link via `previousShortUrls`, that placements follow the domain change, and that archiving stops redirection (old addresses included) while retaining history. These are non-obvious side effects an agent genuinely needs.

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: the mutating scope is front-loaded, then the redirect-preservation behavior, then the archive/never-delete semantics. No filler, and the most decision-relevant facts come 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?

For a six-parameter mutation tool with no annotations and no output schema, the description covers the important behavioral consequences well. It stops short of stating permission requirements or whether omitted fields are left unchanged, which leaves a small gap for a mutation 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 description coverage is 100%, so every parameter is already documented in the schema, including `slug_taken` errors and the shared-domain value. The description adds little parameter-level meaning beyond confirming which fields are updatable, so the baseline 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 and resource (modify a link) and enumerates exactly which fields can change: destination, label, address (domain/slug), archive. It is clearly distinct from create_link/get_link/list_links by virtue of the `id`-based mutation, though no sibling is named explicitly, which keeps it short of a 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?

Usage is implied (call it to alter an existing link identified by `id`) but there is no explicit when-to-use statement, no guidance on partial vs full updates, and no exclusions or named alternatives. The reader must infer the context from the verb alone.

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