efm_list_class_resources

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

With no annotations provided, the description carries the behavioral burden. It adds meaningful context: the resources are 'currently assigned' and are synced to agents 'on its next heartbeat,' which clarifies that this is a read-only snapshot tied to a synchronization cycle. It stops short of explicitly stating no side effects or auth requirements, but the verb 'list' plus the snapshot wording make the behavior reasonably transparent.

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 a single concise sentence with a dash-delimited clarification. Every phrase carries meaning, the core subject is front-loaded, and there is no redundant or filler text.

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 simple one-parameter tool with an output schema, the description covers the core semantics well. However, it leaves the agent_class parameter under-specified and does not mention how to discover valid class identifiers. Given the schema and output schema already exist, this missing parameter guidance is the main completeness 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?

The input schema has one parameter, agent_class, with no schema-level description, and schema description coverage is 0%. The description mentions 'one agent class' broadly but does not explain what agent_class values look like, where to obtain them, or any format constraints. This is a real gap for an agent trying to populate the only required 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?

The description uses a clear verb-resource pair ('list class resources') and then defines exactly what those resources are: assets/extensions EFM syncs to every agent in that class on its next heartbeat. This makes the tool's scope concrete and semantically distinguishable from siblings like efm_list_agent_classes and efm_list_resources.

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: call this when you need resources assigned to a single agent class. It does not explicitly state when to prefer this over efm_list_resources or other sibling tools, nor does it provide exclusions. Context is present, but alternative routing is left to inference.

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