Get Kilango Vocabulary

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the enumeration of what data it returns (brands, portals, personas, apps, providers) which supplements the annotations. However, it doesn't describe the return structure or response format, so it adds some but not rich behavioral context.

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 wasted words. First sentence states the return content, second gives the usage directive. Everything earns its place and is front-loaded with the purpose.

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 parameterless read-only discovery tool, the description is quite complete: it names every data category returned and states the usage context. The only gap is the absence of an output schema and no description of the response shape, which for a data-dictionary tool could matter, but the enumerated categories largely compensate.

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 0 parameters and schema coverage is 100% (there are no params to document). For a parameterless tool, description need not explain params. The description usefully enumerates the categories of data returned, which compensates for the lack of an output 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?

Clear verb+resource: 'Return tenant data to fill argument values'. Names the specific kinds of data (brands, portals, personas, installed apps with widget keys, connected providers) and states its purpose (discover valid ids before creating/editing). Distinguishes well from siblings like kilango_get_meta or kilango_list_portals.

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 says when to use: 'to fill argument values' and 'Use this to discover valid ids before creating or editing.' This clearly signals it's a discovery/lookup tool for id resolution, distinct from the listing and mutation siblings. The 'before creating or editing' phrasing gives a clear usage window.

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