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

Given no annotations, description discloses key behaviors: abstains rather than guessing, uses citations, runs an LLM synthesis, returns specific fields, and explains empty/abstain meaning. Lacks explicit read-only indication but is largely transparent.

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?

Description is well-structured: purpose first, then usage guidance, performance note, and return format. Slightly lengthy but each sentence adds value. Could tighten parameter mentions.

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?

Covers purpose, usage, return format, and behavioral traits adequately. However, lacks parameter explanations for the five undocumented parameters, which is a gap given no output schema and low schema coverage.

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 17% (only multihop has description). The tool description does not explain the other five parameters (limit, seeds, max_items, token_budget, query beyond its obvious role). Insufficient compensation for low schema coverage.

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?

Description clearly states it answers factual questions from a knowledge graph with citations and abstains when unknown. It explicitly differentiates from sibling tools june_context and june_search, making purpose distinct.

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 explicit guidance on when to use this tool (for finished answers) and when to use alternatives (june_context for raw material, june_search for ranked items). Also mentions it may take longer.

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?

Despite no annotations, the description discloses key behaviors: ranking, entity folding, token budgeting, and output structure. Does not mention side effects or error handling, but for a read-style tool this is acceptable.

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 pack the core purpose, usage guidance, and output format with no unnecessary words. Front-loaded with key details.

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

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

With 5 parameters, no output schema, and no annotations, the description is too sparse. It omits parameter explanations and full output structure details, making it incomplete for reliable 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 coverage is 0%, so description must explain parameters, but only token_budget is indirectly referenced. Other parameters (limit, seeds, max_items) are completely unexplained, leaving the agent to guess from names.

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

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

The description clearly states the tool produces a context pack from a query, with ranked evidence and canonical entities. It distinguishes from sibling tool june_answer by specifying use cases: raw material for reasoning vs. answer generation.

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 contrasts with june_answer for when to use this tool vs. when to delegate to the answer. Lacks mention of other siblings or conditions where not to use, but the provided guidance is specific and actionable.

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

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

With no annotations provided, the description fully discloses behavioral traits: idempotent (second run writes 0 new), runs as a background job, returns 409 if already running, 403 on free endpoints, and the return format. This exceeds the burden.

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

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

The description is compact and front-loaded with the key action. However, it packs a lot of information into a dense single paragraph, which could be slightly restructured for readability without losing 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?

Given the absence of an output schema and annotations, the description provides a complete picture: purpose, when to use, how to use, idempotency, error codes, expected return format ({job_id, state, total, processed, nodes, edges, errors}). Nothing is left ambiguous.

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

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

The schema has 0% description coverage, leaving the description to explain parameters. It clearly explains the sole optional parameter 'job': call with no args to start, then pass {job: <job_id>} to check progress. This adds essential meaning beyond the schema.

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

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

The description clearly states the tool's purpose: re-extracting existing artifacts with a richer engine as a background job. It distinguishes itself from siblings like june_remember by specifying use cases (after Pro upgrade or many june_remember writes). The verb 're-extract' and resource 'this canvas's existing artifacts' are specific and 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?

The description provides explicit guidance on when to use the tool: after a Pro upgrade to backfill memories, or after many june_remember writes. It also explains idempotency and how to start (no args) vs. check progress (with job argument). This clearly differentiates from alternatives.

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 discloses key behavioral traits: exhaustive retrieval (not top-k), a cap with default 500, and that it returns all matches up to the cap. It doesn't specify performance or side effects, but the core behavior is well communicated.

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

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

The description is two sentences with no superfluous words. It front-loads the purpose ('Exhaustive structured retrieval') and efficiently conveys usage guidance and key details.

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

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

Given the lack of output schema and annotations, the description omits details about the return format (e.g., what node fields are included) and how multiple filters combine (AND vs OR). It also doesn't address error scenarios or what happens when the cap is exceeded. The explanation of the default cap is helpful but not fully adequate.

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 description mentions the predicate parameters (terms, regex, node_types, subtype) in context, helping agents understand they are filter criteria. However, it does not provide detailed syntax, data types, or combination logic for the 5 parameters, leaving some ambiguity. The cap parameter is explained briefly.

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

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

The description clearly states it performs exhaustive structured retrieval returning every matching node, distinguishing itself from june_search's ranked window. It specifies the predicate types (terms, regex, node_types, subtype) and the cap mechanism.

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 explicitly advises using this tool for aggregation questions where completeness is needed, contrasting it with june_search's ranked window. This gives clear guidance on when to prefer this tool over a sibling.

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?

Description discloses that it is a write operation returning write counts, but with no annotations provided, it lacks details on idempotency, error behavior, permissions, or side effects. Mentions 'exactly as given' implying no transformation, but overall minimal behavioral context beyond the basic mutation nature.

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 only two sentences, concise and front-loaded with the primary purpose. The second sentence provides usage guidance. Every sentence serves a purpose, though the first sentence could be slightly tighter.

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

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

For a complex tool with three parameters and no output schema, the description covers purpose and usage but lacks parameter details, behavioral traits, and return value structure beyond 'write counts'. It is functional but not comprehensive.

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

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

With 0% schema description coverage, the description only hints at the parameters via 'node rows' and 'edge proposals' but does not explain the structure, fields, or purpose of 'nodes', 'proposals', or 'idempotency_key'. The description adds insufficient value for parameter understanding.

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

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

The description clearly states the tool pushes explicit graph structure (node rows + edge proposals) exactly as given, using specific verb 'push' and resource 'graph structure'. It distinguishes from sibling june_remember by specifying that june_remember is for ordinary 'remember this' information.

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 'Use ONLY when you already have structured nodes/edges with ids and kinds' and directly contrasts with june_remember for ordinary information, providing clear when-to-use and alternative 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 provided, so description carries burden. It discloses output format ({edges[], ...}) and prerequisites, but doesn't mention error cases or limits. Still, it provides good behavioral context for a query tool.

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 definition, no wasted words. Each sentence adds clear value.

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

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

