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

With no annotations, the description fully carries the behavioral burden and does so well: it discloses zero writes in advisory mode, exactly one staging import in staging mode, bounded candidate previews, and explicit non-actions (never resolves, commits, publishes, or archives). This gives an agent a clear side-effect and safety profile.

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

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

The description is compact and well-structured: a one-sentence purpose followed by two mode-specific behavioral sentences. Every clause adds meaningful information, and the most important zero-write distinction 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?

The description is strong on side effects and mode boundaries, and an output schema exists so return values need not be explained. However, it does not clarify how the dataset is supplied, what mapping means, or what 'bounded candidates' concretely implies, so an agent still lacks key input-context needed to invoke the tool reliably.

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 for the six parameters, but it only explains the stage parameter's mode behavior. layer_id, filename, mapping, csv_content, and geojson_content receive no semantic explanation, leaving their roles and required format ambiguous.

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 clear purpose: advisory dataset-vs-layer comparison, with mode-specific behavior. It does not explicitly name sibling tools, but the comparison focus and staging-only side effects distinguish it enough from list/get/inspect/summarize 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?

The description gives useful mode-based usage guidance: stage=false for zero-write advisory checks, stage=true only in staging mode. However, it does not mention when to prefer this tool over alternatives like inspect_layer, summarize_import, or infer_csv_mapping, nor any explicit when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'ordered provenance' but does not explain what that entails (e.g., whether it includes import history, source lineage, or computational steps), nor does it describe the output format, error handling, or performance implications. For a retrieval tool with an output schema, this lack of behavioral context is a gap.

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

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

The description is a single sentence of 11 words, front-loading the primary action and the key detail ('full, including ordered provenance'). It is concise and to the point with no fluff.

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?

The tool has a simple single-parameter input and an output schema (though not provided here), so the description does not need to explain return values. However, given that annotations are absent and the description lacks context on what 'ordered provenance' means or when to use this tool, it is not fully complete. For a simple retrieval tool, it is adequate but not thorough.

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% (the schema only provides the type 'string' with no description for feature_id). The description does not explain what feature_id represents (e.g., an ID format, whether it is a UUID or numeric, or how to obtain it). This is a deficiency because the parameter is required and undocumented. A 3 is given because at least it is clear that the parameter is the identifier, but more detail is needed.

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 clear verb ('Return') and resource ('feature'), and adds a specific detail ('in full, including its ordered provenance'), which distinguishes it from the sibling list_features. It does not explicitly name the sibling, but the detail about full detail vs. list is enough to infer the difference.

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 does not state when to use this tool versus alternatives. It implies that it is for retrieving a single feature's full detail (as opposed to list_features), but does not provide explicit conditions or mention alternatives like get_layer or list_sources. An agent might not know if this is the right tool for a given task without additional 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?

With no annotations, the description carries the burden of behavioral disclosure. It states the return value (one summary plus CSV mapping) and implies a read-only operation, but it does not describe behavior for missing/invalid import_id, authentication requirements, or any limitations. The basic output is clear, but deeper behavioral context is absent.

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

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

The description is a single, front-loaded sentence that directly states the action and result. There is no filler or repetition; every word contributes to understanding the tool's core purpose.

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

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

For a simple one-parameter retrieval tool with an output schema, the description conveys the essential return value. However, it does not clarify the relationship to sibling tools or handle edge cases, so the context is adequate but not fully complete for an agent deciding among many import-related 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?

Schema description coverage is 0%, so the description must compensate for the undocumented import_id parameter. It does not explain the format, source, or semantics of import_id beyond the parameter name itself. Since there is only one parameter and it is relatively self-explanatory, this is a moderate gap rather than a severe one.

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

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

The description uses a specific verb and resource: 'Return one import summary with its CSV mapping.' It clearly identifies this as a singular fetch operation, which distinguishes it from list_imports (plural listing) and from related tools like summarize_import or infer_csv_mapping by mentioning the CSV mapping. This leaves little ambiguity about what the tool returns.

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 guidance is given about when to use get_import versus its siblings such as list_imports, get_import_rows, or summarize_import. An agent must infer from the name and output schema alone that this is the singular summary retrieval path, which is not explicit.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It only states 'Return' which implies a read operation, but it does not clarify idempotency, caching, or what 'generic configuration' includes (e.g., may be metadata vs. actual data). It also doesn't mention whether it requires prior setup (like a layer being imported) or if it can operate on any layer.

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

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

The description is very concise, one sentence, and uses clear language. It is well-structured for quick scanning Per the rubric, this is not a flaw in itself, but it is under-specified for a tool with no other documentation. The sentence is efficient but leaves out critical details.

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

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

