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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the shape of what comes back (all public methods, properties, fields, events), which is genuinely useful, but says nothing about failure modes (class not found), namespace ambiguity resolution, or output size for very large classes.

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 purpose and usage sentence are front-loaded and waste no words. The Args block restates the parameter name but adds real format guidance and examples, so it earns its place reasonably well, though the structure is slightly boilerplate.

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 need not explain return values, and the single required parameter is well covered. For a simple read-only lookup this is close to complete; only edge-case behavior (missing class, ambiguous namespace) is unaddressed.

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: it specifies that class_name accepts a name with or without a namespace and gives four concrete examples (Rigidbody, Tilemap, InputAction, SceneManager). That is meaningfully more than the schema's bare 'string' type.

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

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

The description states a specific verb and resource ('Get a complete reference card for a Unity class') and enumerates the returned members (public methods, properties, fields, events), so the agent knows exactly what this tool produces. It does not explicitly contrast itself with siblings like get_method_signature or search_unity_api, which keeps it from 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?

It gives clear context for use — 'Use this when you want to see everything available on a class at a glance' — which implicitly separates it from the narrower get_method_signature. No explicit when-not-to-use or named alternatives are provided, so it falls short of a 5.

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 behavioral burden. It implies a safe lookup and shows that short and fully-qualified names are both accepted, but it never states matching behavior (exact vs. partial), what happens when the name is unknown, or that the call has no 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?

Purpose and the usage cue are front-loaded, and the Args block is compact and example-driven. The section header formatting is slightly heavier than needed for a single parameter, but nothing 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?

The tool is simple, has one parameter, and ships an output schema, so return values need no explanation; the description covers purpose, usage timing, and input format. Only edge-case behavior for names that aren't found or are ambiguous 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 0%, so the description must compensate, and it does reasonably: "name: Class or member name to check" plus four concrete examples ("WWW", "FindObjectOfType", "UnityEngine.Component.BroadcastMessage") clarify accepted name forms and qualification levels.

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: check whether a Unity class/method/property is deprecated and find the replacement. That is clear and concrete, but it never differentiates itself from siblings like get_class_reference or search_unity_api, which could plausibly also surface deprecation 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?

"Use this before using any API you suspect might be outdated" gives a clear trigger condition and the FindObjectOfType/FindAnyObjectByType example makes it concrete. It stops short of naming alternatives or stating when not to use it (e.g., when a full class reference lookup is already 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?

There are no annotations, so the description carries the full burden. It does disclose useful behavior: what is returned (parameters, return type, deprecation status) and that overloads are disambiguated by including parameter types in the fqn. However, it says nothing about failure behavior for unknown or malformed names, ambiguity resolution, or caching/rate characteristics.

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 usage condition are front-loaded in the first two lines, before the argument detail. The Args block is reasonably tight, though the trailing overload note sits awkwardly outside the fqn entry and the stripped-in example formatting adds some visual noise.

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 return format need not be detailed, yet the description still names the three returned facets helpfully. The single required parameter is fully explained. Only edge-case behavior for unresolvable or overload-ambiguous names is missing, which is minor for a lookup 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 coverage is 0% for the single fqn parameter, so the description must compensate, and it largely does: it defines the format, gives two concrete examples, and explains the non-obvious overload convention ('UnityEngine.Physics.Raycast(UnityEngine.Ray)'). It stops short of stating case sensitivity or whether partial/namespace-less names are accepted.

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: 'Look up the exact signature of a Unity API member by fully-qualified name.' The qualifier 'when you know the specific API' implicitly separates it from search_unity_api and get_class_reference, but no sibling is named explicitly, so the differentiation is inferential rather than stated.

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 clear usage context ('when you know the specific API (e.g. from autocomplete or docs reference)') and states what it is used to obtain (exact parameters, return type, deprecation status). No explicit when-not condition or named alternative, keeping it short of a 5.

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 disclosure burden. It does state the return content (namespace plus using directive) and implies a read-only lookup, but says nothing about behavior when the name is ambiguous, not found, or a member of multiple types.

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 purpose and usage in the first two sentences, then a compact Args block. The Args line slightly restates the schema's parameter name, but the added examples earn their place.

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

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

An output schema exists, so return-value explanation is not required; between the purpose, the when-to-use sentence, and the parameter examples, an agent has everything needed to call this single-parameter lookup correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines 'name' as a class or member name and supplies three concrete Unity examples ('SceneManager', 'NavMeshAgent', 'Rigidbody') that clarify the expected input shape.

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 ('Find') and a precise resource ('the correct namespace and using directive for a Unity class or member'), which an agent can act on without opening the schema. It does not explicitly differentiate itself from siblings like get_class_reference or search_unity_api, so it stops 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?

Explicitly names the triggering condition: 'Use this when you need to know which namespace to import for a Unity type.' That is clear context for invocation, but it offers no exclusions or named alternatives among the sibling tools (e.g. when to prefer search_unity_api 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?

No annotations are provided, so the description carries the burden, but this is a low-risk read operation and it does disclose that results are ranked and include summaries. It omits anything about indexing scope, freshness, or empty-result behavior. Since an output schema exists, the return shape need not be spelled out, keeping this at an adequate 3.

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 purpose, then the usage line, then a tight Args block. Every line contributes, and the parameter lines earn their space by carrying enum/limit information absent from the schema.

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

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

For a 3-parameter read-only search with an output schema already describing the response, the description covers purpose, usage, and all parameter meanings. A note on exact vs keyword matching or result ordering would close the last gap.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does: it adds example queries, the "max 20" bound on n_results (the schema only shows default 5), and the enumerated member_type values ("type", "method", "property", "field", "event") that the schema lacks entirely. Only the exact matching semantics of query are left unstated.

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 ("Search") and resource ("Unity API documentation") plus the object domain (classes, methods, properties, fields). It does not explicitly name or contrast against siblings like get_class_reference or get_method_signature, so an agent must infer that this is the keyword-discovery path versus their name-lookup path.

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 to find Unity classes, methods, properties, and fields" implies usage (discovery when you don't have an exact identifier) but never states when to prefer it over the get_* siblings or any exclusions. Enough to orient, not enough to route decisively.

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