Contrie

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

The description discloses key behavioral traits: it costs zero extraction credits, reserves no capacity, and requires account authorization. These are important operational details that go beyond what annotations would provide (and no annotations are present). It doesn't describe the exact response format, but for a zero-parameter read tool, the disclosed behavior is quite complete.

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 compact and front-loaded: the first sentence states the core purpose, the second covers cost/resource behavior, and the third clarifies advisory nature. Every sentence adds value, and there is no redundancy or 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 zero-parameter, read-only account status tool, the description is complete. It covers what the tool does, when to call it, what it costs, what it doesn't guarantee, and what authorization is needed. There is no output schema, but the description sufficiently describes the returned information.

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 has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining what the tool reads and what it returns, which is the relevant semantic content. A baseline of 4 is appropriate for a zero-parameter tool where the description explains the tool's purpose and output.

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 clearly states the tool's purpose: reading account credits and restrictions. It specifies the resource (own account) and the exact data returned (used, reserved, unreserved credits, reset date, restrictions). It distinguishes itself from siblings by focusing on account status rather than extraction or changes.

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 provides explicit usage guidance: call before first or repeat work, not in a polling loop. It also clarifies that eligibility is advisory and that source/service/request-specific checks still apply, which helps the agent decide when to use this tool versus relying on it as a definitive gate.

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 provided, the description carries the full burden and does a solid job: it discloses the output shape (latest answer, 20 events, before/after responses, evidence, field diff) and the authentication prerequisite (API key). The verb 'Read' implies a non-mutating operation, though it does not explicitly state side-effect-free behavior or rate-limit details.

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 compact and front-loaded, stating the core purpose in the first phrase, then adding useful output details and the API key requirement. Every sentence contributes essential information with no filler or repetition 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 single-parameter read tool with no output schema and no annotations, the description provides a strong picture of what the agent will receive and what is required to call it. It could go further by explaining error conditions or the meaning of 'evidence status', but the essential call and response context is adequately covered.

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% and the only parameter, id, is already documented as 'The monitor id from contrie_watch'. The description adds no further parameter-level meaning beyond referring to monitors, so the schema already carries the semantic weight. Baseline 3 is appropriate.

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 ('Read') with a specific resource ('a monitor's history') and enumerates concrete contents: latest answer, evidence status, and the last 20 events with diffs. This clearly distinguishes it from the sibling tools, especially contrie_read, by scoping it to monitor history rather than a generic read.

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 makes the tool's context clear: use it to inspect a monitor's history and recent events. It does not explicitly contrast it with contrie_read or other siblings, but the resource-specific wording gives enough guidance for an agent to select it appropriately. No misleading or alternative-referencing exclusions are present.

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 behavioral burden, and it does so thoroughly. It discloses the return metadata (qualityScore, grounding, progress, credits), clarifies the limits of grounding ('does not establish factual truth or correct field association'), states authentication requirements, explains rendering behavior and its credit cost, and notes caching nuances (via the maxAge parameter). This is a model of transparent disclosure.

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 dense but well-structured: it leads with the core action, then lists return fields, then covers auth and exceptions, and finally notes limitations and costs. Every sentence adds information; there is no fluff. It is longer than typical because the tool is complex, but it earns its length. A minor deduction for density, but it remains efficient.

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 tool with six parameters, one nested object, and no output schema, the description covers almost everything an agent needs: how to specify extraction, what is returned, grounding limitations, authentication, rendering options, caching, and credit charges. It even mentions the /llms.txt special case. The only minor gap is error handling, but that is not essential for correct invocation. It is effectively 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the two complementary ways to specify extraction: natural language (extract) and JSON Schema (schema), and how they can be combined ('and/or'). It also adds auth context not present in the schema. This exceeds the baseline but doesn't dive into each parameter's format since the schema already handles that.

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 opens with a precise verb and resource: 'Extract structured data from one public web page.' It also explicitly disambiguates from related tools by stating 'Not a crawler or a search engine: one page per call,' which clearly separates this extraction tool from any sibling that might handle crawling or broad searching. The purpose is unmistakable.

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 clear context for when to use the tool: it is for single-page extraction, not crawling or searching. It also specifies a conditional usage: 'Eligible JavaScript shells can use bounded browser rendering,' and notes that exact recorded requests from /llms.txt work without an API key. However, it does not explicitly name sibling tools or contrast with contrie_read or contrie_verify, so the guidance is strong but not fully explicit about alternatives.

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 provided, the description carries the full disclosure burden. It reveals the credit cost (1 credit, plus 2 for rendering), the exact response shape (data null, markdown, metadata with credits and evidence status), the requirement for an API key, and the rendering behavior. This is thorough for a read 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?

The description is information-dense but efficient. The core purpose is front-loaded, and every subsequent sentence adds value: costs, response format, usage guidance, auth, and rendering. 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 tool with no output schema and four parameters, the description covers the essential operational context: response structure, costs, authentication, rendering options, and sibling differentiation. Nothing an agent needs 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 description coverage is 100%, so the schema already documents all parameters. The description adds the constraint that the URL must be 'public' and explains credit costs, but it does not elaborate on parameter semantics beyond what the schema states. Baseline 3 is appropriate.

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 clear verb ('Read'), a specific resource ('one public web page'), and the output format ('clean, structure-preserving markdown'). It explicitly distinguishes itself from the sibling contrie_extract by noting the latter is for typed fields, making the tool's purpose 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?

Provides an explicit routing rule: 'Use this when you just need to read a page; use contrie_extract when you need typed fields.' Also explains when browser rendering applies (JavaScript shells), giving an agent a clear decision path for when to invoke this tool versus alternatives.

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 behavioral burden and does so thoroughly: it discloses cost (no credits), auth requirement (API key), output behavior (appear/do-not-appear with supporting excerpts), and a key limitation (field-mismatched values still read as grounded). This is exemplary transparency for a verification 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?

The description is front-loaded with the core action and well organized. It is slightly longer than strictly necessary and partially restates the title, but every sentence carries meaningful semantic or behavioral information, so 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?

Given no output schema, the description fully explains what the tool returns (which values matched, which did not, with excerpts), how to supply the source, the auth/cost profile, and the main caveat about field grounding. An agent has enough to invoke it correctly without further 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 coverage is 100%, so the baseline is 3. The description adds general context about how data, url, html, and text relate to each other, but does not add parameter-level detail beyond what the schema already documents. It is adequate but not additive enough to raise the score.

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 states a specific verb ('check'), resource (extracted data vs. its source page), and method (field-by-field match with excerpts). It clearly distinguishes verification from extraction/reading by saying it works on data from any source, and it explicitly separates 'is this value present' from 'does the page say this about that.'

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 explicit when-to-use guidance ('Use it to bound invention before you act on data you did not verify yourself') and clearly states what the tool does NOT answer. It does not name sibling alternatives directly, but it positions itself against extraction and reading tools well enough for an agent to select it.

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 handles it thoroughly. It discloses the immediate baseline run, scheduling behavior with possible delayed/missed slots, what is recorded on change, the POST attempt with X-Contrie-Signature and one-time secret, cost per accepted run, and the API key requirement. This gives the agent an accurate mental model of side effects and external calls.

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 front-loaded with the core purpose and every subsequent sentence adds operational or behavioral detail: scheduling, change recording, webhook behavior, cost, and auth. It is dense but not bloated, and no sentence is redundant or 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 tool with five parameters, no output schema, and no annotations, the description covers invocation prerequisites, scheduling constraints, side effects, result access, cost, and security-relevant webhook behavior. An agent has enough context to call the tool correctly and interpret what happens afterward via contrie_changes.

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 a baseline of 3 applies. The description adds value beyond the schema by explaining webhook signing, the one-time secret disclosure, cost behavior, and baseline-run semantics. It does not fully re-explain each parameter, but it meaningfully enriches the most behaviorally complex ones.

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 opens with a specific verb and resource: 'Watch one public web page for one question and be told when the answer changes.' This clearly distinguishes monitoring from the single-shot extraction implied by contrie_extract and from reading recorded results via contrie_changes. The scope and intended outcome 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?

The description conveys when to use the tool: when one page and one question need ongoing change monitoring. It also clarifies prerequisites (public page, API key) and points to contrie_changes for reading results. It does not explicitly enumerate when not to use it or name contrie_extract as the one-time alternative, 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.