Graphicle MCP Server

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the scope fact that the whole community is returned, and says nothing about truncation or how token_budget interacts with this bulk retrieval.

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, eleven words, with the verb and the identifying parameter front-loaded and no filler. It is efficiently sized, though its brevity is part of why other gaps remain.

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?

A 4-parameter tool with no output schema, so the description ideally would sketch what a returned node looks like or whether results are truncated. It conveys the retrieval scope but leaves the agent without the notion of a community or the shape of the response.

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 every parameter including repo, as_of and token_budget is already documented in the schema. The description only echoes community_id, adding no format or indexing detail beyond the schema's '0-indexed by size' note. Baseline 3 applies.

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

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

States a specific verb and resource: 'Get all nodes in a community by community ID.' An agent can tell it retrieves a full community's membership rather than a single node (get_node) or an adjacency list (get_neighbors). It does not, however, explicitly differentiate itself from those siblings or clarify what a 'community' represents.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. With siblings like get_node, get_neighbors, query_graph and god_nodes, the agent must guess whether a community lookup is the right entry point. Usage is only implied by 'by community ID'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no mention of how token_budget truncates output, no relation_filter behavior, no error behavior for an unknown node. It contributes essentially no behavioral context of its own.

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; 'direct' and 'with edge details' both carry weight. It is arguably too terse for a 6-parameter tool, but nothing in it 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?

Six parameters, zero required, and no output schema, meaning the description carries the full burden of telling the agent what comes back. It does not describe the response shape (neighbor list, edge metadata), nor the effect of token_budget or relation_filter values, leaving meaningful gaps for a graph-traversal 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 83%, so the schema already documents repo, as_of, node_id, token_budget, and relation_filter. The description adds no syntax, format, or allowed-value detail (e.g., valid relation types) beyond what the schema provides, 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 (Get), resource (neighbors), scope qualifier (direct), and return content (with edge details). It is distinguishable from siblings like shortest_path or query_graph by the word 'direct', though it never names an alternative explicitly.

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

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

There is no when-to-use guidance, no exclusions, and no routing to siblings such as shortest_path (for traversal) or query_graph (for filtered/deeper queries). The agent must infer that this is the one-hop lookup.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no note on what "full details" includes, whether the node can be missing, or how it relates to as_of episodes.

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; the lookup key is stated immediately. It is efficient, though its brevity is partly under-specification rather than disciplined conciseness.

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 four-parameter read tool with no output schema, the description should at least sketch what "full details" returns (properties, edges, location) or note that episodes/repo scoping matter. The schema covers parameters, so this is adequate but has a real gap.

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

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

Schema description coverage is 100%, so repo, as_of, label and node_id are all documented in the schema, including the label/node_id aliasing. The description's "by label or ID" merely restates part of that, adding no format or behavior beyond the schema — baseline 3.

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?

"Get full details for a specific node by label or ID" names a concrete verb (get), resource (node), and lookup key (label/ID). It is distinguishable from listing/query siblings, but it never names an alternative such as query_graph or get_neighbors, so it stops short of full 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?

There is no when-to-use statement, no prerequisite (e.g. needing an episode or repo context), and no guidance on when to prefer this over query_graph or get_neighbors. Usage is only implied by the lookup-key phrasing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the useful framing that these are the highest-degree 'core abstractions', but it does not disclose ordering, default count, or how hub exclusion affects results.

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 that defines the resource and its meaning with no waste. It is efficient, though short enough that it leaves openings unfilled.

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

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

There is no output schema, so the description carries return-value burden, and it never states the shape of results, ordering, or the effect of top_n. It is adequate for a simple read tool with good annotation coverage, but leaves the agent to guess at output semantics.

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

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

With 75% schema description coverage, the schema already documents repo, as_of, and exclude_hubs_percentile, so the baseline is 3. The description adds no parameter detail at all, and top_n remains undocumented beyond its default of 10.

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 ('Return the most connected nodes') and clarifies the opaque term 'god nodes' as 'the core abstractions of the knowledge graph', so the agent knows what it retrieves. It does not distinguish itself from graph-analyzing siblings such as graph_stats, query_graph, or get_community, so it falls short of a 5.

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

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