Given that the tool is simple (one parameter) and has an output schema, the description could be minimal, but it is still incomplete. The output schema exists, so the return structure is known, but the description does not clarify what a 'complete generic configuration' means, nor does it differentiate from 'inspect_layer' which likely provides a similar config. Given the low complexity, a 3 is fair: it covers the basic task but lacks important context.

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 there is only one parameter, 'layer_id'. The description does not explain the format or meaning of 'layer_id' (e.g., is it a string identifier, an integer, a UUID?). It does not provide examples or mention that the layer must exist, so the agent might not know how to populate this parameter correctly.

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

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

The description clearly states the verb 'Return' and the resource 'complete generic configuration for one layer', which indicates a retrieval operation. While it is conciseless, it distinguishes itself from siblings like 'list_layers' (which lists layers) and 'inspect_layer' (likely more detailed inspection). However, it lacks explicit differentiation from 'get_feature' or 'get_source'.

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 guidance on when to use this tool versus alternatives. It does not mention that this is for generic configuration as opposed to specific features or sources, nor does it suggest using 'list_layers' first to find the layer_id. The description gives no context about typical use cases or preconditions.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Return' implies a read-only operation, but the description does not disclose potential side effects (e.g., fetching live health data), error behavior, or whether the operation is safe. More transparency is needed beyond the verb.

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

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

A single sentence that front-loads the verb and resource, with no extraneous words. It is concise without sacrificing the core message.

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?

The description is adequate only for a very simple getter. It does not explain how to obtain a valid source_id, when to choose this tool over list_sources, or what 'health' includes. Given the tool has only one parameter and an output schema, more cross-referencing to siblings and parameter sourcing would make it complete.

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

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

Schema description coverage is 0%, and the only parameter, source_id, is documented as a bare string. The description adds only the term 'external source', which hints at the parameter's meaning but does not explain its format, where to obtain a valid identifier, or its relationship to list_sources. Minimal value beyond the schema.

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

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

The description states a specific verb ('Return'), a specific resource ('one external source's configuration and health'), and explicitly says 'one', which differentiates it from list-level siblings like list_sources. There is no ambiguity about what the tool does.

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 phrase 'one external source' implies the tool is for single-source lookups rather than listing all sources, but there is no explicit guidance on when to use it instead of alternatives such as list_sources or health. Usage context is implied, not stated.

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

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

With no annotations, the description carries the full burden. It discloses that the tool checks liveness, Geo Hub reachability, readiness, and mode, which is valuable behavioral context. However, it does not detail the output format or how the results are structured, relying on the output schema to convey that. Since the output schema exists, this is adequate, but the description could add more about what 'mode' means.

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

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

The description is a single, concise sentence that front-loads the purpose ('Report MCP liveness...'). Every word is informative, and there is no waste. It is appropriately structured for a zero-parameter tool.

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

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

For a simple health-check tool with no parameters and an output schema, the description is mostly complete. It covers the key aspects: liveness, reachability, readiness, and mode. The only minor gap is that it does not explicitly state that the tool performs no side effects or mutations, but given the nature of 'health' and the lack of parameters, an agent can reasonably infer it is non-destructive.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). The description adds meaning beyond the schema by explaining what aspects are checked (liveness, reachability, readiness, mode), which is helpful even though there are no parameters to document. Baseline 4 is justified because no parameter information is needed.

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

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

The description clearly states the tool reports liveness, reachability, readiness, and mode, which is specific and distinguishes it from sibling tools that operate on layers, sources, features, and imports. It conveys the resource being probed and the nature of the check, though it could be more explicit about the name 'health' being a status 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?

The description implies this is for checking the service status and connectivity, which is distinct from the sibling tools that perform data operations. However, it does not explicitly state when to use this over alternatives or when not to use it, but the context is clear enough for an agent to infer this is for health checks.

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

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

With no annotations, the description carries the behavioral burden and does it well: it commits to deterministic execution, local-only operation, and no network or staging. It also lists the full return shape and notes that ambiguous signals get explanatory notes, which is richer than a generic 'infers mapping' statement. It does not explicitly state that no side effects occur, but the deterministic/local/no-staging language strongly implies a pure inference operation.

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

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

Two compact sentences front-load the most decision-relevant facts: deterministic, local, no network, no staging. The second sentence itemizes the output fields without repeating the schema, and there is no filler or boilerplate.

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?

