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

With no annotations, the description should disclose behavioral traits like read-only nature or required permissions. It only describes output, leaving the agent to infer side 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?

The description is concise (7 lines plus parameter notes), uses bullet points for clarity, and is front-loaded with the main purpose. Every 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?

Given no output schema, the description provides a detailed list of return fields (columns, PKs, indexes, row count) that adequately covers the expected output. Slightly missing mention of return format or error cases.

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% parameter description coverage, but the description adds clear explanations for 'owner' (schema owner with example 'FUSION') and 'table_name' (exact table name with example 'AP_INVOICES_ALL'), fully compensating 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 clearly states the tool provides a 'Full description of a Fusion table or view' and lists specific output components (columns, primary keys, indexes, etc.), 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?

No guidance on when to use this tool versus siblings like 'search_tables' or 'execute_query'. The description lacks context about appropriate scenarios or 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 fully discloses read-only behavior, use of BI Publisher, string-only return values, and server cap. No side effects are mentioned but none expected.

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?

Well-structured with core function first, then constraints, parameter details, and return format. Every sentence adds value, no 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 2-param tool with no output schema, the description covers all necessary aspects: accepted queries, parameter details, return format, and underlying mechanism. Complete for its complexity.

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; the description adds comprehensive meaning: sql param explained with example of inlining values, max_rows defined as row limit with server cap hint.

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 executes read-only SELECT/WITH queries against Oracle Fusion via BI Publisher, listing rejected statement types. This distinguishes it from sibling tools focused on metadata or source code.

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 only SELECT/WITH are accepted and DML/DDL/PL/SQL are rejected. Provides guidance on inlining values. While it doesn't directly compare to siblings, the usage context 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?

With no annotations, the description carries full burden. It discloses the limitation regarding dynamic execution and the source (ALL_ARGUMENTS). While it doesn't explicitly state read-only behavior, the limitation implies it is a read 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 very concise: two sentences plus a short note. It is front-loaded with the main action and returns format, followed by a critical usage note. No superfluous words.

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 tool's simplicity (3 parameters, no output schema), the description covers the essential purpose, return columns, and a key limitation. It could mention that the tool assumes Oracle database, but it's sufficient for an agent to understand 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 coverage is 0% and the description only explains package_name ('required when the procedure lives inside a package'). The meanings of owner and object_name are implied but not explicitly described, leaving room for 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 explicitly states the tool returns the full argument list for a stored procedure or function from ALL_ARGUMENTS, and lists the columns returned. It clearly distinguishes this from execution by noting that dynamic execution is not supported.

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 provides clear context: 'This tool is for discovery and understanding only' and directly states that Fusion MCP does not support dynamic procedure execution. It does not explicitly name alternative tools but the context implies when not to use 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?

With no annotations provided, the description discloses that only public subprograms are returned and lists the output fields. However, it does not mention read-only nature, error handling, permissions required, or performance implications. It offers minimal behavioral context beyond the basic capability.

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, using two sentences to convey purpose and output. Every word serves a function, with no redundancy or 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?

The description covers the primary function and output but omits details like parameter format (case sensitivity? wildcards?), error scenarios, and prerequisites (e.g., user must have access to the package). For a low-complexity tool with no output schema, it is adequate but not thorough.

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 does not explain the parameters 'owner' and 'package_name' at all. Given 0% schema coverage, the description should compensate by clarifying their meaning (e.g., 'owner' is the Oracle schema, 'package_name' is the package identifier), but it omits any such detail, leaving the agent to infer from the titles.

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 lists all public subprograms inside a Fusion Oracle package, specifies the return fields, and distinguishes it from siblings like get_procedure_signature (which focuses on a single procedure) and describe_table (which describes tables).

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 does not provide any guidance on when to use this tool versus its siblings (e.g., get_procedure_signature or read_object_source). It lacks explicit context such as 'use this to explore package structure' or 'for a specific procedure signature, use get_procedure_signature instead'.

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?

Discloses return format and valid object_type values, but no annotations exist. Missing behavioral details like authentication requirements, rate limits, error handling, or what happens if object is not found.

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?

Extremely concise: two sentences plus a bullet list for object_type and return format. No fluff, purpose is front-loaded. Every 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?

Adequately covers purpose, parameters, and return format for a simple read tool. Lacks explanation of ALL_SOURCE, permissions, or error scenarios, but given no output schema and low complexity, it is reasonably 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 has 0% description coverage. Description adds meaning for object_type (list of allowed types, omission behavior), but owner and object_name are only mentioned as required with no additional context beyond 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?