The description gives no when-to-use or when-not-to-use guidance. There is no indication of how this differs from graph_stats, query_graph, or get_community, forcing the agent to infer applicability from the 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine behavioral context: reconstruction from recorded history without re-extraction, plus what is included (parent episode, labels, cardinality-one contradictions recorded at that episode). It omits pagination/limit behavior and any error semantics.

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, front-loaded with the primary query mode and no filler. The prose is extremely dense and requires re-reading, but every clause carries information rather than padding.

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

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

For a 10-parameter tool with no output schema and no per-property schema text, the description covers the core selectors and the returned content reasonably well. However, canonical, limit, and repo semantics are absent, and with no output schema the agent must still guess at result shape and pagination.

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 carry all parameter meaning, and it does explain most: as_of (episode id, commit sha label, latest/working), valid_at/known_at/branch, node (exact id), query (id substring), and relations. It leaves repo, limit, and canonical completely unexplained, which is the main gap.

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

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

States a specific verb ('Query') and two concrete resources: the temporal record (valid_at/known_at/branch) and the repository's typed code graph at an episode selector. It is dense but the agent can tell it is an as-of/time-travel read distinct from a live graph query, though it never names a sibling (e.g. query_graph) for contrast.

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 presents the two query modes and the narrowing parameters, implying when each mode applies, but gives no explicit when-to-use versus when-not-to-use, no routing to query_graph or graph_episodes, and no prerequisites. Usage must be inferred from the mode descriptions.

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

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

Annotations already cover the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needed to add context. It adds nothing about ordering, pagination, or what an 'episode' actually is, leaving the semantics of the returned data unexplained.

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 or redundancy. It is efficient, though it is terse to the point of under-specification.

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-optional-parameter read tool with rich annotations and no output schema, the description is minimally adequate but leaves the definition of 'episode', ordering, and result limits unexplained.

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 carry the parameter burden. 'For a repository' loosely maps to the single 'repo' parameter, but no format, identifier convention, or optionality guidance is given.

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?

It states a specific verb ('List') and resource ('recorded graph episodes and their labels') scoped to a repository, so the agent knows what it returns. However, it does nothing to distinguish itself from graph-related siblings like graph_history_stats, graph_as_of, or query_graph.

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 indication of when to use this tool versus the many other graph-read siblings, nor any prerequisites or exclusions. The read-only nature is only implied by '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?

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context, and it does: it discloses the exact content of the summary including retention defaults and the latest change-impact wall-clock time. It stops short of saying whether results are cached, how expensive the call is, or how repo selection defaults.

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 dense sentence, front-loaded with the summary category ('Storage and timing summary') before the content list. It is long but every clause maps to a real output element; the parenthetical table enumeration is the only mildly heavy part.

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 covering return content, the description carries the full burden of describing what comes back, and it does so field-by-field. A read-only, single-optional-param tool needs little more; only the repo-default behavior and the stat-selector absence remain unstated.

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

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

The single 'repo' parameter has 0% schema description coverage and the description only implies it via 'a repository's graph history'. It does not state the accepted identifier form, nor that the parameter is optional, nor what happens when it is omitted (presumably the current/default repo), so it only partially compensates for the schema gap.

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

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

