Monocrawl

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description goes well beyond them: credit reservation and charging semantics, that refunded failures report zero and null means pending_reconciliation, that production never falls back to sample data, and that dry_run is free. These are non-obvious behavioral traits an agent could not infer from the safety hints.

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?

Purpose is front-loaded, but the middle is a dense run of loosely related clauses (credits, refunds, labels, fit, stored evidence, legacy params) with no grouping or headers, making it hard to scan. Almost every sentence carries information, so it is not padding, but the structure is flat and the reader must parse topic shifts themselves.

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 complex, nested-parameter, open-world read tool with no output schema, the description supplies the missing return contract ('data, credits_used, credits_remaining, request_id') and the failure semantics, plus the free/charged branching. An agent has enough to invoke it correctly and interpret the result envelope.

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 on top: how the free-form params object is used (dry_run="1", judgments="off", fit="goal", mode="rows"), the platform/endpoint pairings for stored evidence, and that cursor/path/page_size are strings while legacy fragments use limit. That is genuine value beyond the one-line schema 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?

States a specific verb and resource ('Retrieve public web data through supported read operations') and then explicitly delineates scope by excluding writes: 'Cannot create, edit or delete monitors, cohorts, jobs or browser sessions.' That negative scoping is exactly what separates it from the create/delete/execute siblings, so an agent can route 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?

Provides concrete conditions for variants: dry_run="1" for a free estimate, judgments="off" to disable labels, platform="utility" for free stored-evidence reads, and points to list_endpoints/get_endpoint for available operations and prices. What it does not do is contrast itself with the sibling get_result for retrieving stored results, leaving a possible overlap for the agent to resolve.

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 and non-idempotent, so the bar is lower; the description still adds real value by warning that cancellation may stop useful work, that refunds depend on work attempted, and that refund status must be read separately. It also notes the call is a free control operation, which the annotations do not convey.

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?

Six short sentences, each carrying a distinct fact, with the core action and the preview/execute split front-loaded. Dense but no filler; the refund caveat is placed where the agent needs 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?

No output schema exists, and the description compensates by naming the relevant return signal (refund_status) and stating the credential requirement (idempotency key). A mutation tool with this much behavioral framing 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?

With 75% schema coverage the schema already documents confirm, max_credits, and idempotency_key; the description reinforces these with cross-field dependencies (confirmation requires an idempotency key, previews do not consume it) that add meaning beyond the schema text.

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 ('Cancel a job belonging to this account') and immediately clarifies its dual mode (preview vs. execution). It is distinguishable from siblings like start_data_job, though it does not explicitly name a sibling to route against.

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?

Explains the selection condition between the two modes (omit confirm for a status read, confirm=true to execute) and routes the agent to read refund_status rather than assuming a refund. No explicit 'when not to use' beyond that, but the operative context is clear.

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 value beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing two non-obvious consequences: closing ends browser access, does not refund the creation charge, and the control operation itself is free. It does not say what happens to an already-closed session or what a preview 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?

Four short sentences, front-loaded with the core action and then the confirmation/charge constraints. No filler, though the final 'Free control operation.' is a fragment that could be folded into the charge sentence.

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 4-param mutation with an annotations-covered safety profile and no output schema, the description covers the critical consequences an agent needs (preview vs execute, charge not refunded). Only the return value of a preview and no-op behavior are 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 75%, so the schema already documents confirm, idempotency_key, and max_credits. The description reinforces the confirm/idempotency coupling but adds no format or edge-case detail beyond what the schema text already says, so 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 ('Release an account-owned browser session'), which cleanly distinguishes it from the sibling create_browser_session. It is clear but stops short of explicitly contrasting with other session/lifecycle siblings such as execute_browser_session or cancel_web_job.

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?

