List Manpower Logs

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

Beyond the annotations (readOnlyHint=true), the description adds significant behavioral context: it explicitly states 'Read-only — it changes nothing in Procore', explains default project_id behavior via procore_set_config, and details common error statuses (401, 403, 404). It also mentions pagination reporting and return format, which is valuable for an agent. No contradiction with annotations.

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 front-loaded with the core purpose, then flows through filtering, defaults, return type, error behavior, and API location. Every sentence contributes functional information, with no fluff, and the structure makes it easy to scan.

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 compensates by describing the JSON array return and pagination details. It covers filters (via link), date behavior, default project_id, read-only safety, and error handling. Given the 12-parameter complexity, this is thorough and provides an agent with enough context to invoke 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 coverage is 100%, so the baseline is 3. The description enriches understanding by clarifying that if no date parameters are provided, only current-date logs are returned, and that project_id defaults to the configured value when omitted. It also explains page/per_page pagination semantics, which adds value beyond the raw 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?

The description clearly states the tool returns all approved Manpower Logs for the current date, with a specific use case for discovery and ID lookup. However, it does not explicitly distinguish this from sibling tools like list_manpower_logs_contact_options or list_manpower_logs_vendor_options, so it loses the fifth point.

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 provides a clear use case (discover logs, look up an id) and notes that date parameters can filter results, with a link to documentation. It does not explicitly mention when to use alternatives or when not to use this tool, but the inclusion of a 'Use this to...' statement gives practical guidance.

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