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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description usefully adds that the output is a transparent 0-100 prominence score combining Google result score, knowledge panel completeness, Wikipedia coverage, Wikidata depth, and linked official profiles, plus a plain-English reason for each. It also discloses the API-key dependency and Wikidata-only fallback, though it omits rate limits, pagination, or score stability details.

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 uses three sentences: the first front-loads the purpose, the second explains the scoring methodology, and the third states the prerequisite. Each sentence earns its place with no redundant or vague 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 read-only analysis tool with 100% schema coverage and no output schema, the description covers the important behavioral context: score composition, plain-English reasoning, and data-source fallback. It could say more about the exact return shape, but the key gaps are closed well enough for an agent to call it 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 100%, with query, limit, types, and language all documented in the schema. The description adds no meaningful parameter semantics beyond what the schema already states, so the baseline score of 3 is 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 ('Analyze') and resource ('entity prominence') and explains the outcome: determining which entity matched for a name has the strongest Knowledge Graph presence. It is distinguishable from get_entity and compare_entities by its ranking focus, but does not explicitly name a sibling tool for contrast.

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 by describing the analysis and ranking it performs, and it supplies a key prerequisite: Google data requires GOOGLE_KG_API_KEY, otherwise results come from Wikidata only. However, it gives no explicit when-to-use or when-not-to-use guidance relative to find_entities, compare_entities, or get_entity.

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 establish readOnlyHint and openWorldHint, so the bar is lower. The description adds real behavioral context beyond them: the external Google KG dependency, the required API key, and that results silently narrow to Wikidata when it is absent. It does not describe result sizing beyond the 2-5 input bound.

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 comparison scope and the compared dimensions, then the usage patterns, then the auth caveat. Two dense sentences with no filler, though the enumerated dimension list is long enough to slightly dilute the core action.

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 no output schema, the description usefully previews what comes back (types, scores, gaps, facts, connections, profiles). Combined with input formats, cardinality, use-case routing, and the API-key fallback, an agent can select and invoke this correctly without further inference.

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%, so the accepted ID formats (KG IDs, Wikidata IDs, names) are already documented in the schema. The description nonetheless reinforces name-resolution semantics with concrete examples ('hubspot', 'salesforce') and cross-references find_entities as the ID source, adding practical value over the schema alone.

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 (compare) and resource (entities) with an explicit 2-5 cardinality, then enumerates exactly what is compared: types, descriptions, prominence/readiness scores, gaps, key facts, connections, and profiles. This distinguishes it from siblings like get_entity or analyze_entity_prominence.

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 use cases with the exact argument pattern for each: same-name entities by passing IDs 'from find_entities', competitors by passing names like "hubspot" and "salesforce". It also states a prerequisite (GOOGLE_KG_API_KEY) and the degraded fallback behavior, so the agent knows when the tool will under-deliver.

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 cover safety (readOnlyHint, openWorldHint), and the description adds genuinely new behavior: results are sorted by Google's result score highest-first, and there is a credentialed path (GOOGLE_KG_API_KEY) versus a degraded Wikidata-only fallback without it. That auth/degradation disclosure is exactly the kind of context annotations cannot carry.

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, front-loaded with the core purpose and return fields followed by the auth caveat. No filler, though the parenthetical definition could be tightened slightly.

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 no output schema, the description compensates by naming the returned fields, and it discloses the auth-dependent data source. An agent can call this correctly and interpret the ranking. Only the Wikidata fallback's effect on field availability is left implicit.

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 limit, query, types, and language are already fully documented in the schema, setting the baseline at 3. The description reinforces result ordering and the Google-only nature of typed results but adds no syntax or format detail beyond what the schema states.

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 ("Find all Knowledge Graph entities") and clarifies the concept as "the entities behind Google's knowledge panels." It also enumerates the returned fields, which makes the tool's scope obvious. It does not explicitly name how it differs from siblings like get_entity, 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?

Usage is implied by "associated with a name" (a name-based lookup, versus the ID-based get_entity), but no alternatives are named and there is no explicit when-to-use/when-not guidance. The auth-fallback note gives operational context but not routing guidance.

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

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

Annotations cover read-only and open-world safety, so the bar is lower, and the description still adds genuine behavioral context: an API-key requirement and, crucially, degraded results (Wikidata only) without it. That fallback behavior is exactly the kind of trait an agent needs and is not present in the schema or 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?

The long opening enumeration is front-loaded and justified because no output schema exists, and the two follow-up sentences (usage mode, auth caveat) each earn their place. It is dense but not padded.

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 no output schema, the description must carry return-value disclosure and it does so thoroughly, plus the auth/fallback caveat. Annotations handle the safety profile. Only minor gaps remain, such as not noting the limit parameter's relevance to query-based lookups.

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 all five parameters are already documented; baseline is 3. The description adds the id-vs-query selection semantics (query returns the top match) but says nothing about limit, types, or language beyond what the schema provides.

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?

Starts with a specific verb+resource ("Full profile of one entity") and enumerates the return contents (description, facts, connections, JSON-LD, etc.), which is unusually concrete. It doesn't explicitly name find_entities as the sibling it complements, but the 'id for a specific entity, or a query to profile the top match' framing distinguishes its single-entity profiling role.

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?

States clearly when to pass an id (specific entity) versus a query (top match to profile), which is real selection guidance for the two main parameters. It also discloses the GOOGLE_KG_API_KEY requirement and the Wikidata-only fallback. It stops short of naming find_entities/compare_entities as the alternatives for other tasks.

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