Casii MCP

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

Annotations already flag destructive, idempotent, openWorld, and non-readOnly, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it explains how to use idempotency_key on retry to get the original execution, and warns that a new key is a new paid operation. It stops short of stating whether failed jobs are refunded or what happens to the existing execution.

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

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

Three short sentences, front-loaded with the core action, then the idempotency mechanics, then the cost warning. No filler or restatement of the name.

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

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

For a 7-parameter, nested-object, credit-charging mutation with no output schema, the idempotency and cost story is well covered but the payload semantics (items/targets, expected_credits accuracy, options) and failure/refund behavior are not. An agent can call it safely but cannot reason about the arguments from the description alone.

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

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

Schema description coverage is 0% across 7 parameters, and the description only gives meaning to idempotency_key ('Save a UUID'). export_type, count, items, expected_credits, timezone, options, and detection_token semantics (including the relationship between count and expected_credits) are left entirely to types and a single schema example.

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 specific verbs and resource: charge credits and enqueue export jobs. It clearly separates this from read-only siblings like list_export_jobs/get_export_job, and the word 'confirmed' implies a prior quote step, but no sibling (e.g. quote_export_jobs) 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 implied rather than stated: 'Charge confirmed credits' indicates this runs after a quote is confirmed, but the description never says to call quote_export_jobs first, nor when not to use this tool. The retry guidance applies only to uncertainty after a call, not to tool selection.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds genuinely useful operational context: it is free, creates no jobs, and returns a detection_token — none of which is in 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?

Three short sentences, front-loaded with the outcome, then the key parameter rule, then the cost side-effect. No filler.

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

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

For a 3-param tool with 0% schema coverage and no output schema, the description covers the return value and the critical export_type caveat, but omits what 'target' accepts (URL vs handle) and what 'options' contains, leaving real gaps.

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

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

Schema coverage is 0%, so the description must carry the load. It does explain export_type well (must be explicit because a URL cannot distinguish followers from following), but 'target' and the nested 'options' object are left completely undefined.

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 (validate) plus the artifact it produces (detection_token), which disambiguates the vague 'detect' name. It does not name a sibling tool, but 'creates no jobs' implicitly separates it from create_export_jobs/quote_export_jobs.

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?

'Free; creates no jobs' implies this is a cheap pre-step before job creation, but the description never explicitly says to call it before create_export_jobs or when to skip it. The one guidance sentence is about how to set export_type rather than when to invoke the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description nonetheless adds the non-obvious cost fact "no charge," which annotations do not express and which matters to an agent budgeting calls. It does not describe latency, caching, or what the balance represents.

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

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

Two short sentences, front-loaded with the purpose and followed by the one behavioral fact that matters. Every clause earns its place; nothing is padded or 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 is the only place return-shape information could live, and it says nothing about what a balance looks like (units, currency, whether it is a number or an object). For a simple read tool with full annotation coverage this is a minor but real 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?

The tool takes zero parameters and the schema is a strict empty contract, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level semantics are needed or missing.

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 ("Get your credit balance"), which is instantly distinguishable from every sibling, all of which concern export jobs/tools. It stops short of a 5 only because it never explicitly contrasts itself with alternatives — it relies on the resource name alone to do that work.

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: an agent reads this as "call when you need to know the current balance." There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives (none exist among siblings, but that is left to inference). Adequate for a trivial zero-arg getter, not strong 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 readOnly, idempotent, non-destructive, and non-open-world, so the safety bar is covered. The description adds real value beyond that: the URL is shareable by anyone holding it (a security property), it is stable/'fixed', it stays valid during continuation or failure, and it flags the XLSX-vs-CSV formula-interpretation risk.

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 core action and follow-on caveats that each carry information. No filler; slightly dense but every sentence earns its place.

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

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

With annotations covering the safety profile and no output schema needed, the description is nearly complete for a two-parameter fetch tool. The only omission is any characterization of the job_no identifier, which is likely self-evident but undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaningful semantics for the format parameter (CSV/XLSX behavioral differences), but the required job_no parameter is never explained in either the schema or the description, leaving a gap.

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

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

