get_staff_member

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

With no annotations provided, the description must carry behavioral disclosure. It does say returns structured data plus an inline profile photo when available, adding conditional return behavior. However, it omits permissions, authentication requirements, and what happens if the user is not found; these are notable gaps for a non-annotated read tool.

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 short, to-the-point, and the most relevant information (purpose, then prerequisite, then return behavior) appears near the start. The Args block complement the schema, but it adds some redundancy; otherwise no sentence is wasted. It is slightly above average but not perfectly compact.

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?

The tool is a simple two-parameter getter, and the description gives a workflow to obtain user_id, states the fields returned (email, photo, office), and caveats the profile photo as conditionally present. With no output schema, it explains enough for basic usage. Shortfalls are error or not-found behavior and permission assumptions, though for a read-only detail endpoint this stays primarily complete.

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 Args block supplies the only parameter context. It gives terse meaning '('School ID', 'Staff member's user ID (from get_directory results)') and the user_id provenance hint is genuinely useful, but it restates the parameter names without additional constraints, defaults, or allowed values.

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?

Description states a clear verb ('Get') and a specific resource ('detailed info for a specific staff member') including what details are returned (email, photo, office hours). It is distinct from siblings like list_staff and get_directory because it targets one member's full detail rather than a list or a directory entry.

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 instructs the agent to call get_directory first to find the user_id, then use this tool, which is clear workflow guidance. It does not state when not to use the tool or mention list_staff as an alternative for bulk access, so it falls just short of full when/when-not coverage.

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