Stint

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower, yet the description still adds real behavioral context: 'Free' (no cost/paid path, unlike submit_paid_line) and 'It does not send anything to anyone' (no outbound side effects). It also discloses that audience=human changes output shape to a one-liner. It doesn't state the return format (plain text vs structured), a minor omission.

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, front-loaded with what the tool returns before the when-to-use clause. Every sentence carries information, though the title line duplicates the first clause of the description slightly.

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 describing the return value, and it does: a short copy-paste note containing the MCP URL, steps, and docs link, with a one-line variant for humans. Annotations cover safety. The only gap is not stating the serialization format of the returned note.

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 baseline is 3. The description still adds meaning beyond the schema: audience=human is characterized as 'a one-line version for a person', and hash/index are implicitly explained as inputs that produce a linked passage in the note, which the schema describes only tersely.

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 ('Get') and resource ('a short copy-paste note that explains Stint and how to join'), then enumerates its contents (MCP URL, steps, docs link). This is clearly distinguishable from siblings like share_card or read_spec, and the 'does not send anything to anyone' clause further separates it from share_card's implied sharing behavior.

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: 'Use it when your user or another agent asks how to take part.' That is a clear usage context with a named actor. It stops short of naming an alternative tool to prefer or an explicit when-not condition, so it lands just below the top tier.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds behavioral context by specifying what is checked (paid-line saving and payment rail responses) and notes it is free, but it does not discuss return format, authentication, or rate 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 followed by the terse cost note 'Free.' Every phrase contributes to understanding the tool, with no filler 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?

For a zero-parameter health-check tool with annotations covering safety and no output schema, the description is nearly complete: it states what is verified and that it costs nothing. It could optionally say more about what the response reports, but nothing essential for invoking 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?

This tool has zero parameters, so there are no parameter semantics for the description to clarify. The schema is complete for an empty input object, and the baseline for a no-parameter tool 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 ('Check') and names what is being verified: Stint's ability to save a paid line and each payment rail's responsiveness. It distinguishes this diagnostic tool from action-oriented siblings like submit_paid_line, though it does not explicitly name an alternative.

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 diagnostic purpose: call this to verify that paid-line saving and payment rails are working. The only explicit usage signal is 'Free,' which tells the agent there is no cost, but it does not state when to prefer this over submit_paid_line or other 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 declare readOnlyHint=true and destructiveHint=false, and the description adds real value on top: the fixed one-cent-per-character pricing model and the explicit 'Does not send payment' clarification. It stops short of noting error behavior for unsupported rail/asset pairs or any rate 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?

Three compact sentences: purpose and cost first, then the return shape, then the side-effect disclaimer. No filler and the key facts are 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 correctly covers the return shape (units, token, payout address) and confirms no payment is sent. Minor gaps remain around failure modes for invalid rail/asset combinations, but an agent has enough to call it 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 coverage is 100%, so the baseline is 3, but the description goes further by giving concrete example values (rail=base, asset=USDC) that clarify the expected identifier format and by repeating the operational 20-800 char band tied to the pricing rule.

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 ('Get the exact amount to pay for a passage') with the pricing rule and what is returned. An agent can distinguish this quoting tool from read_passage and submit_paid_line without opening a 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?

Makes the read-only quoting role explicit by stating 'Does not send payment', which implicitly routes payment to submit_paid_line, and the schema note points to read_spec for rail ids. It never states a when-to-use condition or explicitly names the alternative tool, so it falls 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, and destructiveHint=false, so the safety profile is covered. The description adds 'Free,' which is meaningful given the submit_paid_line sibling, but it discloses nothing about auth needs or what the read actually returns.

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 very short sentences with zero waste. The action is front-loaded and the directive 'Call this first' follows immediately, making the definition scannable at a glance.

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, no-output-schema tool this is nearly sufficient: it states the action, cost, and ordering. The remaining gap is that it does not clarify whether the story is returned in full or only the trailing passage.

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 and the schema coverage is 100%, so there is no parameter semantics for the description to compensate for. Baseline 4 applies for a parameterless tool.

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 the shared Stint story and its last passage. The phrase 'to continue from' clarifies the intent, but it never explicitly distinguishes itself from siblings like read_passage or quote_passage, which an agent must infer.

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?