The description names a specific resource (a repository's graph history) and enumerates exactly what is summarized: per-table row counts and byte sizes, episode count, coverage uploads, change-impact timing, and retention defaults. It is clearly not a query or mutation tool, but it never names the sibling graph_stats to distinguish history-oriented storage/timing stats from live graph stats.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as graph_stats, graph_episodes, or repository_status. The agent must infer that this is a diagnostic/introspection call from the content list 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?

Annotations already declare this is a non-read-only, idempotent, non-destructive, closed-world operation. The description adds real behavioral context beyond that: re-running reconciles/closes stale edges, the operation both resolves and persists edges, and only repositories the caller may read participate (an authorization scope note). It does not disclose cost, duration, or what happens on partial failure.

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 dense sentences, front-loaded with the primary edge-resolution behavior before the document-to-symbol phase and the permission caveat. No filler, though 'with both episodes' is opaque and slightly burdens reading.

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 parameterless, output-schema-less batch recomputation, the description covers what is computed, what is persisted, idempotent re-run semantics, and permission scoping for the caller. Remaining gaps (runtime cost, dry-run availability, failure behavior) are minor.

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 the baseline is 4. The description correctly frames it as a workspace-wide batch operation requiring no arguments, though the phrase 'with both episodes' is unexplained jargon.

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

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

States specific verbs and resources: resolving imports between independently indexed repositories by package identity, persisting cross-repository edges, and recomputing document-to-symbol links. An agent gets a precise picture of the operation. However, it never names a sibling or otherwise differentiates this write/compute tool from the many graph_* read tools around 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?

Usage is implied rather than stated: 're-running after new episodes closes stale edges' tells the agent this is meant to be re-invoked after indexing, but there is no explicit when-to-use, when-not-to-use, or named alternative among the graph_* siblings. Adequate but leaves the agent to infer the triggering 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds the metric inventory, which is useful since there is no output schema, but says nothing about scope (whole graph vs. filtered), cost, or default resolution behavior beyond what the schema states.

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 tight sentence with the resource and the returned metrics front-loaded. No filler, no restatement of the name, every clause 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, the description's metric list is the only signal about what comes back, which is genuinely needed. However it omits the scope of the statistics (project-wide vs. episode-scoped) and any guidance tying as_of to the reported stats, leaving a gap for a two-parameter graph 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 both repo and as_of are fully documented in the schema, including defaults and accepted value forms. The description adds no parameter-level meaning 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?

States a specific verb (Return) and resource (summary statistics) and enumerates the metrics: node count, edge count, communities, confidence breakdown. An agent can tell roughly what it produces, but the description never distinguishes it from the close sibling graph_history_stats, which an agent could easily confuse it with.

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 when-to-use guidance, no when-not-to-use, and no mention of alternatives such as graph_history_stats or graph_episodes. Usage has to be inferred entirely from the name and the metric 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?

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact the annotations do not convey: it performs no model call and no memory write. Beyond that it does not disclose what is returned, whether it has side effects on caches, or how long the 'prepared' state remains valid.

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 with no filler, and the purpose is stated before the constraint. It is efficient, though the extreme terseness borders on cryptic rather than informative.

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

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

With no output schema, the description is responsible for explaining what the 'prepared evidence' and 'delta contract' actually contain and how the agent consumes them, and it does not. For a tool the agent must act on rather than merely call, the essential return-shape and downstream-usage information is missing.

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

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

The single parameter memory_id has 0% schema description coverage, so the description carries the full burden of explaining it — yet it says nothing about the parameter at all (format, whether it can be a slug, name, or ID from another memory tool). It does not compensate for the documentation gap.

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

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

The verb 'prepare' and resource 'memory refresh' are present, and the description at least signals scope by negating side effects ('No model call or memory write'). However, the core output terms 'exact current evidence' and 'stable document delta contract' are proprietary jargon that never resolve into a concrete, verifiable artifact, so an agent cannot confidently tell what this produces or how it differs from the similarly named sibling prepare_observations.

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 when-to-use or when-not-to-use guidance, and no alternative is named despite a crowded sibling set that includes prepare_observations, project_memory_history, and search_project_memory. The only indirect signal is 'No model call or memory write', which merely implies a safe prep step.

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?

The annotations already carry readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. What the description adds beyond the structured fields is genuinely useful and non-obvious: that no LLM provider is invoked and the agent must supply its own inference. It still omits pagination/limit behavior and whether the result is cached, so it is not a 5.

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

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

Two short sentences, no filler, and the most decision-relevant fact ('Use your own model; no provider call') is placed where it will be read. The first sentence is dense with undefined jargon, which costs a little clarity but not 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?

There is no output schema to lean on, 0% schema description coverage on three parameters, and no indication of what 'prepared' material looks like or how the agent should consume it. For a preparatory read tool whose whole value is the shape of what it hands back, this leaves the agent under-equipped.

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?

There are three parameters (limit, source_id, start_byte) at 0% schema description coverage, and the description says nothing about any of them. The names are partly self-explaining (source_id, start_byte as a byte offset), but no defaults, units, or interaction (e.g., what limit bounds, whether start_byte pairs with source_id) are given, so the agent must guess.

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 verb 'prepare' and the three artifacts (source excerpts, claim targets, interpretation contract) are stated, so the tool is not a pure tautology of its name. However, the artifacts are undefined domain jargon and the description gives no differentiation from the many sibling tools (e.g., prepare_memory_refresh), so an agent cannot tell exactly what is produced. This is a vague but non-empty purpose.

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 only usage signal is 'Use your own model; no provider call,' which hints at the calling pattern but never states when this tool should be selected over siblings such as prepare_memory_refresh, recall_project, or read_project_source. No preconditions, no exclusions, no alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that it reads memory drafts and reviews state/freshness, but does not explain output, pagination, freshness semantics, or the odd 'stored procedures' caveat. It adds some context but not rich behavioral detail.

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 short and front-loads the read action, which is good. The second sentence is somewhat cryptic and may not earn its place, but the overall structure avoids verbosity.

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 read tool with one parameter and no output schema, the description still omits any explanation of include_retired, return content, or distinction from sibling memory tools. Annotations cover safety, but the definition is too incomplete for confident selection and invocation.

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 one parameter, include_retired, with 0% schema description coverage. The description never mentions or explains this parameter, retired items, or how drafts relate to retired state. The description provides no semantic value for the parameter.

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

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

The description states a verb ('Read') and a resource ('memory drafts'), and adds that it reviews state and freshness. However, 'memory drafts' is vague, and the description does not distinguish this tool from close siblings like search_project_memory, project_memory_history, or recall_project. The second sentence does not clarify the core purpose.

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 use this tool versus alternatives. The sentence 'Stored procedures are not execution permission' is a cryptic caveat, not a usage condition. An agent is left to infer when this tool should be selected.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context that revisions are immutable and can be queried at a point in time, but it does not describe output ordering, pagination, or authentication 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?

A single, front-loaded sentence with no wasted words. It conveys the core operation and the optional temporal parameter efficiently.

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 0% schema description coverage, the description is quite terse for a history inspection tool. It covers the core action and timestamp semantics but omits return format, ordering, pagination, and memory_id semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It explains known_at accepts an RFC3339 timestamp for point-in-time inspection, which adds meaning beyond the schema. However, memory_id is left entirely undocumented in both schema and description.

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

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

The description states a specific verb and resource: inspecting immutable memory revisions. It clearly distinguishes this from general memory reads or searches by focusing on revisions. However, it does not explicitly differentiate itself from sibling tools like project_memory or search_project_memory.

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 when to use the optional known_at parameter: to inspect state as known at a given RFC3339 timestamp. It does not state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds only the return-shape note ('relevant nodes and edges as text context'), with no mention of token budgeting behavior, traversal cost, or scoping defaults beyond what annotations provide.

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, front-loaded with the action and traversal modes. Nothing is wasted, though the second sentence is thin and could carry more useful behavioral context in the same 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?

With annotations covering safety and the schema fully documenting all 7 parameters, the description's main gap is usage guidance against numerous overlapping graph siblings. It is adequate to invoke correctly but does not resolve sibling-selection ambiguity.

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 every parameter (mode, repo, as_of, depth, question, token_budget, context_filter) is documented in the schema itself. The description's 'using BFS or DFS' merely restates the mode enum, adding no syntax or format guidance beyond structured fields, so the baseline 3 applies.

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

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

The description states a specific verb (Search) and resource (knowledge graph), and identifies two traversal modes. It clearly implies retrieval of relevant nodes/edges, but it does not distinguish itself from sibling graph tools like get_node, get_neighbors, or shortest_path, so it falls short of a 5.

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

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

There is no guidance on when to use this broad search tool versus the many targeted graph siblings (get_node, get_neighbors, get_community, shortest_path). The BFS/DFS mention is a mode choice, not a when-to-use rule, and no exclusions or alternatives are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by noting the source must be 'authorized' and that reading supports 'exact byte continuation,' but it omits error handling, pagination behavior, and what happens when multiple lookup parameters are provided.

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

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

A single front-loaded sentence with no filler. The lookup modes and the byte-continuation constraint are stated compactly and earn their 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 tool with seven parameters, zero required fields, no output schema, and very low schema documentation, the description is far too thin. It does not explain how to disambiguate among source_id, path, sha256, and snapshot, nor how line-based and byte-based parameters relate.

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

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

Schema description coverage is only 14% (snapshot is the sole documented parameter), so the description must compensate. It partially does by mapping 'ID or repository path' to source_id/path and by connecting 'byte continuation' to start_byte/line_count/start_line, but sha256 and the interactions among the seven optional parameters remain unexplained.

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 (Read), a specific resource (authorized original source), and two lookup modes (ID or repository path). It is clear what the tool does, though it does not explicitly differentiate itself from likely siblings like repository_files.

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 on when to use this tool versus alternatives such as repository_files, nor any stated preconditions or exclusions. The phrase 'with exact byte continuation' hints at a continuation use case but does not tell the agent when to prefer it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the reranker takes about 20 s per question and did not improve held-out recall, and covered hits return as references. It omits auth/prerequisite and return-shape details.

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

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

Purpose is front-loaded, which is good, but the middle sentence is dense and the trailing 'Continue incomplete sources before making decisions' is vague and low-value. It is not padded, but not every sentence earns its place equally.

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

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

For a 12-parameter retrieval tool with no output schema and 42% schema coverage, the description leaves significant gaps: several parameters (mode, needs) are undefined and the return/selection behavior is only glancingly described. Given the complexity, more disclosure is warranted.

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

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

Schema coverage is only 42% across 12 parameters, so the description must compensate but only partly does. It explains local_reranker_profile/local_embedding_profile behavior, but leaves unexplained parameters like mode (the defaulted 'auto') and needs, which an agent cannot interpret from the bare 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 names a concrete verb ('Find') and two resources ('original source evidence' and 'current reviewed memory'), so an agent knows this is a retrieval tool. It does not, however, distinguish itself from overlapping siblings such as search_project_memory or project_memory, leaving the boundary to be inferred.

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 one narrow piece of usage guidance (leave the reranker unset for a single-conversation project) and a vague directive ('Continue incomplete sources before making decisions'). It never states when to prefer this over search_project_memory, read_project_source, or project_memory, so the when-to-use logic is only implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds only the word 'authorized', hinting at permission-scoped results, but says nothing about pagination behavior despite having limit/offset parameters.

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 short sentence with no wasted words and the core action front-loaded. It is appropriately sized, though its brevity comes at the cost of the missing information noted elsewhere.

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

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

For a 3-parameter listing tool with no output schema and no parameter documentation anywhere, the description is too thin. It omits what 'authorized' means, the return shape, and pagination behavior, so an agent lacks the context to call 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 0% for all three parameters (limit, offset, prefix), and the description mentions none of them. There is no explanation of what 'prefix' filters, or how limit/offset paginate, so the agent cannot use the parameters correctly from this 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 ('List') and resource ('source paths and IDs'), so the agent knows this returns a collection of paths/identifiers. It does not differentiate from siblings like read_project_source or repository_status, leaving the boundary between listing and reading/fetching ambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as read_project_source or repository_status, nor any stated precondition. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that — nothing about what 'source coverage' measures, freshness of revisions, or how memory state is computed.

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 or redundancy. It is efficient, though its brevity shades into under-specification rather than disciplined conciseness.

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 parameters and no output schema, the description carries the burden of explaining what a caller gets back, and it only gestures at three areas without saying what each contains or what the shape of the response is. Adequate to identify the tool, insufficient to call it with confidence about the result.

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 there is no parameter semantics burden; the baseline of 4 applies. Nothing in the description contradicts or confuses the empty 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 verb 'Inspect' is paired with three named facets (source coverage, source revisions, memory state), so the general purpose is identifiable. However, terms like 'source coverage' and 'memory state' are ambiguous domain jargon, and the description does nothing to distinguish this from siblings such as project_memory, project_memory_history, workflow_status, or graph_stats.

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 statement of when to call this tool, what preconditions exist, or which sibling to prefer for adjacent questions (e.g. project_memory for memory contents, repository_files for file listings). Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: it returns source citations and ambiguity diagnostics, and makes no model call, which tells the agent results are deterministic rather than LLM-generated.

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, front-loaded sentences with no filler; the search scope comes first and the return/no-model-call caveats follow. The phrasing is dense and slightly jargon-heavy ('ambiguity diagnostics'), but every sentence carries information.

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

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

With no output schema, the description does well to summarize the return (citations plus ambiguity diagnostics). But for a 7-parameter tool with zero schema documentation, it leaves limit, include_history, and the semantics of the required 'question' parameter unexplained, which is a real gap for correct invocation.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate, and it only partly does: it maps 'name or alias' to identity matching, 'scope' to scopes, 'validity' to as_of/known_at, and lexical mode to match_mode. It says nothing about limit, include_history, or what the required 'question' string actually accepts.

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 gives a specific verb (Search) and resource (reviewed structured memory) plus the axes it searches on (declared name or alias, scope, validity). It is clearly a lookup tool, but it never distinguishes itself from the close sibling project_memory or recall_project, so the agent must guess which search entry point to use.

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 clause 'Explicit lexical mode discovers text matches' implies when to choose match_mode=lexical over the default identity lookup, which is useful implied guidance. However, there is no statement of when to use this tool instead of siblings like project_memory, project_memory_history, or recall_project, and no exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the default scope (latest session), the windowing behavior around an anchor, and the shape of the response ('titles, times and source ids') along with the split of responsibility versus read_project_source.

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

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

A single dense sentence that front-loads the verb and scope, with the sibling hand-off at the end. No filler, though the clause stacking makes it slightly harder to parse than a two-sentence split would.

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

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

With no output schema, the description usefully names what is returned and points to the tool that returns full turn bodies. The remaining gap is the unspecified default and cap for before/after, which matters for an agent tuning a window, but overall the definition is sufficient to call 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 0%, so the description carries the burden. It conceptually maps three of the four parameters (session_id, anchor_source_id, and before/after as 'turns before and after it'), but it never clarifies defaults, the maximum of 20, or how session_id and anchor_source_id interact when both are supplied.

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 ('Browse captured coding-agent turns of this project: the latest session by default, or the session of an anchor turn') and explicitly carves out a slice of behavior that differs from the sibling read_project_source. An agent can tell from the description alone what comes back (turns around a point plus recent sessions) and how that differs from fetching a whole turn.

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 default ('the latest session by default'), the condition that switches behavior ('or the session of an anchor turn'), and routes to the sibling for a different need ('read_project_source returns a whole turn'). It doesn't state explicit exclusions or when not to call it, but the selection logic against the main alternative is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds real behavioral context beyond that: traversal honors stored edge direction unless overridden, which affects results in a way no annotation conveys.

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 core operation front-loaded and the directional caveat immediately after. No filler, nothing redundant.

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

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

For a read-only graph traversal with full schema coverage and no output schema, the definition is nearly complete: operation, scope, and traversal semantics are all covered. It could still note behavior when no path exists or how max_hops affects failure, but nothing essential is missing.

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

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

Schema coverage is 100%, so all six parameters including repo, as_of, max_hops and undirected are already documented in the schema. The description only restates the undirected semantics already present in the schema, adding no syntax or default detail beyond it — baseline 3.

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

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

States a specific verb+resource+scope: 'Find the shortest path between two concepts in the knowledge graph.' This is clearly distinct from siblings like get_neighbors (adjacency) and query_graph (pattern matching), so an agent can route without opening schemas.

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

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

The description gives a conditional usage rule for the traversal mode ('Follows stored edge direction by default; set undirected=true to ignore it'), which is useful, but it never says when to prefer this tool over get_neighbors or query_graph, nor any prerequisite for using it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is fully covered. The description adds the nature of the returned content (queued work plus model usage), which is useful context, but it does not disclose what happens to scope when job_id is omitted or what the response looks like.

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 or redundancy. It is arguably under-specified rather than verbose, but the sentence itself 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-optional-parameter read tool with no output schema, the description covers the basic purpose but leaves the return shape, the job_id semantics, and the filtering behavior unexplained. It is minimally adequate, not 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?

The single parameter job_id is documented neither in the schema (0% coverage) nor in the description, which never mentions it. The agent cannot tell whether it is a required filter, what an omitted value returns, or what format the ID takes.

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 ('Inspect') and two concrete resources ('the caller's queued work' and 'recorded model usage'), which is enough for an agent to know this is a read-only status/job-lookup tool. It is easy to distinguish from siblings (graph_*, memory_*, repository_*), though the description does not explicitly contrast itself with any of them.

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

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

No when-to-use guidance is given. It does not say when a caller should reach for workflow_status versus session_timeline or graph_history_stats, nor when to pass job_id versus calling with no arguments. The agent must infer all of this.

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