States a specific verb and resource: 'Get a shareable fixed CSV/XLSX URL for your job.' An agent can distinguish this download-URL tool from metadata siblings like get_export_job without opening a schema. It stops short of naming a sibling explicitly, so it does not reach a 5.

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

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

Usage is implied by 'for your job' and the note that the URL works 'while a continuation runs or fails,' which tells the agent the result is fetchable across job states. However, it never states when to prefer this over get_export_job, list_export_jobs, or resume_export_job, leaving routing 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 safety is covered. The description adds genuinely non-obvious context beyond them: no charge, and the side effect that calling it may wake an existing local execution.

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 tight sentences with zero waste. The returned-field list is front-loaded and the cost/side-effect caveat follows where it belongs.

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, and it enumerates the key fields well. Safety is covered by annotations; the only real gap is guidance on where job_no comes from and its relationship to resume/list tools.

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

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

Only one parameter (job_no) with 0% schema description coverage, and the description never explains its format or provenance (e.g. obtained from create/quote). The name is largely self-evident and 'your job' hints at ownership, but the description does not compensate for the schema gap.

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

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

States a specific verb ('Get') and resource ('job') and enumerates the payload the agent will receive (status, progress, credits used, price snapshot, errors, resume availability). It clearly reads as a single-job lookup distinct from list_export_jobs, but it never names a sibling or explicitly contrasts itself with them.

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

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

The description implies a polling/status-check use case and flags that the call is free and may wake a local execution, which is useful cost/effect context. However, it gives no explicit when-to-use guidance versus alternatives like list_export_jobs or resume_export_job, so the routing 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 establish readOnly, idempotent and non-destructive behavior, so the bar is low. The description adds a trait the annotations cannot express — 'Free' — telling the agent this is a zero-cost metadata lookup rather than a billable quote, which is genuinely useful for cost-sensitive planning.

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 is returned and then the follow-on chain. Telegraphic but every clause earns its place; no padding.

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

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

With no output schema, the description does the work by enumerating the return payload (input requirements, options, columns, limits, base pricing) and the sequencing. Only minor gaps remain around how to obtain a valid export_type and whether pricing is currency-specific.

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

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

Schema coverage is 0% for the single export_type parameter, so the description must carry the burden. 'selected from the catalog' usefully implies the value must come from list_export_tools, but it gives no format, case, or valid-value guidance beyond 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 states a specific verb and resource ('Get input requirements, options, columns, limits and base pricing') and scopes it to an export_type drawn from the catalog, which separates it from download/job-listing siblings. It does not explicitly name the sibling that produces the catalog (list_export_tools), so it falls just short of full differentiation.

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

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

It prescribes the workflow directly: pick an export_type from the catalog, 'Next detect the target, then quote_export_jobs.' Both downstream tools are named with their ordering, so the agent knows exactly what to call next and why.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds 'no charge' (billing context not in annotations) and the cross-source scope, but says nothing about pagination or return format.

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, front-loaded sentences with no wasted words; the scope qualifier is placed immediately after the core verb.

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?

Four optional parameters, an enum-bearing platform filter, and pagination defaults all go undocumented while there is no output schema to lean on. The description is too thin for a paginated, filterable list tool.

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

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

Schema description coverage is 0% and the description ignores all four parameters (page, search, platform, page_size). It does not compensate for the coverage gap, though the parameter names are partially self-explanatory.

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 ('List your jobs') and adds scope ('from both website and MCP'), which distinguishes it from the singular get_export_job sibling. It does not explicitly name siblings, so it falls short of a 5.

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

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

No when-to-use guidance and no routing to alternatives such as get_export_job for a single job or create_export_jobs. The agent must infer usage entirely from the name.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so credit goes to the added context: 'The returned catalog defines availability' tells the agent the response is authoritative, and 'Free' discloses cost. It stops short of describing the catalog's shape, but with the annotation profile established the remaining gap is minor.

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 trigger condition before the long content-type enumeration, which earns its place by helping the agent confirm coverage. Slightly dense, but no wasted sentences.

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

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

