ic_get_features

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

Annotations only declare readOnlyHint=true, so the description carries the burden of explaining behavior. It clearly states that false means the feature is disabled, while true or missing means available, and describes the per-enrollment structure. This adds meaningful interpretive behavior beyond the annotation with no contradiction.

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, each with a distinct job: what the tool lists, how to interpret the flag values, and when the LLM should use it directly. No filler or 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?

With no output schema, the description appropriately supplies return semantics: enrollments have features objects, values are booleans, and missing means available. The detailed view parameter schema covers projection behavior. It does not mention errors or edge cases, but for a simple read-only capability lookup this is largely sufficient.

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 67% (view and studentId are documented), so the baseline is 3. The description adds the per-enrollment context that helps explain studentId and references the district, but it does not document the district parameter format or otherwise compensate for the uncovered parameter.

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?

Opens with a specific verb and resource: 'List the district's displayOptions feature-flag allow-list for each of a student's enrollments.' It explains the data model (map of ~90 flags to booleans) and distinguishes itself from sibling data-list tools by noting it is exposed for capability questions rather than direct student data retrieval.

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 gives clear usage context: the tool is used internally to short-circuit disabled features, but exposed so the LLM can answer capability questions directly. This implies when to call it, though it does not explicitly name alternatives or define 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.