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

No annotations are supplied, so the description carries the full burden. It does disclose useful behavior beyond the schema — results come from an in-memory cache and force_refresh bypasses it — but says nothing about permission requirements, how fuzzy matches are ranked, case sensitivity, or what happens when nothing matches.

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

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

The core purpose and the caching behavior are front-loaded in the first sentence, followed by a compact parameter list. The Args block partially restates schema titles, but each entry adds meaning, so there is little pure waste despite the docstring-style indentation.

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 explained, and the caching behavior is covered. However, for a search tool with zero schema coverage and no annotations, the description omits result ordering, case/matching semantics, and error behavior, leaving real gaps for an agent deciding how to phrase a query.

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, and it does: all three parameters are explained, including the non-obvious semantics of force_refresh (bypass the cache and refetch from the API) and limit (maximum results). It stops short of clarifying matching semantics for search_term, such as substring vs. edit-distance behavior.

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: find tables by name in Unity Catalog, with the distinguishing mechanism (fuzzy matching) named. It implicitly contrasts with the sibling listing tool get-tables-in-catalogs-schemas, but never names that sibling or explicitly draws the search-vs-list boundary.

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

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

Usage is only implied: 'find tables by name' plus 'fuzzy matching' suggests this is the right tool when the exact table name is unknown, but there is no explicit statement of when to use this instead of get-tables-in-catalogs-schemas or get-tables-details, and no stated exclusions or preconditions.

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

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

With no annotations, the description must carry the behavioral burden; "Retrieve" weakly signals a read-only, non-mutating operation. It does not mention permissions/authentication requirements, whether results are paginated or capped, or that access is limited to catalogs the caller can see, though the existence of an output schema removes the need to describe the return shape.

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

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

A single front-loaded sentence with no filler or redundant restatement of the name. It is efficient, though "available" is slightly imprecise about visibility scoping.

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 zero-parameter read-only listing tool with an output schema already documenting returns, the description covers the essentials: what is listed and where. Minor gaps are the lack of hierarchy context and any mention of permissions or result limits.

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 to explain; the description correctly does not invent any. Baseline for a no-parameter tool 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 ("Retrieve a list of all available catalogs") and scopes it to "the Databricks workspace". It is clear what is returned, but it never contrasts itself with hierarchical siblings such as get-schemas-in-catalogs or get-tables-in-catalogs-schemas, so the agent must infer the catalog/schema/table layering.

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 prerequisites, and no named alternative. The only hint is "all available", which implies an unfiltered top-level listing, leaving the agent to infer that this is the entry point before descending into schemas and tables.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but nothing is said about permissions, behavior for unknown or deleted job IDs, response size for jobs with many tasks, or pagination—all relevant for a details endpoint.

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

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

The core sentence is short and front-loaded, but the raw 'Args:' docstring block repeats the schema verbatim and the fragment '- List of integer job IDs' is ungrammatical and adds nothing. The structure looks like an unedited function docstring rather than agent-facing guidance.

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-value explanation is unnecessary, and the tool has only one simple parameter. Still, for a details-fetching tool with no annotations, more context about error behavior on invalid IDs and the batch semantics would make it complete.

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

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