Explains the preview-vs-execute pattern: 'Without confirm=true, read the session only' and that confirmation requires an idempotency key. That gives a clear condition for each mode, though it never names an alternative tool to reach for 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 destructiveHint, openWorldHint and non-idempotency, so the bar is lower. The description still adds real value: creation is charged, early closure does not guarantee a refund, and the required prerequisites for execution. It stops short of describing return content or session lifecycle/TTL behavior itself.

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, front-loaded with the action and immediately followed by prerequisites. No filler, though the cost/refund sentence could be slightly compressed.

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, cost-incurring mutation with no output schema, the description covers confirmation, idempotency, credit limits, pricing lookup and refund limits. Only the session lifecycle (TTL behaviour after creation) is left to get_endpoint, which the description explicitly points to.

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 all four parameters are already documented, including the confirm/dry_run interplay and idempotency-key reuse. The description's parameter claims largely restate the schema rather than adding new syntax or format detail, making 3 the correct baseline.

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 ('Preview and open an account-owned hosted browser session') plus optional navigation to a URL, which separates it from the read/list siblings. It does not explicitly name or contrast with execute_browser_session or close_browser_session, so sibling differentiation relies on 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?

Gives concrete execution prerequisites (confirm=true, idempotency key, max_credits) and routes the agent to get_endpoint web/sessions/create for price and TTL limits. It implies preview-vs-execute usage but never states when to prefer this over execute_browser_session.

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 the safety profile (readOnly=false, destructive=true, openWorld=true, idempotent=false), yet the description adds real behavioral context beyond them: credit cost at creation, per-run charges up to the shown estimate, the mandatory two-step confirm flow, and that runs persist with the client closed. The idempotency_key guidance also clarifies the non-idempotent default without contradicting the annotation.

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 core purpose, then cost, confirm flow and capabilities in a compact sequence. A couple of statements (confirm flow) duplicate the schema descriptions, but nothing is wasted at the sentence level.

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 20-param, no-output-schema, destructive, open-world creation tool, the description covers cost, confirmation, supported kinds and filtering semantics well. It does not explain what creation returns or per-kind required parameters, 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 75%, so most parameters are self-documented; the description adds meaning for relevance_enabled/relevance_prompt/exclusions ('same backend filter as the dashboard') and reiterates the confirm flow. It leaves many params (feed_params, params_json, endpoint, platform, sources, purpose, delivery_webhook) unexplained, so it only marginally exceeds the schema baseline.

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 and scope ('Watch a subject across platforms on a schedule') and enumerates the supported monitor kinds (subject, feed, change). An agent can distinguish it from run_monitor/update_monitor/delete_monitor by the create verb, though it never names 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?

Gives explicit, actionable context: 'Requires confirm=true — call once without it to get the plan and estimate, then again with confirm=true to create.' This is clear when-to-use flow guidance, but it offers no exclusion against alternative siblings such as update_monitor.

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 safety profile is covered. The description adds genuinely new context beyond that: irreversibility and the confirm-gated preview behavior where an unconfirmed call returns a description instead of deleting.

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, front-loaded with the destructive action and its irreversibility, then the confirm requirement. 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 usefully hints at the return behavior of an unconfirmed call ('the monitor is described'). Idempotency_key behavior is carried by the schema itself, so nothing critical is missing for calling the 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 33% (only idempotency_key is documented), so the description must compensate. It explains the semantics of the undocumented confirm flag, including its dry-run effect, though it leaves the id parameter implicit.

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 (Removes) plus resource (the monitor) and adds the side effect that its schedule stops. This clearly distinguishes it from get_monitor, update_monitor, and create_monitor among the 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?

Gives explicit operational guidance: confirm=true is required, and without it nothing is deleted and the monitor is merely described (a dry-run/preview path). It does not name an alternative sibling tool, but for a delete operation the when-to-use context is complete.

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/openWorld, but the description adds what those costs mean in practice: code can click, type, submit forms or alter a website, so the exact code and URL should be reviewed; execution is billed separately from session creation; confirm=true, an idempotency key and max_credits are all mandatory; and it is a hosted browser, not a local shell. This is well beyond the annotation bar.

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 action and the safety warning before cost and prerequisite details. Every sentence carries information, though the pricing-pointer and status-pointer sentences make it denser than strictly necessary.

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, nested-object, no-output-schema tool, the description covers cost, authorization prerequisites, preview semantics and a status-check sibling. The only real gap is what execution returns, which the description leaves unaddressed despite there being no output schema to fall back on.

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 80%, so the schema already documents confirm, max_credits, idempotency_key and params. The description reinforces that params come from get_endpoint and are strings, and that confirm gates preview vs run, but adds little syntactic or semantic detail the schema lacks. Baseline 3 fits.

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?

