Generates a schedule-risk brief that scores project risk, identifies discipline hotspots, and lists the worst overdue issues with supporting documents and scoring method.
Schedule-risk brief for a project: score, discipline hotspots and the worst overdue issues with their supporting documents. Includes the scoring method.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, so the safety bar is low. The description adds real value beyond that by disclosing the response contents (ranked hotspots, worst overdue issues, supporting documents, and the scoring methodology), which tells the agent how to interpret and trust the output.
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?
Two compact sentences, front-loaded with the deliverable and its payload. The trailing clause about the scoring method is a small but genuinely useful addition rather than filler.
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?
An output schema exists, so return-value detail is partly covered elsewhere, and annotations handle the safety profile. What's missing is scoping the brief itself: no time window for 'overdue', no statement of how many 'worst' issues are returned, and no note on whether an invalid project_id errors or returns an empty brief.
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% and the description says nothing about project_id — not its format, nor that it corresponds to an ID returned by list_projects. With a single required parameter left entirely undocumented, the description fails to compensate for the schema gap.
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 names a concrete deliverable (a schedule-risk brief for a project) and enumerates its contents: score, discipline hotspots, worst overdue issues with supporting documents, and the scoring method. This clearly separates it from the granular siblings like search_issues and get_issue, though it never explicitly states the relationship to those 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?
Usage is only implied: an agent can infer this is the aggregate-overview tool rather than per-issue lookups, but there is no explicit 'use this when you want X instead of paging through search_issues' guidance. No prerequisites (e.g., that project_id must come from list_projects) or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.