For a zero-required-param catalog tool with no output schema, the description supplies the trigger, the optional parameter guidance, the free-cost note, and the handoff to get_export_tool. Sufficient for an agent to invoke and continue the workflow.

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%, but the description compensates: it explains platform is optional and only to be set when known, and enumerates the covered platforms (though it omits 'gmap' from the enum). This adds real meaning beyond the bare $ref enum.

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 combination ('list export tools') plus the discovery framing 'Start here...'. It clearly distinguishes itself from get_export_tool, the sibling it routes the agent to as the next step.

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 ('when the user wants to export... data to CSV/XLSX'), how to parameterize ('Set platform when known; select export_type by user intent'), and names the follow-up tool ('then call get_export_tool'). Routing is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so 'Read-only' in the description is a restatement of structured data and earns no credit. 'No charge' is a genuine addition beyond the annotations (cost transparency relative to credit-consuming siblings like create_export_jobs and quote_export_jobs), but the description says nothing about result limits, pagination, or what 'companies' includes.

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 the purpose. Efficient, though the 'Read-only' half is redundant given the annotations, so not every word earns its place.

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

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

With no output schema and a single-parameter input, the definition is minimally sufficient for invocation, but it omits result shape, count limits, and match behavior. The 'no charge' note is the only differentiating behavior conveyed.

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% and the single 'query' parameter has only a length constraint, so the description must compensate — and it does not. It never explains what the query string matches (company name, page name, ad text, partial vs. exact) or whether it is required, which is the key ambiguity for this lookup.

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 and resource: 'Find Facebook Ad Library companies.' An agent can tell what the tool returns, but nothing distinguishes it from the sibling lookup_* tools (facebook_marketplace_locations, instagram_hashtags, instagram_locations) beyond the platform name embedded in the tool name itself.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or exclusions. The agent must infer from the name alone that this is the tool for resolving a company name to a Facebook Ad Library entity. The sibling set contains several near-identical lookup_ tools with no 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=true, idempotentHint=true and destructiveHint=false, so 'Read-only' is redundant. 'No charge' is a genuinely additive behavioral detail (cost/billing trait not covered by annotations) and is relevant next to billing siblings like get_credit_balance, but nothing about result shape, rate limits, or pagination is provided.

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, front-loaded sentences with no filler. The second sentence partially duplicates annotation data, which costs a little, but overall the definition is efficiently sized.

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

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

For a one-parameter lookup with no output schema, the description should at minimum clarify the query format and roughly what a 'location' result is. It leaves both the input semantics and the returned entity undefined, so the definition is thinner than the tool's minimal complexity still warrants.

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 single required 'query' parameter has 0% schema description coverage, and the description says nothing about what it should contain (city name, zip, address, free-text?). With the raw schema carrying no semantics and the description not compensating, an agent cannot confidently construct the argument.

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

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

States a specific verb ('Find') and resource ('Facebook Marketplace locations'), which distinguishes it from siblings like lookup_instagram_locations and lookup_facebook_ad_companies. It stops short of an explicit sibling differentiation statement, but the resource 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?

There is no guidance on when to use this lookup versus the other lookup_* tools, nor any mention of prerequisites or context such as needing a Marketplace seller location to proceed. 'Read-only; no charge' hints at it being a cheap discovery call, but no when/when-not condition is stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Read-only' is redundant restatement. The one genuinely additive fact is cost context ('no charge'), which the annotations do not convey. Beyond that, nothing about rate limits, result caps, or matching behavior is disclosed.

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?

Very short and front-loaded, with the purpose first and the safety/cost note second. Two terse fragments waste no words, though 'Read-only' duplicates the annotation and earns no space.

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 lookup tool with no output schema, the definition should convey what a returned 'hashtag target' looks like and how results are bounded. It instead leaves both the input semantics and the return shape completely unspecified, so an agent cannot predict outcomes.

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

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

