Pack project context

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

Annotations already flag readOnlyHint=true and destructiveHint=false. The description adds the non-obvious behavior that a stored pack id is tied to the server process lifetime and becomes invalid on restart, which is valuable for an agent. It also implies a pack is stored in memory without contradicting the read-only 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?

Exactly two sentences. The first is a terse verb+object opening, and the second captures a critical lifetime constraint. Every word earns its place with no 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?

With 13 optional parameters and no output schema, an agent needs more orientation than this description provides. It never explicitly says the tool returns a pack id (only implies it), gives no example call shape, and does not explain what 'redacted' means for selection. The lifetime hint is useful, but the overall context is thin for such a complex tool.

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 85%, so the input schema already documents most parameters. The tool description adds no parameter-level meaning, such as which parameters are needed or how they interact, so it neither compensates for nor detracts from the schema's coverage.

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 opening sentence states a specific action ('Build an exact redacted DevProjex context export') with a clear resource, and the name pack_context helps distinguish it from siblings like read_pack and get_tree. However, it does not explicitly differentiate from those tools, and 'DevProjex context export' leaves some meaning implicit.

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 gives one explicit usage signal: pack ids expire at process exit, so call pack_context again after restart. It does not, however, state when to prefer pack_context over read_pack, get_tree, or search_project, so guidance beyond the lifetime rule is implied rather than explicit.

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