The tool has no annotations and no parameter documentation, so the description must compensate; while it discloses behavior and output fields, it omits input semantics and when-to-use guidance. The presence of an output schema reduces the need to explain returns, but the missing parameter context leaves an agent uncertain about how to populate the optional arguments.

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 schema provides no descriptions (0% coverage), yet the description does not explain headers, sample_rows, or desired_properties. The phrase 'CSV mapping inference' and the mention of external_id/property mappings indirectly hint at what headers and desired_properties are for, but the optional sample_rows and the relationship between inputs and outputs are left to inference.

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

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

The description clearly identifies the function as CSV mapping inference, and the return list (coordinates, external_id guess, typed property mappings, confidence map, notes) makes the output contract concrete. It does not use a direct verb or name a sibling alternative, so it misses the top tier. The deterministic/local framing also separates it from any remote mapping operation, but not from a specific sibling tool.

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 says 'No network, no staging,' which hints at when the tool is appropriate (local deterministic work), but it never states when to choose this tool over alternatives. No sibling is named and no exclusion or prerequisite is given, leaving the agent to infer use cases from the tool name alone.

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

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

No annotations are provided, so the description shoulders the burden of signaling safety and scope. 'Bounded operational summary' implies a read-only, limited result, which is useful, but it does not state side effects, permissions, or what 'bounded' excludes; this is adequate but minimal.

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 front-loaded sentence with no filler; 'bounded operational summary' is immediately informative and 'by UUID or slug' is the only necessary parameter detail. 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?

For a one-parameter tool with an output schema, this is close to sufficient: the operation and identifier format are clear and return values are covered by the output schema. However, the absence of alternatives/usage context and no annotation safety net leave minor selection uncertainty in the sibling set.

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 0% schema description coverage, the schema only says layer is a string. The description adds that the identifier can be either a UUID or a slug, a genuinely useful semantic that the schema omits. It does not describe slug format or accepted values, so not a 5.

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 resource ('a layer') and a specific product ('bounded operational summary'), which is more informative than a generic fetch. The word 'bounded' hints at a distinction from get_layer/list_layers, but it never names those siblings, so it stops 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?

There is no explicit guidance about when to choose inspect_layer over get_layer, list_layers, or list_features. 'By UUID or slug' explains identifier format, not selection criteria or exclusions.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that omitting status preserves the non-archived default, adding value beyond the schema. However, it does not mention pagination behavior, read-only guarantees, or what 'compact' summaries contain.

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

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

The description is two sentences with no wasted words. It front-loads the primary action and then adds the most important behavioral nuance about status, so 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?

The output schema covers return values, which reduces the burden. Still, with no annotations and minimal schema descriptions, the description does not fully explain pagination via cursor/limit or how this tool relates to neighboring feature tools. It is adequate for basic invocation but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It does explain the status default, which is helpful, but it leaves layer_id, limit, and cursor semantically unexplained beyond their names and schema types.

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

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

The description uses a specific verb and resource: 'List compact feature summaries for a layer.' This clearly identifies what the tool does and hints at a distinction from more detailed feature retrieval, though it does not explicitly name siblings like get_feature.

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 about when to use this tool versus alternatives such as get_feature or inspect_layer. The only usage-related note is about omitting status to preserve the Geo Hub default, which concerns parameter behavior rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states that it lists rows and can filter by state; it does not mention whether this is a read-only operation, how pagination works (cursor), any rate limits, or what the response structure looks like beyond the output schema. This is a significant gap for a data-listing tool, and with zero annotations it fails to provide necessary behavioral context. A 1 is warranted.

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

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

The description is a single, focused sentence that states the core purpose and the main optional filter. It is efficient with no fluff and is appropriately front-loaded. However, it could be more structured by briefly mentioning key parameters, but as a concise statement it earns a 4.

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

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

Given the tool has 4 parameters, an output schema, and is part of a larger import inspection workflow, the description is severely incomplete. It does not explain the return format (even though an output schema exists, the description should guide on interpretation), does not mention pagination via cursor, does not clarify the meaning of import_id, and lacks any guidance on typical usage flow (e.g., first get an import, then list its rows). This is far from complete for an agent to call correctly without additional context. A 1 is justified.

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 by explaining each parameter. The description adds value for the 'state' parameter by naming valid values (valid/invalid/candidate), but it does not explain 'import_id', 'limit', or 'cursor'. These parameters remain undocumented in both the schema (which has no descriptions) and the description. Since it covers only one of four parameters and the rest are unaddressed, a 2 is appropriate.

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

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

The description clearly identifies the verb 'List' and the resource 'import rows', and mentions an optional state filter with specific values (valid/invalid/candidate). This is specific enough to distinguish from sibling tools like list_imports or list_features, though it does not explicitly name an alternative. A 4 is appropriate because it is clear but lacks explicit sibling 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?

