lognexus_statusInspect the current Git branch, repository status, active issue, routing mode, and recommended model tier to guide AI coding agent context.
Inspect the current Git branch, whether the directory is a Git repository, the active issue, the routing mode and the recommended model tier.
| 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?
No annotations exist, so the description carries the full burden. It implicitly conveys a read-only inspection and enumerates the returned fields, which is genuinely useful, but never explicitly states 'no side effects', whether it touches the filesystem/network, or what the response shape looks like. Adequate but short of what an unannotated tool warrants.
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?
One sentence, front-loaded with the verb and no filler. The list is long but each item is a distinct returned datum, so little is wasted.
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 must convey return content, and it does so by naming five concrete fields. Missing only the explicit read-only guarantee and any note on failure when the directory is not a Git repository.
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?
The tool takes zero parameters, so the baseline is 4. The description instead spends its words itemizing the inspection targets, which is the useful analog for a no-arg tool.
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?
Starts with a specific verb ('Inspect') and enumerates exactly which fields are surfaced: Git branch, repo detection, active issue, routing mode, model tier. This is far more concrete than a name restatement. It does not, however, contrast itself with the similarly named sibling lognexus_state_get, so an agent has no signal on how they differ.
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?
There is no statement of when to call this versus lognexus_state_get, lognexus_state_sync, or lognexus_timeline, which all read adjacent state. Usage must be inferred entirely from the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.