Description clearly states the tool reads full source code of a stored object from ALL_SOURCE in Fusion, specifying verb 'read' and resource 'source code'. It distinguishes from siblings like get_procedure_signature (signature only) and search_source (search, not read).

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 guidance on when to use this tool versus alternatives like get_procedure_signature or list_package_contents. Only lists valid object_type values but does not provide contextual usage instructions.

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. The description adds the return format and example, but omits behavioral traits like read-only nature, case sensitivity, or potential performance impact. It provides basic transparency but no depth.

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 sentences covering purpose, example, and output. No redundant content, front-loaded with clear action and example.

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

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

For a 2-parameter search tool with no output schema, the description sufficiently covers purpose, input, and output shape. Missing some contextual details like whether search is case-insensitive, but overall 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?

Schema description coverage is 0%. The description clarifies the 'keyword' parameter (column name or comment) and gives an example, but does not explain the 'limit' parameter beyond its default. Partial compensation.

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 finds tables/views by column name or comment, with a concrete example. It differentiates from siblings like search_tables by focusing on columns.

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

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

Usage is implied through the example but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. The description lacks directives for choosing this over search_tables or other tools.

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 full burden. It discloses that the limit is capped at 200 and lists return fields. It does not mention permissions or side effects, but the read-only nature is implied. Overall, good transparency for a search 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 description is three sentences plus a bullet list of return fields. It is front-loaded with purpose and efficient, though the bullet list could be integrated into prose. No 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?

The tool has 4 parameters and no output schema. The description covers all parameters and return fields, and mentions the limit cap. It lacks details on error handling, pagination (though limit is given), or ordering, but is reasonably complete for a simple search.

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 fully compensates by explaining each parameter: keyword as substring match, object_types as optional filter, owner as schema filter, and limit with max cap. This adds significant meaning beyond the schema's bare types.

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 searches ALL_OBJECTS in Oracle Fusion/ERP Cloud by object name pattern, specifying the verb (search), resource (ALL_OBJECTS), and system. It distinguishes from siblings like search_tables, search_columns, etc., which have narrower scope.

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 explains keyword matching (case-insensitive, substring) and optional filters (object_types, owner, limit). However, it lacks explicit guidance on when to use this tool over siblings like search_tables or search_source, leaving the agent to infer context.

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

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

With no annotations provided, the description carries the full burden. It discloses that scans can be slow on large schemas, which is a key behavioral trait. It does not mention side effects or authorization needs, but the read-only nature is implied.

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 (four sentences) and front-loaded with the main purpose. 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, the description explains return format (distinct owner/name/type) and next steps. It also mentions performance considerations. This is complete for a search 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%, so the description must explain parameters. It clarifies keyword, type_filter (with examples), and owner implicitly, but does not explain name_filter or limit. This provides moderate value 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 performs full-text search across ALL_SOURCE to find objects containing a keyword, using a specific verb and resource. It distinguishes itself from sibling tools like search_objects and search_columns by focusing on source code content.

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 advises constraining type_filter and owner to improve performance, and directs users to read_object_source for full source retrieval. However, it does not explicitly list when to avoid using this tool or mention alternative tools for similar tasks.

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 burden. It discloses the return fields (owner, object_name, object_type, table_comment) and that search is by name or comment containing the keyword. However, it does not mention side effects (likely read-only), rate limits, or behavior on no results. The transparency is minimal but adequate for a simple search 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 concise sentences with no wasted words. First sentence defines the tool's purpose and scope, second lists the return columns. Information is front-loaded and efficient.

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 annotations, output schema, or detailed parameter info, the description is incomplete. It does not address error handling, default limit behavior, or how to refine searches. With multiple sibling tools, more context (e.g., when to use this vs. search_columns) would be valuable. The minimal coverage leaves gaps for a 2-parameter 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 the description adds no meaning beyond parameter names. The 'keyword' parameter is not explained (case sensitivity, pattern matching), and 'limit' is not described (purpose, default behavior). Without any additional info, the agent cannot infer proper usage of parameters.

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 function: 'Find tables/views in Oracle Fusion whose name or comment contains the keyword.' It uses a specific verb ('Find') and resource ('tables/views'), and distinguishes from siblings like search_objects and search_columns by focusing on tables/views and keyword matching.

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 guidance is provided on when to use this tool versus its siblings (e.g., search_objects, search_columns). There is no mention of prerequisites, exclusions, or context for effective use. The description only states what it does, leaving the agent to infer usage.

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