Given 4 parameters, no output schema, and no annotations, the description covers purpose, usage context, prerequisites, and output shape. Missing parameter details but otherwise complete for a simple 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 0%, and description only notes that node_id and node_type are required (already in schema). It does not explain direction or limit parameters, leaving users to infer their semantics.

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

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

The description clearly states it retrieves '1-hop edges' around a node, using a specific verb and resource. It distinguishes itself from sibling june_subgraph by specifying it's for immediate neighbors versus multi-hop expansion.

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 says to use after june_search returns a node_id, and to use june_subgraph for multi-hop. Also mentions prerequisites: requires node_id and node_type from a prior result.

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

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

With no annotations, the description carries the full burden. It discloses that entities and relations are extracted server-side, links to existing knowledge, notes that Pro endpoints run richer engines (and the result reports which engine ran), and explains the return of write counts with an instruction not to echo text. It also mentions size limit (64k chars). It could mention if it overwrites or only appends, but overall it's transparent.

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 appropriately sized, front-loading the core purpose. It is structured logically: purpose, usage, constraints, return instruction, sibling comparison. While every sentence earns its place, it could be slightly tightened (e.g., 'write text' and 'plain text' are redundant). Still, it is effective and clear.

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

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

Given the complexity (3 parameters, no output schema), the description is fairly complete. It explains input format constraints, the process (entity extraction, linking), output format (write counts, not text echoing), and even differentiates between free and Pro endpoints. It lacks error handling or performance notes, but for a write tool with this context, it is sufficient.

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 low (33%, only format has a description). The description compensates by adding that the text parameter accepts plain text or markdown up to ~64k chars, which is beyond the schema. For the format parameter, it effectively repeats the schema's description. The source_app parameter lacks any guidance, so the description provides marginal added value, raising from baseline 2 to 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?

The description clearly states the tool saves new information into a shared graph by writing text, with server-side entity/relation extraction. It distinguishes itself from june_ingest by noting it's preferred unless explicit graph structure is needed, clearly differentiating among its nine siblings.

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

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

Explicit usage context is provided: 'Use when the user states a fact, decision, update or note worth persisting for later' with examples like 'remember that…', meeting notes, and status changes. It also specifies when not to use: prefer over june_ingest unless explicit graph structure is needed.

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 provided, but description fully discloses behavior: runs server-side, reversible, default conservative, upgrade to semantic on Pro endpoints. Also states what happens with strong_only parameter and return format.

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

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

The description is concise and well-structured, covering purpose, usage, parameters, and return in a single paragraph. Slightly dense but each sentence adds value.

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 2 parameters and no output schema, the description provides sufficient context: explains when to run, parameter behavior, and return structure. Minor gap on min_confidence, but overall 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 0%, so description must explain parameters. It explains the 'strong_only' parameter well (default behavior and effect of false), but does not mention the 'min_confidence' parameter at all, leaving ambiguity.

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

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

The description clearly states the tool performs cross-format entity resolution and merges duplicates via reversible same_as edges. It distinguishes itself from siblings by specifying its use case and context.

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 explicit guidance: 'Use once after a batch of june_remember/june_ingest writes, not per question; reads are already resolution-aware.' Also explains parameter toggling between conservative and fuzzy matching modes.

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. It describes the tool as performing fused retrieval with multiple signal types, returning items with scores and provenance, and mentions degraded lanes. Though it does not explicitly declare read-only or state side effects, the description provides sufficient behavioral context for a search-like operation.

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

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

The description is concise at three sentences, front-loading the core functionality in the first sentence, followed by usage guidance and return structure. Every sentence adds value without redundancy.

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

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

Given no output schema and no annotations, the description gives a reasonable overview and distinguishes from siblings, but lacks parameter explanations and detailed return field descriptions. The mention of degraded_lanes is vague. It is adequate but not complete for an agent to fully understand all aspects.

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%, meaning no parameter descriptions in the JSON schema. The tool description does not explain the individual parameters (limit, seeds, min_confidence) beyond stating the required query. The agent is left to infer meanings, which is insufficient given the low schema coverage.

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

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

The description clearly states the tool performs fused retrieval over a knowledge graph combining lexical, dense, and graph signals into a ranked list. It explicitly distinguishes itself from siblings by specifying when to use june_answer or june_context instead, making the purpose 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?

The description provides explicit guidance on when to use this tool ('use when you need matching items...e.g. to find entities or check what the graph holds on a topic') and when not to, with specific alternatives named (june_answer, june_context). This fully supports correct tool selection.

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

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

No annotations provided, so description carries full burden. Mentions bounded depth ≤ 3 and return structure, but does not disclose side effects, auth needs, or read-only guarantee. Adequate 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?

Two sentences, front-loaded with main action and sibling distinction. No unnecessary words, 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?

Given no output schema, description gives basic return structure ({nodes[], edges[], …}). Covers depth limit, required params. Missing details on return fields, but sufficient for basic usage.

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 has 0% description coverage, so description adds meaning: node_id and node_type from prior results, depth ≤ 3. However, max_edges is not described. Good compensation for three of four params.

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?

Clearly states the verb (map/expand) and resource (neighbourhood around a node). Distinguishes from sibling june_neighborhood by specifying multi-hop versus direct edges.

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 says when to use ('map a cluster of related entities') and when to use alternative ('use june_neighborhood for just the direct edges'). Also notes prerequisites: 'Requires node_id + node_type from a prior result.'

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