Schema description coverage is 0%, but the single parameter is self-explanatory (job_ids, array of integers, required). The description restates 'List of integer job IDs', confirming batch input, yet adds no format, ordering, or limit details 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 uses a specific verb+resource ('Get job details') and names the returned content ('settings and tasks') scoped by job id, so an agent knows what it retrieves. It does not explicitly contrast itself with nearby siblings like get-jobs or get-job-runs, leaving that distinction to inference.

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 and no mention of alternatives such as get-jobs (listing) or get-job-runs (execution history). The only implied guidance is that a job id is required, which the schema already states.

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 bears the full behavioral burden. It discloses only that results are sorted by most recent, saying nothing about permissions, result ordering across multiple job ids, truncation behavior, or what a run record contains beyond what the output schema implies.

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 prose is short, but it is written as a Python docstring with an 'Args:' block, which spends lines restating parameter names rather than adding value, and the parameter it restates does not match the schema. Front-loading is fine, but the structure is boilerplate rather than purposeful.

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 shape need not be explained. However, for a two-parameter query tool with zero schema coverage and no annotations, the description leaves material gaps: the 'amount'/'n_recent' mismatch, the default of 1, and the absence of any usage context relative to the six sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does. More seriously, it refers to a parameter called 'amount' while the schema defines 'n_recent' (default 1), so an agent mapping the prose to the schema encounters a name mismatch with no reconciliation or mention of the default.

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 first line states a specific verb and resource: fetch recent job runs for given job ids. It is distinguishable from get-job-details (which presumably returns one job's configuration) because it explicitly returns runs. It falls short of a 5 because it never names or contrasts with any sibling tool.

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

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

There is no guidance on when to use this tool versus get-jobs or get-job-details, no mention of prerequisites, and no statement of limits on how far back 'recent' reaches. The agent must infer usage entirely from the tool 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?

No annotations are provided, so the description carries the behavioral burden. 'Retrieve a list' makes the read-only nature clear, but it does not mention pagination, permissions, ordering, or whether all job states are included.

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

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

The description is a single, front-loaded sentence with no unnecessary wording. It communicates the core action and scope 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?

For a zero-parameter list tool with an output schema, the description is mostly complete because it names the resource and workspace scope. It could be stronger by clarifying how it relates to get-job-details and get-job-runs.

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

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

The tool has zero parameters and schema coverage is 100%, so there is no parameter meaning for the description to add beyond the input schema.

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

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

The description states a clear verb and resource: 'Retrieve a list of all jobs in the workspace.' It distinguishes listing from detail/run siblings only implicitly, since it does not name get-job-details or get-job-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?

It implies usage for listing jobs, but gives no explicit when-to-use guidance, no exclusions, and no routing against the available job-related siblings such as get-job-details or get-job-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?

No annotations are supplied, so the description carries the full burden. 'Retrieve' weakly implies a read, but it never states read-only safety, what happens with an invalid or empty catalog name, whether missing catalogs are skipped or error, or whether results are paginated. Those are real behavioral questions for a zero-annotation 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?

The tool's purpose is front-loaded in the first sentence and there is no filler. The trailing 'Args:' block is docstring residue that duplicates the schema, but it is short and does not obscure the main statement.

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?

This is a simple single-parameter read tool and an output schema exists, so return values need no explanation. Still, with no annotations and no parameter descriptions anywhere, the definition leaves the agent without behavioral or format guidance it cannot get elsewhere.

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 the description must compensate and largely doesn't. It restates only that catalog_names is a list of catalog names, adding no meaning about accepted format, whether multi-part or fully qualified names are allowed, or whether an empty list is valid — all beyond what the array-of-strings schema already says.

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 all available schemas within given catalogs. The scope ('in the given catalogs', 'all available') makes it distinguishable from get-catalogs and get-tables-in-catalogs-schemas, though it never names those siblings 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?

Usage is only implied: the 'given catalogs' phrasing hints this is a drill-down step after get-catalogs, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer the catalog→schema→table hierarchy from the sibling names 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?

With no annotations, the description carries the full behavior burden. 'Retrieve' implies a read-only operation and the list input suggests batching, but it does not disclose authorization requirements, error or partial-failure behavior, or what kinds of details are included; the output schema covers return values but not these operational traits.

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 short and front-loaded, with one purpose sentence and one parameter note. There is minor redundancy and awkward docstring-style formatting with 'Args:', which keeps it from being maximally concise.

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

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

For a simple one-parameter read tool with an output schema, the description covers the core operation and input format adequately. It could be more complete about sibling selection and failure behavior, but the essential information needed to invoke it is present.

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 input schema has 0% description coverage, so the description supplies important meaning for the only parameter: it is a list of full table names in catalog.schema.table format. It does not cover edge cases such as duplicate names or maximum list length, so it is not a 5.

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

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

The description states a specific verb, 'Retrieve', and a specific resource, 'detailed information for the given tables', so the core operation is clear. It does not explicitly distinguish itself from sibling tools such as get-tables-in-catalogs-schemas or find-tables-by-name, so it is not 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 implies usage when the caller already has full table names and needs details, but it does not state when to choose this over listing or searching siblings, nor does it provide explicit prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read but says nothing about permissions required, pagination or result limits, behavior on nonexistent schemas, or whether nested/child schemas are traversed. It also doesn't clarify whether tables includes views or only base tables.

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

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

The core sentence is front-loaded and free of padding, and the docstring-style Args block is the only structural overhead. Slightly verbose formatting, but no wasted meaning.

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 explained, and the format of the one parameter is covered. Against that, the tool has no annotations and the description omits error behavior, result-scope limits, and routing guidance relative to its four sibling tools.

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

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

Schema description coverage is 0% and the single parameter is documented only as 'array of strings' in the schema, so the description does add value by specifying the 'catalog.schema' dot-notation format and that it is a list. However, it leaves ambiguity about whether three-part names are accepted, how multiple pairs combine in one call, and what happens on malformed entries.

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 a list of all tables') scoped to 'the given catalogs and schemas', which implicitly contrasts with name-based siblings like find-tables-by-name. It doesn't explicitly name or distinguish itself from get-tables-details, 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 explicit when-to-use guidance, no mention of prerequisites (that you must first know catalog/schema names via get-catalogs and get-schemas-in-catalogs), and no statement about when to prefer find-tables-by-name or get-tables-details instead. Usage can only be inferred from the parameter shape.

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