Croncool Cron Jobs

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 real behavioral context beyond that: the field set returned and the explicit 'or not-found' failure outcome, which tells the agent how to interpret a miss.

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

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

Front-loaded with the usage trigger, then the return contract, then the exclusion — a sensible ordering with no filler. The middle enumeration sentence is dense and partially duplicative of the output schema, but it stays readable.

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?

An output schema exists, so the return-value enumeration is not strictly necessary, but the not-found disclosure and the when-to-use trigger round out the definition. Nothing an agent needs to call a single-id, read-only lookup correctly 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% and the single jobId parameter is fully documented with type and constraints, so the schema carries this dimension. The description only implies the id selects one job ('one cron job's'), adding no format or lookup semantics beyond the schema.

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

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

States a specific verb and resource (retrieve one cron job's details) and enumerates the retrievable fields, so the agent knows exactly what comes back. The closing clause 'Not for running the job' separates it from run_job without needing to open either schema.

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

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

Gives a concrete trigger ('when someone asks about one cron job's schedule or target, or whether it is enabled and last succeeded') and an explicit exclusion ('Not for running the job'), which routes the agent toward run_job for execution. It does not name sibling tools like get_job_runs for run history, so the routing is clear but not exhaustive.

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 real behavioral context beyond that: newest-first ordering, the fields returned (success/failure, HTTP status, duration, time), the absence of response bodies, and the pagination defaults (20)/ceiling (100).

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 that front-load the use case before the return-shape details; every clause (ordering, fields, pagination, exclusion) earns its place with no filler.

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

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

For a simple two-parameter read tool with a fully covered schema and an output schema present, the description supplies everything an agent needs: when to call it, what it returns, ordering, pagination limits, and what it is not for.

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 jobId and limit are already documented in the schema. The description restates the limit default and maximum, adding no syntax or format detail beyond the schema, which is the expected baseline when the schema does the work.

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

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

States a specific verb (get/check) and resource (job run history), with the intent framed as answering 'did it run, fail, or slow down'. It also distinguishes itself from the sibling run_job by explicitly saying 'Not for starting a run'.

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

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

Gives an explicit triggering condition ('when someone asks whether a cron job ran, failed or was slow, including a run just triggered') and an explicit exclusion ('Not for starting a run'), which routes the agent away from run_job. Nothing about when to choose this tool is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what the response contains and the pagination behavior ('50 steps by default and 200 at most'), which is useful for interpreting truncated traces.

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

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

Three tight sentences. The use-case trigger is front-loaded, the return payload follows, and the exclusion closes it. No filler.

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

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

An output schema exists, so return values need not be fully enumerated, yet the description still summarizes them and notes the step cap. For a read-only trace tool with two required ids, nothing an agent needs to invoke it correctly 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 description coverage is 100%, so runId, projectId and stepLimit are all already documented in the schema, including the same 1-200/default-50 range repeated in the description. Baseline 3 applies; the description adds no new parameter meaning.

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

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

Specific verb and resource: it traces a workflow run and states exactly what comes back — run status, timings, error code, plus steps with status, attempt, timings and error code. It also distinguishes itself from the listing sibling with 'Not for listing runs.'

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

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

Gives an explicit trigger ('when someone asks why a durable workflow run failed or where it is stuck') and an explicit exclusion ('Not for listing runs'), which routes the agent away from list_workflow_runs.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered by structured data. The description adds genuine behavioral context beyond that: the full set of returned fields and the pagination contract (20 per page, cursor for more), which the annotations do not convey.

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

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

Three tight sentences: usage trigger first, return payload second, exclusion last. No filler and nothing repeated from the annotations.

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?

An output schema exists, so return values need not be specified; the description nonetheless summarizes them usefully. With pagination covered and the exclusion stated, an agent has everything needed to call this correctly against its siblings.

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

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

Schema coverage is 100% and each of the three parameters (limit, cursor, projectId) is documented in the schema, so the baseline is 3. The description adds a small amount on top by framing the paging workflow ('20 per page by default, with a cursor for more'), which helps the agent understand how limit and cursor interact.

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

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

The description states a concrete verb and resource (list cron jobs / scheduled tasks) and enumerates exactly what comes back: id, name, schedule, target origin, method, enabled state, last run status and time. It also explicitly delimits itself against the sibling get_job_runs with 'Not for a job's full run history.'

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

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

It gives a clear trigger ('when someone asks what cron jobs or scheduled tasks they have, or which ones last failed') and one explicit exclusion (full run history). It stops short of naming the alternative tool (get_job_runs) the way the strongest definitions do, so the routing is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds value beyond that: default page size of 50, a hard cap of 100, a has-more flag, and the returned fields (id, name, creation time) — useful operational context an agent cannot get from the annotations.

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

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

Three short sentences, trigger-first, with no filler. Every clause carries information: triggers, return shape, pagination policy, and the sibling exclusion.

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 single optional-parameter list tool with a full output schema and complete annotations, this description covers everything an agent needs: when to call it, what comes back, pagination ceiling, and what it is not for.

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

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

Schema coverage is 100% and the limit parameter already documents its range and default ('1 to 100; defaults to 50'). The description's '50 by default and 100 at most' simply restates the schema, so 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+resource ('List your Croncool projects') and explicitly disambiguates from the sibling list_jobs with 'Not for listing jobs.' An agent can route between list_projects, list_jobs, and the other list_* siblings without opening a schema.

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

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

Gives two concrete triggers ('when someone asks which Croncool projects they have' or 'a project's id is needed') plus an explicit exclusion ('Not for listing jobs'). This is when-to-use and when-not-to-use in a single breath.

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 still adds non-obvious context: session-vs-API-key auth requirement and the 20-item default page size. It does not mention rate limits or whether results are paginated beyond the limit cap.

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

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

Front-loaded with the usage trigger, then returns, then constraints — every sentence earns its place. Slightly list-heavy in the middle sentence, but there is no filler or 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?

For a read-only, two-optional-parameter tool with annotations covering the safety profile and an output schema, the description supplies everything else an agent needs: when to call it, when not to, auth mode, and default page size.

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 limit and projectId are already documented there; the description only restates the default of 20, matching the schema. Baseline 3 applies since the schema carries the parameter burden.

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

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

States a specific verb+resource (list webhook subscriptions) and pairs it with the concrete outcome the caller cares about: delivery health. It enumerates the returned fields (endpoint origin, events, active state, consecutive failures, auto-disabled, last delivery time), so an agent knows exactly what query this answers without opening the schema.

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

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

Gives an explicit trigger ('when someone asks whether their webhooks are delivering, failing or were disabled') and an explicit exclusion ('Not for changing or re-enabling a webhook'), which routes the agent away from mutation tools. The auth constraint (signed-in session, not API key) is a further use-condition stated plainly.

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 behavior beyond that: newest-first default ordering, 20-per-page pagination with a cursor, and the returned field set (id, workflow name, status, timings, error code). It does not discuss rate limits or cursor expiry, but for a read-only list tool this is solid.

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

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

Two sentences, zero filler, with the usage trigger front-loaded before the return and pagination details. 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?

An output schema exists, yet the description still summarizes the returned fields, and the pagination/cursor and default-sort behavior are all disclosed. Nothing an agent needs to call this six-parameter list tool correctly 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 description coverage is 100%, so the schema already documents projectId, workflowName, status, sort, limit and cursor. The description restates the defaults and filters but adds no syntax or format detail beyond the schema, which is the expected baseline when the schema carries the load.

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

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

States a specific verb and resource (list workflow runs) scoped to a Croncool project, and explicitly carves out the sibling territory with "Not for one run's steps." An agent can distinguish it from get_workflow_run or get_job_runs without opening any schema.

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

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

"Use this when someone asks about recent or failed runs" gives a concrete trigger, and the closing exclusion ("Not for one run's steps") steers away from the detail sibling. It stops short of naming the alternative tool explicitly, so the routing is clear but not fully enumerated.

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 structurally. The description adds value beyond that by disclosing the return shape (name, run counts by status, last run time) and the result ceiling (50 default, 100 max), which goes beyond the annotation set.

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 trigger condition, then the return payload and the boundary limit. No filler, no repetition of the title, and the exclusion lands last where it is most useful.

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?

An output schema exists so return values need not be spelled out, yet the description still characterizes them briefly. With annotations covering safety and a fully described 2-parameter schema, nothing an agent needs to invoke this tool correctly 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 description coverage is 100%, so both projectId and limit are fully documented in the schema. The description restates the pagination defaults ('50 by default and 100 at most') and the single-project scope but adds no syntax or format detail beyond what the schema already provides. 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 ('list durable workflows') and scopes it to a single project with per-status run counts and last run time. The final clause 'Not for individual runs' explicitly separates it from list_workflow_runs and get_workflow_run, so the agent can distinguish it from siblings without opening a schema.

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

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

Gives an explicit trigger ('when someone asks which durable workflows a Croncool project runs, or how many runs are running, pending, completed, failed or cancelled') plus an explicit exclusion ('Not for individual runs'). Both the when-to-use and the when-not-to-use are stated, with the alternative behavior implied by the exclusion.

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, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the sidebar cannot run jobs or modify configuration, and request payloads, full target URLs, secrets and workflow bodies are deliberately excluded from what is shown.

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, no filler. What the sidebar shows comes first, followed by the read-only constraint and the exclusion list, so the most decision-relevant information is front-loaded.

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

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

With an output schema present, the description does not need to explain return values, and it correctly limits itself to scope, read-only status and data exclusions. The only omission is a pointer to programmatic siblings for agents that cannot use a sidebar view.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify about inputs. The baseline for a parameterless tool is 4.

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 ("Open Croncool") plus the scope of what the view contains: owned projects, scheduled jobs, target origins, schedules and latest execution status. It is clearly not a data-fetch or mutation tool, so an agent can distinguish it from siblings like list_jobs or run_job by inference, but 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?

The description establishes the context of use (browsing/reviewing) and the hard constraint that this sidebar is read-only and cannot run jobs or change configuration, which implies when it is appropriate. However, it never states when an agent should prefer this over programmatic siblings such as list_projects or list_jobs, leaving the choice to inference.

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

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

Annotations already cover the safety profile (destructive, non-idempotent, open-world), and the description adds genuinely new behavioral facts: it returns only that Croncool invoked the job rather than the target's response, each call re-sends the configured request, and repeated calls re-fire with downstream write/message/billing effects.

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 tightly packed sentences with the trigger condition front-loaded, then the return-value caveat, then the repeat-call hazard. Every sentence carries distinct information and none 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?

An output schema exists so return structure need not be explained, yet the description still flags the key caveat that the response only confirms invocation. Combined with the re-send hazard, an agent has everything needed to call this safely.

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% with a single well-formed jobId (uuid) parameter, so the schema already does the work. The description adds no syntax or format detail beyond what is documented, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('run or trigger a cron job now') and makes the scope unambiguous. An agent can distinguish it from get_job_runs or get_workflow_run without opening a schema.

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

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

Opens with the triggering condition ('when someone asks to run or trigger a cron job now') and explicitly excludes a nearby use case ('Not for checking a run's result'), routing the agent toward the read-side siblings.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world semantics, so the safety profile is settled. The description adds real behavioral content beyond that: the result is a summary card, and it is capped at 12 jobs, which warns the agent about truncation. It does not say how to retrieve the remainder or whether the cap is silent, leaving a modest gap.

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

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

Two tightly packed sentences: usage trigger first, then the exact return contents, then the exclusion. No filler, no repetition of the title, and every clause 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?

For a one-parameter read tool with an output schema and full annotations, the description is effectively complete; the output schema means return shape need not be explained. The only shortfall is the unaddressed truncation at 12 jobs, where an agent is not told what to do when the project has more.

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 there is a single required projectId whose meaning is already self-evident from the schema. The description adds no further meaning about the id format or source, 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 resource (one Croncool project) and enumerates exactly what the card contains: project name/creation time, workflow hosting status, and up to 12 jobs with schedule, origin and last run status. The closing exclusion ('Not for a job's run history') separates it from get_job_runs and get_job without needing the schema.

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

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

Gives an explicit trigger ('when someone wants a quick overview or dashboard of one Croncool project') plus a negative boundary against run-history tools. It stops short of naming the sibling to use instead (get_job_runs) or pointing to list_projects for cross-project views, so it is clear but not fully routing.

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