Opens with a precise verb+resource+scope: 'Execute JavaScript in an existing account-owned browser page, optionally navigating first.' It distinguishes itself from create_browser_session ('existing'), from generic code execution ('not a local shell'), and names the sibling used for pre-run inspection.

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 explicit when-to-use branching: omit/false confirm for a free preview, confirm=true to actually run, and points to call_endpoint web/sessions/get for status and get_endpoint web/sessions/execute for pricing. Alternatives and prerequisites are spelled out rather than inferred.

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/non-destructive, so the safety profile is covered. The description adds real value beyond that: it distinguishes the connection spending cap from account funds, explains that null means no connection cap, notes the cap can be changed at manage_url without reconnecting, and states the call is free even at the cap. These are behavioral traits the annotations do not convey.

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 compact and front-loads the returned fields before the clarifying semantics. It is somewhat field-list-heavy in the opening sentence, but every subsequent sentence (spending-cap meaning, null semantics, manage_url, cost) 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?

There is no output schema, so the description effectively serves as the return-value documentation and lists the fields it returns, which is the right call. For a zero-parameter read tool this is largely complete, though field types/formatting and ordering are not described.

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 per the rubric the baseline is 4. There is nothing to clarify and the description correctly adds no parameter content.

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 enumerates the returned fields (account credits_remaining, credits_lifetime, updated_at; connection credit_limit, credits_used, credits_remaining, manage_url), which makes clear the tool reads credit/balance data. However, it never states the purpose with an explicit verb+resource phrase like 'returns the current credit balance'; the purpose is inferred from the field list plus the title. It is unambiguous but rests on sibling-irrelevant inference rather than an explicit statement.

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 when-to-use or when-not-to-use guidance, and no mention of any alternative tool. The only contextual aid is the cost statement ('Free — costs 0 credits'), which is informative but not usage guidance. The agent is left to infer when this call is appropriate.

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 safety (readOnly, idempotent, non-destructive), and the description adds behavior they do not carry: no API key required, no credit charge, documentation reads never execute or bill a request, and output is bounded with a null-terminated cursor. That is exactly the extra context an agent 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 sentences, well front-loaded, with the reading/pagination contract stated before the cost disclaimer. The final sentence slightly repeats the earlier 'without a key or credit charge' claim, a minor redundancy rather than a flaw.

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 compensates by describing the return format (Markdown), the chunking model, and cursor termination. With annotations covering safety and the schema covering all three params, nothing an agent needs to call this 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 baseline is 3, but the description adds meaning beyond it: concrete topic values to pass and the termination rule for 'cursor' (follow the same topic until null), which the schema only vaguely calls an 'opaque continuation'.

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 concrete verb and resource ('Read public guides as Markdown') and names the exact topic space (index, mcp, quickstart/agents, platforms/tiktok, endpoints/tiktok/profile). It is unmistakably the documentation reader among siblings like call_endpoint, get_endpoint and run_monitor.

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 consumption context: returns a bounded chunk and you follow the cursor with the same topic until null, and restarting without a cursor is the remedy if the doc changed. There is no explicit when-not guidance or named alternative, but no sibling competes for this doc-reading job.

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 readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral facts: it is free (0 credits), it does not execute or charge, and the params input is discovery-only rather than a reservation. These are exactly the traits an agent needs and cannot get from 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?