The description provides minimal usage context by mentioning the optional state filter, but it gives no guidance on when to use this tool versus alternatives (e.g., when you need rows of a specific import vs. all imports). It does not mention prerequisites like needing an import_id, or that this is for inspecting a specific import's contents. This leaves the agent without clear selection criteria, so a 2 is fair.

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

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

With no annotations, the description must carry behavioral disclosure, but it only states a listing action and the 'staged' status. It does not mention pagination, ordering, whether only pending/in-flight imports are returned, or any read-only guarantee.

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 tight sentence front-loads the verb and resource and packs the key filter into a dependent clause. There is 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 simple optional-parameter list operation with an output schema, this is minimally viable. However, without any parameter descriptions or usage notes, an agent gets only the core list/filter behavior from the text.

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 for undocumented parameters. It adds meaning only for layer_id ('filtered by layer'); limit and cursor are left to be inferred from their names and defaults.

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 action and object ('List staged imports') and adds the key optional filter by layer. It is clear enough to stand apart from siblings like list_sources and list_import_rows, but it does not explicitly name or contrast those alternatives.

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 about when to choose this tool over get_import, list_import_rows, or summarize_import. The only implication is that import lists can be filtered by layer, so an agent must infer the rest 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?

With no annotations, the description carries the disclosure burden. 'Compact summaries' is a meaningful behavioral hint that the result is not full layer payloads, and 'List' implies a read-only operation. It does not mention pagination despite the limit/cursor schema, though the output schema covers return shape.

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 sentence, front-loaded with the action and resource, and every word carries meaning. There is no filler or restatement of the schema.

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

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

For a simple list tool with an output schema and optional pagination parameters, the description is largely sufficient to invoke it correctly. It could add an alternative pointer or pagination note, but the schema already supplies defaults and the output schema covers return values.

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 schema has 0% description coverage and the tool description adds no meaning for limit or cursor. When schema coverage is low, the description must compensate, but it is entirely silent on how pagination and page size behave beyond the schema's bare defaults.

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

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

The description names a specific verb ('List'), a clear resource ('Geo Hub layers'), and an output shape ('compact summaries'). This distinguishes it from the 'get_*' and 'inspect_*' siblings, which imply detailed single-layer access.

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 verb and resource imply the use case: enumerate layer summaries rather than retrieving one layer. However, it never explicitly states when to prefer this over siblings like get_layer or inspect_layer, nor does it mention any exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List' and does not confirm read-only behavior, pagination semantics, ordering, or data freshness. The limit/cursor parameters hint at pagination, but the description itself adds no transparency.

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

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

The description is a single, front-loaded sentence with no filler words. It conveys the essential purpose efficiently, though it could have added compact guidance about pagination or related tools without becoming verbose.

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

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

For a simple listing tool with two optional parameters and an output schema, the description provides the core action and resource. However, it lacks any context about pagination behavior or when to choose this tool over siblings, leaving the agent to infer those details from the schema and tool names.

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 makes no mention of limit or cursor, so it adds no parameter-level meaning. The parameter names and defaults in the schema are somewhat self-explanatory, which prevents a score of 1, but the description does not compensate for the missing 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?

The description clearly states the action ('List') and the resource ('configured external sources'), which distinguishes it from siblings like list_layers and get_source. It does not explicitly contrast itself with those siblings, so it falls just 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?

The description gives no guidance on when to use this tool versus alternatives such as get_source or list_layers, and it does not mention pagination or any selection criteria. The usage context is only weakly implied by the verb 'List'.

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

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

No annotations are provided, so the description carries the full behavior-disclosure burden. It adds one useful clue (source is 'backend aggregate state') but does not state whether the operation is read-only, what happens if the import does not exist, or any permission/error 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?

The description is a single short sentence with no filler, and the key concept ('import status... commit readiness') is front-loaded. It is concise, though it leans toward being too minimal rather than just efficient.

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

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

With a single required parameter and an output schema, the description is close to usable: the agent knows what topic to query and the schema fills in the structural details. However, missing usage direction and parameter semantics keep it from being genuinely complete.

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

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

Schema description coverage is 0% and the description never mentions import_id or how it selects the aggregate state. An agent only knows import_id is a string, with no indication of its meaning, format, or expected examples.

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 concrete resource/domain (import status, commit readiness) and identifies the data source ('backend aggregate state'), so the core purpose is recognizable. It lacks an explicit verb like 'summarize' or 'retrieve' and does not explicitly distinguish itself from get_import, so it misses the top tier for clarity.

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 no guidance on when to use summarize_import versus siblings like get_import or list_imports. There is no mention of situations where the aggregate/commit-readiness view is preferable or when it should be avoided.

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