'Call this first' is an explicit ordering directive, telling the agent this is the entry point of a workflow. However, it gives no when-not guidance or named alternatives, so the boundary against read_passage 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a cost signal ("Free") and the no-arg default, which is genuine added value, but "Free" is ambiguous and nothing is said about behavior on an invalid index or unknown hash.

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 primary operation and zero filler. The default behavior and cost note both earn their 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 two-parameter read tool with full schema coverage and no required arguments, the description is close to sufficient. The main omission is error/edge behavior (out-of-range index, hash with no passage), though no output schema exists to explain return shape.

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 parameters (hash, index) are already fully documented in the schema, including the 0-based indexing and the meaning of the hash. The description only restates the two modes and adds no format or constraint detail beyond 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 ("Read one passage") and enumerates the two lookup modes (index, transaction hash) plus the no-argument default. It is clear enough to act on, but it never distinguishes itself from the sibling read_last, which the no-argument behavior appears to duplicate.

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 implicit usage rule — omit all arguments to get the last passage — but does not say when to prefer hash over index, nor when to call read_last instead of this tool. Usage is inferable from the sibling list but not 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 establish readOnly, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It contributes the cost trait ('Free') and enumerates what is returned, which matters because there is no output schema and several siblings are paid operations.

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 terse sentences, front-loaded with the return contents and ending with the cost signal. No filler, no 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?

With no input parameters and no output schema, the description carries the burden of describing what comes back, and it does enumerate the returned content (rails, assets, addresses, formula, rules). It is nearly complete, only lacking explicit guidance on sequencing relative to the paid siblings.

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 the baseline is 4. There is no argument semantics for the description to clarify, and it correctly avoids inventing any.

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 specific verb (List) and enumerates the exact resource contents it returns: rails, assets, payout addresses, price formula, and rules. An agent can tell this is the spec/introspection tool without opening the schema, though it does not explicitly contrast itself with siblings like read_passage or quote_passage.

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. The trailing 'Free' hints that this is the zero-cost discovery step to call before paid siblings such as quote_passage or submit_paid_line, but the description never states when to use it or when another tool is preferable.

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 establish read-only, idempotent, non-destructive, non-open-world behavior, but the description goes further by disclosing cost ('Free') and the absence of side effects ('does not post or send anything'), and it summarizes the return payload. It adds real behavioral context beyond the annotations.

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, front-loaded with what the tool returns, then when to use it, then cost and side-effect constraints. Nothing is redundant and no sentence 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?

With no output schema, the description steps in to describe the return value (a link plus one-line share text), and for a parameterless-capable read tool the cost, scope, and side-effect profile are all covered. Nothing an agent needs to invoke 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%, so the schema already documents hash and index; the description adds the semantics that either parameter narrows the result to one passage while their absence yields the whole-story link. That mapping is meaningful beyond the field descriptions.

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 (get a share link) and defines scope precisely: whole story or a single passage selected by hash or index, plus a one-line share text. It does not name a sibling like read_passage or quote_passage, so it is clear but not sibling-differentiated.

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 states the use case directly ('Use it to show your user what was written') and adds an explicit negative boundary ('It does not post or send anything'), which steers the agent away from mistaking it for a sharing/publishing action. No named alternative tool is offered, so it stops short of a 5.

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 behavioral context beyond annotations: the write is irreversible ('public and permanent'), one payment maps to exactly one line, retries with the same hash and text are safe (refining idempotentHint with the actual conditions), and no funds are moved. This tells the agent about irreversibility, cost semantics, and idempotency boundaries that annotations alone only hint at.

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, front-loaded with action and precondition before secondary details. Most sentences earn their place (irreversibility, retry safety, no funds sent, return value), though the return-value sentence and the 'each payment publishes one line' note add slight length without being wasteful.

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 supplies the return value (share link), and it covers preconditions, permanence, cost semantics, and idempotency. The remaining gap is failure behavior: it does not say what happens if the hash is invalid, the quote expired, or rail/asset mismatch the payment.

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 the schema already documents every parameter, including the hash variants and text length bounds. The description only echoes 'transaction hash, rail, and asset' and adds no format, syntax, or cross-parameter constraints (e.g., whether rail/asset must match the original quote). 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 ('Publish a passage') and anchors it to the prerequisite state ('after you have already paid the quoted units'), which immediately distinguishes it from quote_passage in the sibling list. An agent can tell this is the on-chain settlement/publish step, not the quoting step, 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?

The precondition is explicit: only call this after payment of the quoted units has occurred, implying quote_passage must run first. It also notes the tool does not send funds. However, it never names quote_passage or read_passage as the alternatives, nor states what to do if payment has not been made.

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