git_log

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

No annotations are provided, so the description carries full burdens. It states 'Free local I/O' suggesting a read-only, local operation, but does not explicitly say whether modifications occur or what auth/session requirements exist. The tool actually requires a project and session_token (per schema descriptions), but the tool description omits these behavioral constraints entirely, leaving the agent unaware of setup prerequisites.

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, front-loaded sentence with no redundancy. It conveys the core purpose immediately and wastes no words. It is appropriately sized for a simple read tool, though the trade-off is a lack of detail elsewhere.

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 has 4 parameters, two of which (project, session_token) are necessary for project tools, and no output schema, the description is incomplete. It does not mention the requirement to pass session_token or the need for the project to be armed. The description also does not specify return format or edge cases. It heavily relies on schema descriptions for critical operational detail, making the overall context inadequate.

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%, so each parameter (path, count, project, session_token) is documented. The description adds the 'project root' context, which implies the path is relative to root, but does not elaborate on parameter interactions. It adds marginal value beyond the schema, so the baseline of 3 is appropriate.

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 what the tool does: 'Recent commit history (oneline) of a project root.' It uses a specific verb (get/recent) and resource (commit history), and distinguishes from sibling tools like git_status (status) and git_diff (diff) by focusing on log at project root. The 'oneline' format is also specified.

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 no explicit guidance on when to use this tool versus alternatives. It mentions 'Free local I/O,' which hints at low cost, but does not compare against git_status, git_diff, or other read tools. Sibling tools are numerous, but the description fails to indicate scenarios or exclusions.

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