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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the write location (Fuseki's backups directory), the async nature (runs in background, returns a task id), and the rationale for its read-tool classification (copies data out, stays available under read-only servers). That read-only justification is exactly the kind of trait annotations would normally supply.

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-loads purpose, then placement/async behavior, then the safety rationale, then the read-tool justification. Every sentence contributes a distinct operational fact; there is no filler despite the multi-paragraph length.

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 explaining what is returned (a task id) and how to consume it (poll with task_status). Combined with destination and safety context, an agent has everything needed to invoke this correctly.

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

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

Schema coverage is 100% and the single 'dataset' parameter already documents its defaulting behavior, so the description needs to add nothing and doesn't. Baseline 3 applies since the schema does all the parameter work.

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: 'Start a server-side backup of a dataset.' The scope word 'server-side' immediately distinguishes it from anything client-side or export-oriented, and the sibling set (delete_dataset, drop_graph, compact_dataset) all deal with different lifecycle actions.

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 ('Do this before anything destructive') and names the exact risks it protects against ('no undo for drop_graph or delete_dataset'), which are real siblings. It also hands off the follow-up step by naming task_status as the polling mechanism.

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 and largely discharges it: it discloses asynchronous background execution with a task_status polling pattern, the space-reclamation side effect, and the fact that delete_old 'cannot be undone' and 'frees the most space.' Irreversibility of a destructive option is exactly the disclosure 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?

Four short, front-loaded sentences: purpose first, then execution model, then the consequential parameter, then the applicability constraint. No filler and no repetition of schema content.

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 an async mutation tool with no output schema, the description supplies the critical missing piece — that results must be obtained via task_status rather than a direct return — plus the irreversibility caveat and the TDB2 applicability limit. Nothing an agent needs to invoke it safely is absent.

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 beyond the schema: delete_old's schema text only says 'Delete the pre-compaction copy. Default false,' while the description adds the consequence (frees the most space) and the risk (cannot be undone). The dataset parameter gets no added treatment, but it is self-explanatory and defaulted.

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?

Specific verb+resource ('Compact a TDB2 dataset') with an explicit effect qualifier ('reclaiming space held by superseded data'). The added scope constraint 'Only meaningful for TDB2 datasets' makes it unambiguous against siblings like backup_dataset or delete_dataset, none of which perform compaction.

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 operational context — it 'Runs in the background; poll with task_status' — which tells the agent how to consume the result, and 'Only meaningful for TDB2 datasets' excludes invalid targets. It does not, however, state when compaction is warranted versus alternatives such as backup_dataset or a fresh write.

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

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

With no annotations, the description carries the full burden and largely succeeds: it discloses that Fuseki writes a config file so the dataset survives restarts, that 'mem' data vanishes on stop, and which stock endpoints get created. It omits auth/permission requirements and duplicate-name behavior, so it's strong but not exhaustive.

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 purpose is front-loaded in the first sentence, followed by the durability distinction the caller most needs. It's slightly wordy in the middle section, but each sentence conveys non-redundant behavioral information, so nothing is wasted.

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

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

For a no-annotation, no-output-schema mutation tool, the description covers persistence, restart behavior, and resulting endpoints — the factors an agent needs to call it correctly. Missing are permission requirements and conflict/error handling, but the core is complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description genuinely enriches the 'kind' parameter by explaining the durability consequence of each value and flagging the common mistake of choosing 'mem' unintentionally, adding meaning beyond the schema's brief gloss.

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

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

The description opens with a specific verb and resource ('Create a dataset on the server'), making the tool's function unmistakable. It doesn't explicitly differentiate itself from siblings like delete_dataset or list_datasets, but the creation semantics are clear enough that an agent won't confuse it.

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 clear context for the key decision — choosing between 'tdb2' (persistent) and 'mem' (in-memory), including the 'trap' warning about losing data. It stops short of naming alternatives or exclusions (e.g., when to prefer load_rdf_file or back up instead), so it lands at clear-context rather than full when/when-not.

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. Calling it 'a quick orientation' implies a lightweight, non-mutating read, but it never states that it is read-only, requires no special permissions, or leaves the store unchanged — important for a tool sitting beside destructive siblings like delete_dataset and drop_graph.

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 the substance front-loaded: what it measures first, when to reach for it second. No filler or restatement of the tool name.

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

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

For a simple two-parameter read tool with no annotations and no output schema, the description covers the returned dimensions (counts, graph distribution, dominant types/predicates) well. It stops short of stating safety/read-only behavior, which is the only notable omission.

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

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

Schema description coverage is 100%, so the schema already explains both 'top' and 'dataset'. The phrase 'which types and predicates dominate' loosely maps to 'top', but the description adds no format, default, or behavior detail beyond the schema — 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 names a concrete operation and its outputs — 'Size and shape of a dataset: triple counts, graphs, classes and properties' — which is specific enough to separate it from list_datasets, list_graphs, and sparql_query. An agent can tell what this returns without reading the schema.

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

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

It gives a clear use context: 'A quick orientation for a store you have not seen before.' That is a real when-to-use signal, but no alternative is named (e.g. list_graphs for graph names only) and there are no explicit 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 full behavioral burden and does well: it discloses that the operation is irreversible and that on-disk files are removed, not just the server registration, which is precisely the failure mode a caller would otherwise underestimate. It omits operational details like required privilege level (admin/maintenance), behavior when the dataset does not exist, and whether dependent graphs go with it.

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 its consequence in the first sentence, then a short disambiguation and a short warning. Every sentence earns its place and there is 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 two-parameter destructive tool with no output schema, the description covers the essentials an agent needs: what is destroyed, that it cannot be undone, and to back up first. Missing only peripheral operational context such as permissions required and error behavior on a nonexistent dataset.

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

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

Schema description coverage is 100%, so the schema already explains both 'name' and the 'confirm' guard against autocomplete deletion. The description adds no parameter-level detail beyond that, so the baseline of 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 names a specific verb (remove/delete) and resource (dataset) and immediately scopes the operation: the files on disk are destroyed too. The explicit contrast with 'unmount' disambiguates it from a plausible alternative a reader might assume, which is exactly the kind of sibling differentiation that earns a top score.

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 a clear precondition ('Take a backup first'), which implicitly routes the agent to backup_dataset, and it sets the expectation that this is only for data you are willing to lose. It does not, however, explicitly contrast with other destructive-adjacent siblings such as drop_graph or compact_dataset, so the when-not guidance is partial.

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 exist, so the description carries the full burden. It does disclose meaningful behavior: output covers both directions, incoming is toggleable, and each triple names its source graph. It omits read-only confirmation (only implied), how limit interacts across directions, and pagination/truncation 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 core behavior is front-loaded in the first sentence, followed by the two-direction explanation. The clause about the object direction being "where the interesting part is" is chattier than necessary but aids understanding rather than wasting 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?

There is no output schema, so the description should describe return shape, which it partially does (triples both ways, graph provenance). It omits read-only safety framing and what happens when limit truncates results, leaving some gaps for a 4-param query 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 100%, so all four parameters are already documented. The description reinforces the incoming toggle ("unless you turn it off") but adds no syntax, default, or interaction detail beyond the schema, 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?

States a specific verb (describe) and resource (one IRI), and clarifies scope: triples where the IRI is subject and object. It implicitly contrasts with hand-written queries but does not name the sibling (sparql_query) it replaces, leaving a small differentiation gap.

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?

"Faster to reach for than writing the query by hand" implies the tool is a shortcut alternative to sparql_query, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement and no named alternative, so usage is only inferable.

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

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

With no annotations, the description carries the full burden and does so well: it declares irreversibility ('no undo'), states the destruction scope, and explains the 404 outcome as an idempotency signal (already-empty/nonexistent graph does not error). It leaves permissions/auth requirements and any partial-failure behavior unstated, which is the only notable 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?

Three short sentences, front-loaded with the destructive consequence and scoping, then the backup precaution, then error semantics. Every sentence earns its place with 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 2-param destructive tool with no annotations and no output schema, the description covers the critical unknowns an agent needs: irreversibility, destruction scope, a prerequisite, and the meaning of a 404. Only auth/permission expectations and any response payload details are absent, which keeps it just short of 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 100%, and both parameters ('graph' as graph IRI, 'dataset' with its default) are already documented in the schema. The description adds no syntax, format, or naming detail beyond that, so the baseline of 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 uses a specific verb (delete/drop) and resource (a named graph) and immediately states scope: 'everything in it.' It is clearly distinguishable from siblings like delete_dataset (dataset-level) and write_graph (non-destructive write), so an agent can select it without opening the schema.

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

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

It gives a concrete precondition — 'Run backup_dataset first if the contents matter' — naming the sibling to use beforehand, which is genuinely actionable routing guidance. It stops short of explicitly contrasting with delete_dataset for the dataset-level case, so it is clear context rather than exhaustive when/when-not 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?

No annotations exist, so the description carries the full disclosure burden, and it delivers real behavioral context: Fuseki returns 405 rather than 404 for unknown datasets, and endpoint availability varies between assembler-configured and stock configurations. It omits auth or rate-limit expectations, but for a read-only listing operation that is a minor 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?

Three short paragraphs, each front-loaded with its claim and each adding non-redundant information: what is listed, why the 405 signal matters, and why endpoint names are worth reading. No sentence is 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 and no annotations, the description compensates by describing the return content in prose (datasets plus their endpoints) and the diagnostic value of that content. Completeness is good for a zero-parameter listing tool, though a one-line note on how datasets/endpoints appear in the response would close the last 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, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond noting that listing is server-wide rather than scoped.

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 ('List the datasets on this Fuseki server') and adds a distinguishing scope the siblings lack: the endpoints each dataset offers. This differentiates it from dataset_stats, create_dataset, and delete_dataset by outcome rather than name 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?

Gives a concrete trigger condition ('Reach for this first when a call fails with 405') with the reasoning behind it, which is unusually actionable. It does not name an alternative tool or state exclusions, so it stops short of the explicit when/when-not/alternatives bar.

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

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

With no annotations, the description carries the full burden and does well: it discloses that only graphs with at least one triple appear, that empty graphs are indistinguishable from never-created ones on TDB2, and that the default graph is reported separately. It omits auth/rate-limit behavior but covers the subtle semantic quirks a caller 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?

The core purpose is front-loaded in the first sentence, and the following sentences each add genuine semantic value rather than filler. Slightly verbose, but the length is earned by the non-obvious empty/default graph behavior.

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 must convey return content; it does so by stating graphs come with triple counts and that the default graph is reported separately. Complete enough for correct invocation, with only minor gaps around formatting or ordering.

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% and the single dataset parameter is already documented in the schema. The description adds no parameter details beyond what the schema provides, so the baseline of 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 ("List the named graphs in a dataset") plus a return detail ("with a triple count for each"). It is clearly distinct from read_graph/drop_graph/write_graph, though it does not explicitly name a sibling to route the agent away from.

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 through the discussion of empty graphs and default graphs, but there is no explicit when-to-use, when-not-to-use, or alternative tool named. The agent must infer the 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?

With no annotations, the description carries the behavioral burden and does real work: format auto-detection from extension, the rule that quad formats override any target graph, and the token-cost rationale for the file path. It omits mutation semantics of mode=replace (does it drop existing triples?) and any auth or async/task behavior, which are meaningful for a data-loading write.

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 paragraphs, front-loaded with the action and followed by format rules and rationale. The token-cost sentence is a concise justification for the tool's existence rather than filler; nothing is wasted.

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

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

For a tool with no annotations and no output schema, the description covers formats, mode, and graph interaction well. The remaining gap is the return/execution model (synchronous vs. a task tracked via task_status) and the exact effect of replace mode, which the agent cannot infer from structured fields.

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 genuinely adds meaning beyond the schema: it explains that media type is inferred from the file extension and that the graph parameter must be omitted for quad formats because the file defines graph names. That interaction is not derivable from the parameter descriptions alone.

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 (Load), resource (RDF file), source (from the sandbox) and destination (into a dataset). An agent can distinguish it from write_graph and sparql_update, which serve inline or in-conversation writes, without opening any 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?

Gives clear context for using this over passing RDF inline (contrasted with INSERT DATA) and an explicit exclusion: 'do not pass a target graph' with TriG/N-Quads. It stops short of naming the sibling tools (sparql_update, write_graph) that would be the alternatives, so this is strong context rather than full 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?

With no annotations, the description carries the full burden and does well: it discloses the single-HTTP-request cost, that it bypasses the query parser, and the important semantic that a 404 means an empty graph rather than an endpoint failure, plus a size warning. It does not address authentication, permissions, or behavior on a missing dataset, which a mutation-adjacent read on a shared store could reasonably mention.

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 front-loaded sentences, each carrying a distinct fact (what it fetches, why over CONSTRUCT, 404 meaning, size handling). Nothing is padding, even the clarifying line about 404 semantics 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 read tool with no output schema, the description covers the return medium (Turtle), the error semantics (404 = empty graph), and the large-result escape hatch (out_file). An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real guidance: it states out_file should be used 'for anything beyond a few hundred triples' and confirms Turtle as the returned format, going beyond the schema's per-field 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 (Fetch) and resource (one named graph whole, as Turtle), and explicitly distinguishes itself from a CONSTRUCT query that 'returns the same triples but has to be parsed as a query first.' An agent can separate this from sparql_query, list_graphs, and write_graph without opening any 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 an explicit when-to-use condition ('the right way to read a graph you intend to inspect or copy') and names the alternative approach (CONSTRUCT) with the tradeoff that selects it. Also gives a concrete threshold for the out_file parameter.

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 exist, so the description carries the full burden. It implies a non-mutating read via its metrics-flavored content and adds a genuinely useful behavioral frame: detecting a wrong endpoint that still answers. It does not state read-only status outright, nor permissions, rate limits, or caching 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 sentences, zero filler, and the payoff (what it returns) is front-loaded ahead of the rationale for calling it. 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?

No output schema or annotations, but the description enumerates the returned fields (version, uptime, per-dataset stats) well enough for an agent to know what to expect. The only real omission is any contrast with the similarly named dataset_stats sibling.

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

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

Schema description coverage is 100% and the single optional 'dataset' parameter is fully documented in the schema as limiting statistics to one dataset. The description adds no syntax or format details beyond that, so the baseline 3 for schema-covered params 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?

Names a specific verb-less but concrete resource set: version, uptime, and per-dataset request statistics. An agent knows exactly what comes back. However, it never distinguishes itself from the sibling dataset_stats, which sounds like it could return overlapping statistics, so sibling differentiation is missing.

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?

Explicitly states when to call it ('at the start of a session') and why (confirming the endpoint identity). No exclusions or named alternatives are given, so it stops short of the 5-level when-not/alternatives 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?

With no annotations, the description carries the full burden and does so richly: read-only semantics, the fact that a LIMIT is auto-appended to SELECTs, that limit:0 lifts the cap, and that out_file routes large results to disk instead of the conversation. It also discloses the empty-default-graph behavior on many datasets — exactly the operational 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?

Front-loaded with the core purpose, then organized into scannable sections (forms, property-path table, named graphs, result caps). It is on the longer side, but the property-path examples and cap warnings each earn their place for a complex query 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 query tool with no output schema, the description still explains the return shape of each form (rows, triples, boolean) and the cap/file behaviors. Combined with 100% schema coverage, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds real meaning: it explains why limit exists (unbounded queries can return hundreds of thousands of characters), that limit:0 lifts the cap deliberately, and that out_file sends results to disk. dataset is only lightly touched.

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

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

The description opens with a specific verb+resource: 'Run a read-only SPARQL query (SELECT, CONSTRUCT, ASK or DESCRIBE).' It enumerates the query forms and their return shapes, clearly distinguishing this read-only tool from the sibling sparql_update. The purpose 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 gives explicit when-to-use guidance ('Property paths are the reason to reach for SPARQL over a REST API') and warns about default-graph pitfalls that inform usage. It does not explicitly contrast with read-oriented siblings like describe_resource or read_graph, so it falls short of full alternative coverage.

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 a genuinely useful behavioral quirk (CREATE GRAPH returns 200 but the empty graph is invisible to list_graphs and yields 404 via GSP). But it never warns that DROP, CLEAR, and DELETE are irreversible, nor mentions permissions or transaction semantics — significant omissions for a mutation tool with zero annotation coverage.

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 capability, then a worked example, then the TDB2 caveat, then alternatives — a sensible priority order. The TDB2 paragraph is slightly verbose (repeats the 'graph does not exist' idea three ways) but each sentence carries actionable 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 2-parameter tool with no output schema and no annotations, the description covers operation semantics, a syntax example, a platform-specific pitfall, and alternative tools. It is missing only response/error shape and permission or transaction expectations, which the absence of an output schema makes somewhat forgivable.

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, and the description earns an extra point by embedding a concrete 'INSERT DATA { GRAPH <iri> { <s> <p> "o" } }' example that demonstrates the expected syntax of the `update` string. It adds no detail on the `dataset` parameter beyond the schema's default behavior note.

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 ('Run a SPARQL Update') and enumerates the exact operation families (INSERT, DELETE, LOAD, CLEAR, CREATE, DROP, COPY, MOVE, ADD), which distinguishes it cleanly from the read-oriented sparql_query sibling. An agent can tell what class of operation this tool executes without opening the schema.

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

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

Gives an explicit routing rule with named alternatives: 'For replacing a whole graph from a file, write_graph and load_rdf_file are better.' It also warns when a naive approach fails (CREATE GRAPH alone on TDB2). It does not, however, state the complementary case — that read-only queries belong to sparql_query — leaving that inference to the agent.

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 behavioral burden. It usefully discloses the completion signal (a "finished" timestamp is present only when done), which is genuine behavioral value, but it omits error/failed/cancelled states, whether results are retained or expire, and what the call returns besides that timestamp.

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, zero filler, with the resource identity front-loaded and the completion-semantics detail immediately after. 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 no output schema and no annotations, the description must carry the whole contract, and it only covers the finished/not-finished distinction. For a polling tool an agent needs to know the other possible states and the full return shape, which are absent, though the core completion check is adequately 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?

Only one parameter and schema coverage is 100%, so the schema already explains that task_id comes from backup_dataset or compact_dataset. The description adds no syntax, format, or validity details beyond the schema, 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?

States a specific resource (background task state) and explicitly scopes it to tasks created by backup_dataset or compact_dataset, which routes the agent away from the other dataset/graph siblings. An agent can immediately tell this is a task-introspection tool, not a dataset query.

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

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

Usage is only implied: the mention of backup_dataset and compact_dataset suggests this is called after those operations to check progress, but it never says when to poll, how often, or that it is the only way to observe those long-running operations. No alternatives exist among siblings, so there is nothing to exclude.

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 and does well: it flags that replace is destructive ('whatever was in it is gone'), declares replace as the default, and explains that file payloads bypass the conversation and go straight to the server. It omits permissions/auth requirements and any indication of what a call returns or how failures manifest.

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 action, then structured into short paragraphs that each cover one decision (mode, per-graph versioning rationale, payload source). No filler 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 six-parameter mutation tool with no annotations and no output schema, the description covers the destructive/default behavior and payload choice well. It does not describe the response, error conditions, or required permissions, which leaves minor gaps for a write operation.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: mode's replace/merge semantics and default, the mutual exclusivity of content and file, and the practical preference for file on larger payloads. Only content_type and dataset get no elaboration beyond the schema.

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

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

States a specific verb (write/replace/extend) and resource (a named graph) with RDF payload, and distinguishes itself from siblings like sparql_update (which it frames as per-graph replacement) and read_graph/drop_graph. An agent can tell what this does without opening the schema.

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

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

Gives explicit mode semantics (replace is the destructive default, merge is additive) and a clear rule for choosing file vs inline. It stops short of naming sibling alternatives such as sparql_update or drop_graph, so a routing decision between write_graph and a generic SPARQL update 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.