A single dense sentence that front-loads the return contents and closes with the cost caveat. Every clause carries information, though the em-dash chain makes it slightly harder to scan than separate sentences would.

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 carries the return-value burden, and it does so by enumerating the response sections. Combined with the cost and non-execution notes, an agent has enough to call it correctly; only pagination/format details are absent, which is minor for a single-item introspection 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 100%, so the baseline is 3, but the description goes beyond it by explaining what the optional params actually does business-wise — it yields an effective probe plan without running or charging, and is explicitly not a reservation or availability guarantee. That is real semantic value for the second parameter.

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 resource and enumerates exactly what the response contains (accepted parameters, optional inputs, prices, ready-to-run example), which distinguishes it from list_endpoints and call_endpoint. It never uses a clean verb like 'describe', but the noun-plus-contents framing 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?

It implies the discovery use case ('include params to receive its effective probe plan without running or charging it') and contrasts implicitly with the calling sibling, but never names an alternative or states when not to use it. Usage is inferable rather than spelled out.

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 genuinely useful trait not present in structured fields — that the call is free and costs 0 credits — which matters for a metered API.

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 clauses, front-loaded with what is returned before the cost note. Very little waste, though 'Free — costs 0 credits' is slightly redundant.

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 usefully enumerates the payload contents and the cost, and the single parameter is fully documented in the schema. Complete enough for a simple read tool, though it says nothing about what happens if the id does not 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 description coverage is 100% and there is a single required id parameter with format guidance ('mon_…') already in the schema. The description adds nothing about the id, 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?

The description states a specific resource and scope: retrieving one monitor 'in full' and enumerating the notable fields it returns (relevance_enabled, relevance_prompt, exclusions, recent runs, receipts). The word 'One' implicitly distinguishes it from list_monitors, but no sibling is named 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?

Usage is only implied: 'One monitor in full' suggests this is the single-record fetch as opposed to list_monitors, but there is no explicit when-to-use statement, no mention of prerequisites, and no named alternative such as list_monitors or monitor_findings.

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 the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial unannotated behavior: bodies are never shortened or split, an 8 MiB download ceiling with a credential-free URL, 24-hour expiry, same-account-only access, and an explicit prompt-injection warning that source content is evidence, never instructions.

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 value proposition (no rerun, no credits) followed by tightly packed operational rules; almost every sentence carries a distinct constraint. Slightly dense and occasionally terse ('Read already-paid evidence'), but there is little redundant 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, no-output-schema pagination tool with mode switching, the description supplies everything needed to call it correctly: mode choice, cursor continuity, path selection, page limits, oversized-row escape hatch, auth scoping, expiry, and a link to the API reference.

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 beyond the schema by tying cursor reuse to the same mode, describing path auto-selection and the requirement to hold the same path while paging, and clarifying page_size's dual cap (row count and 256 KiB). These are behavioral constraints the schema does not express.

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 (Read) and resource (already-paid stored result evidence) and immediately distinguishes itself from the sibling that would re-run work via 'without rerunning or spending credits'. An agent can tell this is a replay-of-stored-data tool, not an execution tool like call_endpoint.

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?

Explicit conditional guidance: use mode="rows" for intact structuredContent pages, legacy default mode="text" returns fragments that must be concatenated when cursor is null, select a path from returned choices, and fall back to the authenticated full JSON download only for oversized rows. Alternatives and their triggers are all named.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new operational context beyond that: it is a bounded page, cursor-continuation behavior, and the cost fact 'Free — costs 0 credits', which no structured field provides.

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 what a page contains, then the compact/get_endpoint routing, then filters and cost. No filler; each sentence supplies 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?

With no output schema, the description correctly states the shape of returned entries, covers pagination via cursor, and discloses the free-of-charge behavior. Nothing an agent needs to invoke this read-only listing 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 limit, cursor, search, compact and platform are all documented in the schema; baseline 3 applies. The description reinforces compact's effect on payload size and the filter axes, but adds no syntax beyond what the schema already states.

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 the specific verb+resource (list the public endpoint catalogue) and enumerates the returned fields (id, name, credit cost, parameters, description). It explicitly positions itself against the sibling get_endpoint, so an agent can distinguish the two without opening 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?