Schema coverage is 0% and the description says nothing about the single required 'query' parameter — not its format, what values are accepted, whether it takes bare tags or terms, or why minLength/maxLength are constrained. The description fails to compensate for the undocumented 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 verb ('Find') and resource ('Instagram hashtag targets'), which distinguishes it from the sibling lookup_instagram_locations and lookup_facebook_* tools. However, 'hashtag targets' is vague about what is actually being found (hashtag suggestions? accounts using a hashtag? related hashtags?), leaving the scope ambiguous.

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 guidance, no prerequisites, and no mention of any alternative among the 13 siblings. The agent must infer everything about selection context.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description repeats 'Read-only' but adds 'no charge', which is genuinely new cost context not present in annotations; it omits rate limits and return behavior.

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, front-loaded sentences with zero filler; the core purpose plus the safety/cost note land immediately.

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 three-parameter, no-output-schema tool the description is thin: it leaves the all-optional parameter contract (which of query/lat/lng must be supplied, and whether they combine) unexplained, though annotations adequately cover the safety profile.

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% for three optional parameters. The description names the two input dimensions (query, lat/lng) but adds no semantics beyond the schema: it does not state that at least one of query or coordinate pair is required, nor any format or mutual-exclusivity rules.

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

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

The description names a specific verb+resource ('Find Instagram locations') and even states the two input modes (query or lat/lng). It is clearly distinct from siblings like lookup_instagram_hashtags and lookup_facebook_marketplace_locations, though it does not name a sibling to contrast 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?

It implies the two usage modes (text query vs. geographic coordinates), which is useful context, but gives no guidance on when to prefer one over the other, no prerequisites, and no routing rules against the lookup_* 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, idempotentHint, and destructiveHint=false, so the no-job/no-charge claim largely restates the safe-read profile. The description adds little beyond that, such as output shape, validation failure behavior, 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?

One clean sentence with the core action and constraints front-loaded. 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 5-parameter nested tool with no output schema and 0% schema description coverage, the description omits parameter guidance and return-shape information. Annotations cover safety, but they do not compensate for the missing invocation details.

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

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

Schema coverage is 0%, and the description only alludes to 'detected targets' without defining items/target/detection_token, export_type, count, options, or timezone. Required parameters remain opaque, leaving the agent unable to infer how to construct valid input.

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 specific actions (validate detected targets, quote total credits) and explicitly excludes creating jobs or charging, which distinguishes it from create_export_jobs. An agent can identify this as a dry-run quoting tool from the description alone.

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

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

Clearly signals use for pre-creation validation and cost quoting, and rules out job creation/charging. However, it does not name create_export_jobs as the follow-up action or explain when to prefer detect_export_target or get_credit_balance.

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

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

Annotations already flag destructive=true, idempotent=true and openWorld=true, but the description adds the material facts an agent actually needs: real credits are charged, the price is locked to the job's snapshot, and a fresh idempotency_key can trigger a second charge. That duplicate-charge warning is genuine behavioral disclosure beyond the structured 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?

Three tight sentences with no filler: the charge/enqueue action leads, the idempotency contract follows, and the double-charge warning closes. Every sentence carries distinct operational information.

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

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

For a money-moving mutation with no output schema, the description covers the charge risk, the price-snapshot semantics, and the retry protocol, which are the failure modes that matter most. It does not say what the continuation enqueues or what the call returns, a minor gap given there is no output schema to carry that.

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

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

Schema description coverage is 0% across four required parameters, so the description carries the burden. It meaningfully explains idempotency_key (UUID, save it, reuse it on retry) and implicitly explains expected_credits via the 'confirmed credits at the job price snapshot' model, but count and job_no receive no explanation at all.

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 concrete action: charge confirmed credits at the stored price snapshot and enqueue a continuation of an export job. That is a specific verb+resource, not a tautology of the name 'resume_export_job'. It never distinguishes itself from siblings like create_export_jobs or quote_export_jobs, so an agent must infer when resumption applies versus a fresh create.

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?

Strong guidance is given for the retry case: reuse the same idempotency_key and arguments to recover the original execution, and a new key may charge again. However, there is no statement of when to call resume_export_job at all, nor how it differs from create_export_jobs, so alternative selection 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.