Antigravity MCP Orchestrator

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

With no annotations, the description carries the full burden. It usefully discloses where files are written (.agents/rules/*.md or GEMINI.md), which is real behavioral context, but says nothing about overwrite behavior, collision with existing rules, or required permissions for global scope.

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?

A single front-loaded sentence that identifies the action, the resource, and the write destinations 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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers the 'what' and 'where' but omits overwrite semantics and what a successful call produces. Adequate but with a clear gap for a file-creating operation.

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 coverage is 100% and both enums (scope, trigger) are documented in the schema itself. The description only echoes the file targets already implied by the filename examples, adding no new parameter meaning.

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?

Specific verb ('Creates') plus a well-defined resource ('an Antigravity rule') and concrete write targets (.agents/rules/*.md or GEMINI.md). It is distinguishable from siblings like list_rules/get_rule, though it does not explicitly contrast itself with create_workspace_skill.

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?

No when-to-use guidance, no conditions for choosing between workspace vs global, and no mention of an alternative tool. The scope enum in the schema conveys the choice mechanically, but the description offers no decision context.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully names the created artifact (SKILL.md with YAML frontmatter), but says nothing about overwrite/conflict behavior if the skill exists, required permissions, or any destructive side effects of a create operation.

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?

A single tight sentence with the key action and artifact front-loaded. No wasted words, though the parenthetical is the only extra detail provided.

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 4-parameter mutation tool with no annotations and no output schema, the description is thin. It omits failure modes, overwrite behavior, and scope-dependent prerequisites, leaving meaningful gaps an agent would need before invoking it 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% and each parameter (name, scope, description, instructions) is well documented in the schema itself. The description adds essentially no parameter detail beyond what is already structured, so baseline 3 applies.

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?

States a specific verb ('Scaffolds') and resource ('new Antigravity skill') with a concrete artifact ('SKILL.md with YAML frontmatter'). It is clearly distinguishable from read siblings like list_skills and get_skill, though it does not explicitly contrast with create_workspace_rule.

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?

Provides no when-to-use guidance, no prerequisites (e.g., whether an active workspace is needed for the 'workspace' scope), and no mention of alternatives among the sibling tools. The agent must infer all usage context.

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

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

With no annotations, the description carries the full behavioral burden. It mentions captured output, but does not disclose side effects, permissions, sandboxing, destructive potential, or workspace boundary constraints, which matter greatly for arbitrary shell execution.

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?

It is a single, front-loaded sentence with no wasted words. The core action and scope are presented immediately.

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 high-risk shell execution tool with no annotations and no output schema, the description states what outputs are captured but omits safety boundaries, permission requirements, and execution constraints. The schema covers parameters, but the description is too thin for the tool's complexity.

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 the schema already documents command, cwd, and timeout. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 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 states a specific verb (executes), resource (shell command), and scope (directly in the Antigravity workspace). It also describes the captured outputs, making it clear how this tool differs from the list/get/create siblings.

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?

It provides no guidance on when to use this tool versus alternatives, when not to use it, or what prerequisites exist. The workspace context is implied, but there is no explicit usage condition or warning.

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

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

With no annotations provided, the description carries the full burden. It implies a safe read-only operation via 'Returns' and 'real-time status' and discloses the categories of data returned, but says nothing about permissions, freshness guarantees, or whether the call has any side effects or rate limits.

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?

A single front-loaded sentence with no filler, and the returned content is listed immediately after the verb so the agent grasps scope at a glance. The enumeration is compact but complete.

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 zero-parameter, annotation-free tool with no output schema, the description compensates well by naming the data categories returned. An agent would still lack specifics on the shape of the response and any auth requirements, but the core is covered.

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, which sets the baseline at 4. There are no input arguments whose semantics need explanation, so the description has nothing to compensate for.

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?

States a specific verb ('Returns') and resource ('real-time status of Google Antigravity IDE') and enumerates the returned content: workspace paths, config locations, counts, and environment. It is clearly distinct from siblings like list_skills or list_known_workspaces, though it does not explicitly name any sibling to differentiate itself.

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 explicit when-to-use or when-not-to-use guidance, nor any named alternative. Usage is implied by the tool's nature as a zero-parameter status snapshot, which an agent can route to without ambiguity, but nothing in the text confirms that intent.

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

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

With no annotations, the description carries the full burden. It does disclose the kinds of events returned (steps, prompts, thoughts, tool invocations) and implies a read-only inspection, but says nothing about ordering, pagination behavior tied to limit, or what the response structure looks like despite there being no output schema.

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?

A single, front-loaded sentence with no filler; the resource and the payoff are stated immediately. It is efficient, though it could have used the remaining space to state usage conditions.

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 two-parameter, annotation-free tool with no output schema, the description covers what the transcript contains but omits return shape, ordering, and how limit interacts with the transcript window. Adequate but with clear gaps for an agent deciding how to call it.

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 limit and conversation_id are already documented in the schema, and the description adds nothing about either (e.g. the default-to-active-conversation behavior only appears in the schema). Baseline 3 applies when the schema does the heavy lifting.

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?

Names a specific verb ("Inspects") and a specific resource ("the execution transcript of an Antigravity conversation"), plus enumerates the content it exposes (agent steps, user prompts, thoughts, tool invocations). It is clearly distinct from a listing tool like list_conversations, but never explicitly contrasts itself with any sibling.

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 phrase "allowing Gemini to review recent agent steps" implies the review/debugging context in which an agent would reach for it, but there is no explicit when-to-use, no exclusion, and no mention of the sibling list_conversations as an alternative for enumerating conversations.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the payload shape (configuration, manifest metadata, rules, MCP definitions), which is useful for a read tool, but says nothing about permissions, behavior for an unknown plugin name, or any failure mode.

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?

A single front-loaded sentence with no filler; the returned-content list is the only elaboration and it earns its place. Slightly list-heavy but appropriately sized for one parameter.

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 one-parameter read tool with no annotations and no output schema, the description compensates by spelling out what the response contains. The remaining gap is only the absence of error/edge-case behavior, which is minor here.

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 coverage is 100% and there is only one parameter, so the baseline is 3. The description adds real value by supplying concrete name examples ('cursor-team-kit', 'ponytail', 'pstack') that clarify the expected identifier format beyond the schema's terse 'folder name of the plugin'.

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?

States a specific verb (gets) and resource (a specific plugin) and enumerates exactly what is retrieved: full configuration, manifest metadata, rules, and MCP definitions. The singular 'a specific plugin' cleanly distinguishes it from the sibling list_plugins without needing to name it.

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 explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as list_plugins or get_rule. The only signal is 'a specific plugin', which implies the caller must already know the name, but that inference is left entirely to the reader.

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

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

No annotations are provided, so the description carries the burden. It discloses that the operation returns 'full content and triggers' of a rule and that it is a lookup by name or path, but says nothing about error behavior when the rule is not found or about permissions. Adequate but incomplete for a tool with zero annotation coverage.

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?

A single front-loaded sentence with no wasted words; the verb and resource come first. It is appropriately sized, though 'triggers' is introduced without elaboration.

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 single-parameter read tool, the description covers what it does and what it returns. With no output schema, more detail on the returned rule structure (e.g. what 'triggers' are) would help, but nothing critical to invocation is missing.

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 coverage is 100% with a single well-described parameter that already gives examples ('GEMINI.md', 'AGENTS.md', custom rule name). The description's 'by name or path' adds little beyond what the schema documents, so the baseline of 3 applies.

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?

States a specific verb ('Reads') and resource ('an Antigravity rule file'), plus a distinguishing scope detail ('full content and triggers') that separates it from the sibling list_rules. It stops short of explicitly naming list_rules or other alternatives, but the read-vs-list distinction is inferable.

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 when-to-use guidance, no exclusions, and no mention of alternatives such as list_rules for discovery or create_workspace_rule for creation. Usage is only implied by the verb.

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

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

With no annotations, the description carries full behavioral burden. It discloses the payload shape (complete instructions plus scripts/references/examples), which usefully signals a potentially large read-only response, but says nothing about permissions, unknown-skill-name behavior, or output size limits.

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?

A single front-loaded sentence beginning with the action verb, with the returned content grouped at the end. Efficient, though slightly dense in its enumeration of artifacts.

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 and no annotations, the description compensates by enumerating the returned content and identifying the tool as a details retriever. Missing only error/precondition context for an invalid skill name.

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% and the single skill_name parameter is well documented with real examples ('bento', 'deslop'). The description adds only the notion of "a specific skill" as the lookup key, so it does not meaningfully exceed what the schema already provides.

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?

States a specific verb ("Retrieves") plus a specific resource ("a specific Antigravity skill") and enumerates what comes back (SKILL.md, frontmatter, procedures, scripts/references/examples). This clearly distinguishes a single-skill fetch from the sibling list_skills/search_skills, but it never names those alternatives explicitly.

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 phrase "for a specific Antigravity skill" implies this is the detail-fetch step after discovery via list_skills/search_skills, but no when-to-use, when-not, or prerequisite is stated. Guidance is inferable rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only enumeration and discloses the storage scope, but says nothing about ordering, pagination, result limits, or what happens when a conversation has no artifacts. For a simple listing tool this is adequate but thin.

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 front-loaded sentence with the operation and its scope stated first and the artifact examples in a compact parenthetical. No filler, no repetition of the tool name as a standalone tautology.

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 one-param read tool with no output schema, the description covers what exists but not what comes back — whether the result is a list of paths, IDs, or summaries, which matters because no output schema defines the shape. It is minimally sufficient rather than complete.

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 single optional conversation_id parameter is fully documented in the schema at 100% coverage, including its default-to-most-recent behavior. The description adds no extra meaning about the parameter, which is the expected baseline when the schema does all the work.

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?

States a specific verb (Lists) and resource (generated artifacts), and enumerates what counts as an artifact: plans, code diffs, reports, diagrams. It scopes the operation to the 'conversation brain directory', which narrows it against siblings, but it never names read_artifact, the obvious counterpart for retrieving artifact contents.

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 when-to-use or when-not-to-use guidance. The agent is left to infer that this is the discovery step preceding read_artifact, and nothing states that other siblings (list_conversations, list_skills) operate on different resource types.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the data source ('brain store') and the fields returned, but says nothing about how many conversations 'recent' covers, ordering, pagination, or whether results are scoped to the active workspace.

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?

A single front-loaded sentence with no filler: verb, resource, returned fields, and source are all packed in. Nothing to trim and nothing buried.

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 does double duty by naming the returned fields, which is helpful. However, the undefined scope of 'recent', absent limit/pagination behavior, and no mention of how it relates to get_conversation_transcript leave gaps for an agent deciding whether this is the right call.

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 rule sets the baseline at 4. The description adds no parameter detail, but none is needed since there is nothing to configure and the schema coverage is 100%.

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?

States a specific verb ('Lists') and resource ('Antigravity IDE conversations') and enumerates the returned fields (timestamps, artifact counts, status). It is clearly distinguishable from sibling get_conversation_transcript, though it never names that sibling to make the boundary explicit.

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 when-to-use or when-not-to-use guidance and no mention of alternatives such as get_conversation_transcript. Only the word 'recent' hints at intended usage, leaving routing to the agent's inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the result includes an active/selected indicator, but says nothing about scope of 'known' (active vs. archived), ordering, permissions, or rate limits. Adequate but thin for a zero-signal tool.

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?

A single front-loaded sentence with the key noun (workspaces) early. 'Discovers and lists' is mildly redundant, costing a fraction of a point, but there is 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?

For a no-param, no-annotation, no-output-schema read tool, the description covers what it returns (known workspaces plus the active one). It would be fully complete with a note on whether inactive/archived workspaces are included, but the gap is minor.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. The empty schema and additionalProperties:false match the described no-argument behavior.

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 gives a specific verb (discovers/lists) and resource (development projects and workspaces) and adds a distinguishing detail — it shows which is currently active. This separates it from the mutating sibling set_active_workspace, though it never names that sibling explicitly.

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 implied rather than stated: an agent can infer this is the read step that should precede set_active_workspace, but there is no explicit when-to-use guidance, no exclusions, and no named alternative. Minimum viable for a trivial list tool.

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

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

With no annotations and no output schema, the description carries the full burden, and it does disclose the read target (~/.gemini/config/plugins) and the returned content (manifests, descriptions, versions, skills, subagents). It does not, however, state that the operation is side-effect free or read-only, nor whether results are paginated or cached.

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?

A single front-loaded sentence leading with the verb and resource, followed by an enumeration of contents. Slightly list-heavy at the tail, but every clause adds information rather than padding.

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 zero-parameter read-only listing with no output schema, the description explains what comes back well enough to set expectations. Minor gap: no statement of behavior for empty results or how workspace vs. global entries are merged or labeled.

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 also clarifies the scope of enumeration (workspace plus global configuration directory), which is the only 'parameter-like' semantic an agent could misread.

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?

States a specific verb and resource ('Lists all installed Antigravity plugins') and adds scope ('across workspace and global configurations'). An agent can distinguish it from get_plugin_details as the bulk-enumeration variant, though the description never names that sibling to make the contrast explicit.

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 when-to-use guidance and no mention of alternatives such as get_plugin_details, get_antigravity_status, or list_skills. The only inference available is that 'Lists all' implies bulk retrieval, which the agent must derive on its own.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the scan scope (workspace vs. global config paths), which is real behavioral context, but it never states that the operation is read-only, whether results are paginated, or how results are ordered — all relevant for a discovery tool.

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?

A single front-loaded sentence with the verb and scope up front and the file globs as concrete detail. No filler, no redundancy.

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 zero-parameter, no-annotation, no-output-schema listing tool, the key thing an agent needs — what gets scanned — is present. The remaining gap is the shape of the returned rule list, which the tool description could have sketched briefly.

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. There are no arguments whose meaning the description could add or omit, and schema coverage is 100%.

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?

States a specific verb ('discovers') and resource ('all active rules'), plus the exact sources it scans (GEMINI.md, AGENTS.md, .agents/rules/*.md, ~/.gemini/config/rules/*.md). The scope word 'all' clearly separates it from the singular sibling get_rule.

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 implied by 'discovers all active rules', but there is no explicit when-to-use guidance, no mention of when to prefer get_rule instead, and no stated prerequisites or exclusions. An agent can infer the intent but must guess at the sibling boundary.

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

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

No annotations are provided, so the description carries the full burden. It implies a read operation via 'Discovers and lists' but never confirms read-only safety, pagination behavior, or result size – meaningful omissions for a listing tool with zero annotation coverage.

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 tight sentences with the action front-loaded and the filter options following. Slightly redundant in re-enumerating the scope enum that the schema already lists, but 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?

For a simple two-parameter, zero-required list tool, the description covers what it does and how to filter, which is adequate. Since no output schema exists, it could have described the shape of returned skills or result limits, leaving a minor gap.

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 both parameters are already documented. The description roughly restates the scope enum values and mentions plugin-name filtering, adding marginal value but no syntax or format detail beyond the schema.

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?

States a specific verb and resource ('Discovers and lists all skills') scoped to Antigravity agents. It is clearly distinguishable from the singular get_skill, but it never names or contrasts with the close sibling search_skills, so sibling differentiation is only partial.

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 implies a discovery/listing use case but offers no explicit when-to-use guidance and no exclusions. With a near-identical sibling (search_skills) present, the absence of routing guidance is a real gap.

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

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

With no annotations, the description carries the full disclosure burden. It says the tool 'formulates' a blueprint but is ambiguous about whether it plans or actually executes ('orchestrate' in the name implies action), and it discloses nothing about permissions, side effects, or reversibility. For a tool with an execution-sounding name and zero annotation coverage, this is a notable gap.

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?

A single front-loaded sentence with no filler. It is efficient, though the closing 'and steps' is slightly redundant given the blueprint framing.

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?

There is no output schema, so the description should indicate what the blueprint looks like when returned, and it does not. Combined with absent annotations and ambiguity about whether it executes anything, the definition leaves important gaps for an apparently complex planning 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 100%, so both parameters (task, preferred_aesthetic) are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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?

States a specific verb ('Formulates') and a concrete deliverable ('end-to-end execution blueprint'), and enumerates what the blueprint contains (skills, rules, steps). It is distinguishable from the CRUD/list siblings like list_skills or list_rules, though it never explicitly contrasts itself with them.

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 when-to-use guidance, no prerequisite conditions, and no alternatives named. An agent must infer that this is a planning entry point rather than a lookup, and nothing tells it when to prefer this over list_skills/search_skills.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It signals a read-only operation, but does not disclose permissions, error behavior, return format, or any limits, leaving important context unspecified.

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?

A single, front-loaded sentence with no wasted words. It states the operation and scope directly, making it efficient and easy to parse.

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 low-complexity read tool with full schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should clarify return behavior and when it is preferred over list_artifacts; those gaps keep it from being fully complete.

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 coverage is 100%, so both parameters are fully documented in the schema. The description adds no meaning beyond the schema and does not mention conversation_id, but baseline 3 is appropriate when the schema already covers parameter details.

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?

States a specific verb ('Reads') and resource ('artifact file'), and specifies the content type as markdown or code. It distinguishes itself from list_artifacts by focusing on a specific file, though it does not explicitly name the sibling.

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 phrase 'specific artifact file' implies usage after an artifact is known, but there is no explicit guidance on when to use this tool versus list_artifacts or other retrieval tools. It lacks when-not-to-use or alternative recommendations.

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

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

No annotations are provided, so the description carries the full burden, but it does disclose useful behavior: the search spans both skill names and descriptions, and accepts free-text intent. It still omits result behavior (ranking, matching semantics, whether it returns full skill content or just references), which matters for a search tool with no output schema.

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?

A single front-loaded sentence that packs verb, resource, search scope, method, and purpose with no filler. Nothing is repeated or 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?

For a one-parameter, non-destructive search tool with complete schema coverage, the description covers what it searches and why. It could say more about result shape or how the search differs from browsing tools, but nothing essential to calling it correctly is missing.

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 coverage is 100% and the single query parameter is already documented with examples in the schema. The description restates that it accepts natural language or keywords but adds no format constraints or guidance beyond the schema. Baseline 3 is appropriate when structured data does the work.

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 gives a specific verb (searches), resource (skills), method (natural language query or keywords), and target (find the right procedure for a task). It implicitly distinguishes itself from siblings like list_skills and get_skill by emphasizing natural-language search, though it never names them.

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 phrase 'to find the right procedure for a task' implies a use case, and 'natural language query or keywords' suggests the input style. However, there is no explicit when-to-use versus when-to-use list_skills/get_skill, and no alternatives or exclusions are named.

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

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

With no annotations, the description carries the full burden and does disclose the key behavioral trait: this is a stateful mutation whose effect applies to all subsequent commands, skills, and rules without a server restart. It omits error behavior for an invalid path and whether the switch persists, but the critical session-wide side effect is explicit.

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 sentences, front-loaded with the action and followed by the consequence, with no filler. Every clause carries information.

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 one-parameter, no-output-schema tool, the description covers purpose and the main runtime consequence. It could still note failure modes for an invalid path or how to enumerate known workspaces, but nothing essential for correct invocation is missing.

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?

There is a single parameter with 100% schema description coverage including a concrete path example, so the schema already does the work. The description adds no further meaning about accepted path forms, absolute vs relative, or validation.

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?

States a specific verb and resource ('switches the active workspace') plus the target scope ('another folder/repository on the user's machine') and the timing ('at runtime'). This clearly separates it from read-only siblings like list_known_workspaces, so an agent can pick it without inspecting schemas.

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 implies when the tool is relevant ('switches the active workspace... at runtime') and describes the downstream effect, but never states when NOT to use it or points to list_known_workspaces as the way to discover valid targets. Usage is inferable but not spelled out.

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