Says when to use it (browse/filter the catalogue) and names the alternative for depth: 'use get_endpoint for full details', plus the compact toggle and platform/search filters. It lacks an explicit when-not-to-use case, but the routing condition is clear.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds one genuinely useful non-annotation fact — the call is free (0 credits) — but says nothing about pagination behavior, despite the limit/cursor parameters, or ordering guarantees.

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, zero filler, with the scope statement front-loaded and the cost note placed last. The field enumeration is long but carries 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?

With no output schema, listing the returned fields is a real contribution, and the annotations cover safety. However, a paged list tool should explain cursor/limit usage and default ordering; those gaps leave the agent guessing how to iterate results.

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 67%, and cursor has no schema description at all. The prose instead documents output fields (relevance_enabled, exclusions, schedule) rather than input semantics, so it adds nothing on limit, cursor, or status and does not compensate for the uncovered cursor parameter.

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 ('Every monitor on this account') and enumerates the returned fields, which separates it from get_monitor (single) and monitor_findings. It never names a sibling explicitly, so an agent must still infer that this is the list-all variant rather than an alternate retrieval path.

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 'Every monitor' (bulk retrieval) and by the cost note, but there is no explicit when-to-use or when-not-to-use guidance relative to get_monitor, monitor_findings, or list_endpoints. The agent is left to infer the 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?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true). The description adds genuinely non-structural context: the change is limited to unread status and the call is free/no credit charge, which helps an agent decide to invoke it. It still omits whether the change is reversible and that the scope is per-page.

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 action and effect, with the cost note last. No filler, though the pagination hint is too terse to be actionable.

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 4-parameter mutation with no output schema, the description covers the effect and cost but leaves the meaning of id/limit/cursor and the preconditions (which id, whose account, per-page scope) unstated. Annotations carry the safety profile, so the remaining gap is moderate rather than severe.

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% — only idempotency_key is documented in the schema. The description does not explain id, limit, or cursor at all; 'returned page' weakly implies limit/cursor pagination but gives no format, required-source, or semantics. With low coverage the description should compensate and does not.

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 ('mark the returned page of findings as seen') and a concrete effect ('changes their unread status'). It does not explicitly distinguish itself from the closely related sibling monitor_findings, which likely lists the same findings, leaving the read-vs-mark split 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 when-to-use, when-not-to-use, or prerequisite guidance is given. The 'returned page' phrasing hints the tool operates on output of a prior listing call, but the agent is never told to call monitor_findings first or which sibling this replaces.

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 the bar is lower; the description adds two genuinely non-structured facts: result ordering ('newest first') and cost ('Free — costs 0 credits'). It stops short of describing pagination behavior or result volume, which the agent would still have to discover.

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 with zero filler: ordering, filter semantics, and cost. Each sentence earns its place and the resource identity 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 and no annotation covering cost or ordering, the description supplies both, plus filter semantics — the essentials for calling it correctly. Missing only pagination mechanics (how cursor/limit interact) for full completeness.

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; it explains only the 'unseen' boolean and implies 'id' (a monitor's findings). 'limit' and 'cursor' are left undocumented, though their pagination roles are conventional and 'newest first' hints at ordering. Adequate but with a clear gap for a 4-param 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 the resource (a monitor's findings) and its shape ('evidence links and receipts, newest first'), which is enough to distinguish it from siblings like get_monitor, run_monitor, and mark_monitor_findings_seen. It never names a verb explicitly, but the noun phrase is unambiguous as a read/list of findings.

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 a conditional for the unseen filter ('for only what has not been marked seen') and notes that calls are free, which helps an agent decide to call it. However, it never says when to reach for this tool versus get_monitor, run_monitor, or get_result, leaving the routing to inference from sibling names.

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 openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context beyond annotations: the charging model (billed at per-run estimate, settled to actual usage) and the no-charge preview path. It omits rate limits and auth requirements, keeping it short of 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 tight sentences, front-loaded with the action, then cost, then the blocking requirement. Every sentence earns its place — no filler, no repetition of 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?

