Show Time And Material Entry

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by explicitly stating 'Read-only — it changes nothing in Procore.' It also discloses the return shape ('a single JSON object') and provides concrete error semantics: failures come as an error payload with HTTP status, and it lists common 401, 403, and 404 scenarios. This is exactly the kind of behavioral context agents need, and it does not contradict any annotation.

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 about five sentences long and every sentence earns its place. It is front-loaded with the core purpose, then covers usage context, default behavior, id resolution, return type, read-only nature, error handling, and the API endpoint. There is no fluff or redundancy; it is a dense but well-organized paragraph.

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 read-only tool with two path parameters, this description is exceptionally complete. It covers what the tool does, when to use it, how to obtain the necessary id, the default for project_id, the return format, safety (read-only), error outcomes, and the underlying API endpoint. No output schema is provided, but the description's statement that it returns a single JSON object is sufficient for this resource. The agent has everything it needs to invoke this 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 100% (both project_id and id have descriptions). The description adds meaningful semantics beyond the schema: it explains that project_id defaults to the value set by procore_set_config when omitted, and that id must identify an existing parent record and be resolved with a list tool first. This extra context helps the agent understand how to supply these parameters correctly, moving the score above the baseline of 3.

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 opens with a specific verb and resource: 'Return Time And Material Entry detailed information.' It clearly states the tool returns a single JSON object for a known time and material entry, and distinguishes itself from list tools by saying 'Use this when you already know which time and material entry you want and need its full field set.' This makes the purpose unmistakable and differentiates it from the many sibling list/create/update/delete tools.

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 clear when-to-use guidance: 'Use this when you already know which time and material entry you want.' It also instructs the agent to resolve the id using 'the matching list tool first' and explains the project_id default behavior. It does not explicitly name a sibling list tool, but the reference to a 'matching list tool' is sufficient, along with the context of needing a specific record. This is strong usage guidance, though not quite as explicit as naming the exact alternative tool.

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