m_function_help

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

The annotation readOnlyHint=true already declares this as a read-only operation, so the description need not repeat that. It adds behavioral context by explaining what results to expect: signatures and descriptions for exact names, member lists for namespaces, and search results for keywords. It does not discuss pagination or the limit parameter's effect, but these are minor given the read-only nature.

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 sentence that front-loads the purpose and includes concrete examples. Every clause adds value, and it avoids redundancy. It is concise yet comprehensive for the tool's complexity.

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?

Given the tool's complexity (850+ members, multiple lookup modes) and the absence of an output schema, the description covers all necessary usage aspects: how to query by exact name, namespace, or keywords. It even includes examples. The only omission is the limit parameter's behavior, but that is a minor detail that can be inferred from its default. Overall, it is complete for an agent to call the tool 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 explain the parameters. It thoroughly explains the primary parameter name_or_search with examples of exact name, namespace, and search words. However, it does not explicitly describe the limit parameter, which controls result count, leaving its meaning to inference. The main parameter is well-covered, but the secondary one is not.

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 clear purpose: look up the M standard library. It specifies three distinct query modes (exact name, namespace, search words) with concrete examples. This distinguishes it from all sibling tools, none of which perform library lookup.

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 explicitly tells when to use the tool: 'Use it instead of guessing signatures.' It also describes the three usage patterns (exact name, namespace, or search words), giving an agent clear guidance on how to phrase the input. No alternative tool is mentioned, but since it is the only library lookup tool, this is sufficient.

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