No output schema exists, yet the description covers what a preview call returns (the estimate) and the billing settlement behavior. Combined with annotations covering the safety profile, an agent has enough to call correctly; only the id parameter and any rate expectations are left unstated.

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%, so the description must carry weight, and it does by fully explaining the semantics of the undocumented 'confirm' parameter. The required 'id' remains undocumented anywhere, but it is self-evident as the monitor identifier, and idempotency_key is already covered 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 scope — 'Queue one check immediately' — which clearly reads as a single manual run of a monitor. It is distinct from create_monitor/update_monitor in intent, though it never names a sibling to differentiate itself explicitly. The idea is unambiguous but sibling routing 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?

Provides strong how-to-call guidance: the confirm=true requirement and the fact that omitting it yields an estimate with no charge, establishing a preview-then-confirm workflow. It does not, however, say when this tool should be chosen over alternatives (e.g. create_monitor or execute_browser_session), so context 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?

Goes well beyond the annotations by disclosing that an accepted job is not completed data, that retrieval is free, that a browser agent may interact with live pages and its URL/task should be reviewed before confirming, and that refund_status must be inspected. These are operational traits the destructiveHint/idempotentHint flags alone cannot convey.

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 preview-vs-execute distinction is front-loaded and each sentence carries a distinct instruction, but the final docs URL and some list density slightly dilute focus. Still efficient for the amount of behavior it must convey.

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-param, nested-object mutation tool with no output schema, the description covers the full lifecycle: preview, confirmation requirements, idempotency, the absence of polling, the follow-up retrieval call, and what to read in the response. Nothing essential to 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?

At 67% schema coverage the description adds real meaning: it maps which platform/endpoint combinations are valid verbs (web/crawl vs tripadvisor/restaurant/reviews), clarifies confirm gating, and points to get_endpoint for the params object. It reinforces rather than duplicates the schema's per-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?

Names a specific verb pair ('Preview and start') and enumerates the exact endpoint families it covers (web/crawl, web/batch-scrape, web/agent, tripadvisor reviews), so an agent can distinguish it from siblings like call_endpoint or run_monitor. It stops short of an explicit contrast with those siblings, but the scope 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?

Gives explicit when-to-use conditions: omit confirm for a free estimate, confirm=true requires an idempotency key and max_credits, no automatic polling, then follow status_url via call_endpoint web/jobs/get. It names both the prerequisite and the follow-up tool, leaving almost nothing 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 and non-idempotent behavior, but the description adds material context those annotations cannot convey: the operation costs 0 credits, and omitting confirm=true yields a safe preview rather than applying changes. It stops short of saying what is destroyed 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 compact sentences front-load the editable fields, then the cost fact, then the confirm prerequisite. Every sentence carries information, though the confirm/preview sentence could be tightened 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?

For a 12-parameter mutation on a destructive, non-idempotent tool with no output schema, the description covers the critical gate and preview behavior. Gaps remain around idempotency_key reuse and relevance-filter parameters, which an agent handling retries would want spelled out.

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 58% across 12 parameters, so the description only partly compensates. It clarifies the semantics of status, name, schedule_minutes, the confirm gate, and groups delivery channels, but says nothing about exclusions, relevance_prompt, relevance_enabled, idempotency_key, or the deprecated monthly_cap_credits.

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 the mutation verbs and the specific fields it edits (status, name, schedule_minutes, delivery), which is far more specific than the title alone. It does not, however, distinguish itself from siblings like get_monitor, delete_monitor, or create_monitor, so an agent must infer this is the edit path from the name.

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 concrete invocation conditions: confirm=true is required to resume or change the schedule, and without it the call returns a preview of the current monitor plus proposed changes. That is real when/how guidance, though it never names alternatives for reading (get_monitor) or removing (delete_monitor) a monitor.

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