gc_mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
There is heavy overlap between many tools: gc_conversation, gc_agent_conversation, gc_aden, gc_peer_conversation, and gc_peer all provide nearly identical spawn/turn/get/list/delete chat sessions — an agent could easily misselect among them. gc_docs and gc_recall both search knowledge; gc_project_status is literally an alias for gc_ticker/get; gc_peer is a legacy alias for gc_peer_conversation. Several tools (gc_workflow vs gc_workflow_watch vs gc_tool_call) also blur boundaries.
Naming Consistency3/5
Most tools follow the gc_* prefix with snake_case, which provides surface consistency. However, the action-based dispatch convention means many tool names don't embed the verb; instead each gc_ tool takes an 'action' parameter (list, create, get, etc.), so the naming is more resource-oriented than verb_noun. There are also clear outliers like davinci_resolve, devonthink, gh_issues, and gh_issue_view which break the gc_ prefix pattern, and legacy aliases (gc_peer, gc_project_status) that don't follow the primary naming scheme.
Tool Count1/5
At 63 tools this is far beyond the well-scoped range and will create significant selection burden and confusion for agents. Many tools cover adjacent concerns that could be consolidated (six conversation/chat tools, multiple alias tools, schedule vs dispatch vs workflow overlapping). The count reflects a sprawling monolithic daemon rather than a focused server purpose, making it very heavy for any agent to navigate.
Completeness3/5
The server covers an extraordinarily broad domain spanning memory, workflows, scheduling, dispatch, finances, publishing, project management, and even video editing — yet gaps exist within each sub-area (e.g., only one gh_issue_view tool among several gh_issue_* tools, no gh PR coverage despite gh_issue_view). Some sub-domains feel complete (workflows have full CRUD+ops) while others are fragmented. The scope itself makes 'complete' coverage nearly impossible.
Average 3.2/5 across 60 of 63 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description discloses no behavioral traits whatsoever — no mutation safety, no side effects, no prerequisites, no idempotency, nothing. The phrase 'Strategic vector tracking' plus 31 action names gives no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (a single list of action names). However, this isn't genuine conciseness — it's under-specification masquerading as brevity. There's no editorial judgment about what merits explanation; the entire payload is a bare enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool with 23 parameters, 31 action variants, and no output schema. The description provides virtually no context: no action semantics, no parameter-action mappings, no return value expectations. For a tool of this complexity, a minimal viable description would need far more than an action-name list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the schema only describes parameters at the level of 'Vector name', 'Max results', 'Notes' — mostly one-word field labels. The description adds literally nothing about parameter semantics because it only lists action names without mapping any to parameters. With 23 parameters and 31 actions, the relationship between which action uses which parameters is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a list of 31 action names with no explanation of what the tool actually does. 'Strategic vector tracking — the Fosferon evaluation model' is vague jargon with no verb+resource clarity. It gives no sense of what operations are possible or what the tool's core purpose is beyond the opaque 'Fosferon evaluation model' phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool vs alternatives. The description lists 31 actions with no explanations, no context for selection, and no when-to-use or when-not-to-use guidance. It doesn't reference any sibling tools or clarify the domain boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions attribution repair, backfills, and review decisions (which imply mutating or destructive operations) but gives no indication of side effects, prerequisites, or consequences. None of the 12 actions have any behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense block that lists action names with no grouping, hierarchy, or prioritization. While technically short, the conciseness here is under-specification — it saves words by omitting essential explanatory content. The information density is low because action names without context communicate almost nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-action tool (12 distinct operations) with no output schema and no annotations, yet the description provides no per-action detail, return behavior, error conditions, or action-to-parameter mapping. A tool this complex with this many operations needs substantial per-action documentation, and the single paragraph is wholly inadequate for agent usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema description coverage is 100%, the description doesn't map any parameters to actions or explain their role beyond what the schema says. The connection between parameters like 'review_id', 'note', 'decision' and the 'apply_review_decision' action is only inferable, not stated. The description adds minimal value beyond the schema's one-line parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists 12 action names without explaining what any of them does. 'Session ingestion ops — scanner status, attribution repair, manual scans, and knowledge backlog control' is too vague to convey the tool's purpose, and the actions like 'review_attributions', 'apply_review_decision', 'work_item_summary' have no explanation. It is essentially a menu of command names that doesn't tell the agent what each does or 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.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings (gc_recall, gc_retain, gc_reflect, etc.) or when individual actions are appropriate. The description provides no context about which action to choose for a given task, leaving the agent to guess from bare action names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It provides none. The tool clearly has side effects (add_endpoint, remove_endpoint, seed_rules, backfill_senders are mutating operations), yet there is no mention of destructive potential, authentication requirements, or what the operations change. Given zero annotation coverage and zero behavioral disclosure in the text, this is a serious gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence followed by a comma-separated enumeration of 19 action names. While the length is technically short, it is poorly structured: the 19-action list is undifferentiated and buried, and the opening verb 'Query' mismatches the mutating actions also listed. This is under-specification presented as conciseness, not organized, front-loaded useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 20 parameters, 19 actions, and no output schema, this description is grossly incomplete. The agent needs to know which action drives which parameter set, what each action returns, and which actions are read-only vs. state-changing. None of this is provided. A tool of this complexity demands a structured per-action breakdown, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the critical flaw is that the description does not map which of the 20 parameters apply to which of the 19 actions. The description only lists action names; it gives no hint that e.g. 'imap_host' and 'app_key' relate to scan/endpoint actions, 'vat_period' to financial, or 'reason' to dismiss/ignore. This is a significant degradation below the schema-only baseline because the mapping between action and its applicable parameters is entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists 19 distinct actions that the tool can perform, covering everything from 'summary' and 'financial' queries to 'add_endpoint' and 'seed_rules' operations. This is not a single coherent purpose but a grab-bag of heterogeneous capabilities. The description does give a specific verb ('Query') and resource ('mail transceiver'), but the scope is so broad it fails to communicate what the tool fundamentally does or why the agent would choose it over siblings like gc_banks, gc_cash, or gc_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use the various actions. The description simply enumerates the action names without explaining which scenario triggers which action. No exclusions or alternatives are mentioned, despite the tool overlapping conceptually with gc_banks (financial) and gc_cash (financial tracking). An agent is left to guess which of 19 actions is appropriate for a given request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. With 9 actions spanning creation (create, post - mutations) and analytics (list, report, compare, trend, funnel - reads), the description gives zero context about side effects, write behavior, idempotency, or what data gets modified. It mentions 'force ingest even if duplicate snapshot exists' only in the schema, not the description. For a tool with multiple mutating actions, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core concept, but the action list is presented as a comma-delimited catalog that adds noise without explanation. The first sentence is useful; the second sentence is essentially a table of contents that could be derived from the action enum in the schema, providing marginal added value while being technically redundant with the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool (32 params, 9 actions, no output schema, no annotations) but the description gives essentially nothing operational. There's no guidance on which action requires which parameters, no output/return expectations, no mention of prerequisite data (e.g., must create a piece before posting), no error handling notes, and no description of expected workflows. For a tool this complex, the description is drastically under-specified and would leave an agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description itself adds zero parameter meaning beyond the schema. More importantly, with 32 parameters (many optional, action-dependent), the description does nothing to clarify which parameters apply to which action. The description lists actions but never maps parameters to actions, so an agent cannot know that 'piece_id' is for 'post', 'file' is for 'ingest', 'dimension' is for 'compare', etc. The description fails to compensate for this complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Content dissemination metrics' and lists actions, but it reads like a menu or catalog rather than a clear statement of a single cohesive purpose. It's a catch-all tool with 9 different actions and 32 parameters, making the primary purpose ambiguous. It doesn't distinguish itself from siblings like gc_engagement (which likely overlaps with metrics) or gc_work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions (create, post, snapshot, ingest, list, report, compare, trend, funnel) but provides no guidance on when to use this tool versus alternatives. No mention of when NOT to use it, no exclusions, and no context about which sibling tools might be better suited for overlapping tasks like engagement tracking (gc_engagement). The action is exposed as a required parameter but there's no explanation of how actions map to use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden, but it discloses almost nothing: no mention of backend availability, auth requirements, latency, side effects of 'retain', or what happens when the backend is unreachable. It does note 'Foresight expected to succeed it', which hints at instability, but says nothing about operational behavior or risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus an action list), which is efficient, and it front-loads the proxy/backend context. But conciseness here approaches under-specification—it's a single dense sentence that crams backend substitutions without providing usable structure for an agent deciding how to invoke it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 distinct actions, 7 params (1 nested object), and no output schema, the description is severely under-specified. It doesn't explain each action's return, behavior, or param requirements, nor does it note that dedicated sibling tools exist for the same actions. Given the complexity and zero annotations, this is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds zero parameter context beyond what the schema already provides. The description doesn't clarify how parameters map to each action (e.g., which params apply per action), how actions interrelate, or format requirements. It fails to compensate for the ambiguity of 7 params affecting different actions differently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description calls it a 'Direct proxy to the deep-memory backend' and lists four actions, but it never states WHAT the tool actually does in user terms. It doesn't explain what 'recall', 'reflect', 'retain', or 'health' accomplish semantically. The enum in the schema partially conveys purpose but the description adds little beyond naming the backend. Notably, gc_recall and gc_recall siblings exist, so the distinct purpose is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this proxy tool vs the dedicated sibling tools (gc_recall, gc_retain, gc_reflect) which likely cover the same actions more specifically. No context on use cases, prerequisites, or exclusions. The description gives no decision support for when this umbrella proxy is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. The term 'circuit-breaker' hints at safety mechanisms (presumably blocking spend when ceilings are exceeded), but the description never explains important behaviors: what happens when a ceiling is exceeded, whether reset has side effects, what 'status' vs 'check' vs 'spend' actually do, or whether any action is destructive. The description lists actions but gives zero behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), which is efficient, but it reads as a compressed catalog dump—a list of action names plus a parenthetical referring to internal ticket references. The 'Story 3.3, AD-26' reference is meaningless to an external agent and the action enumeration repeats what the schema's action enum already communicates. It's under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex dispatch tool with 11 parameters and 7 distinct actions, no output schema, and no annotations. The description does not explain the circuit-breaker semantics (thresholds, what triggers a break), what each action returns, or how the tool integrates with the broader gc_cost/cost-management system. For a tool of this complexity, the description is substantially under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 11 parameters have descriptions in the schema, which establishes a baseline of 3. However, the descriptions are terse parenthetical tags like '(for spend)' and '(for estimate)' that map parameters to actions but don't explain format, units beyond 'cents', or relationships between parameters (e.g., which combinations are valid for which actions). The description itself adds no parameter information beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Provider cost ceilings and circuit-breaker' which identifies the domain, and lists the available actions. However, it lacks a clear verb+resource statement of what the tool does as a whole—it's a dispatcher tool covering 7 distinct actions with no unifying operational sentence. The purpose is somewhat clear but relies on the action list rather than an explicit statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on WHEN to use this tool vs alternatives. It does not distinguish from siblings like gc_cash (cost-related), gc_control, or gc_capability. The mention of 'Story 3.3, AD-26' provides internal project context but offers no practical usage direction. No when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only lists action names without explaining behavioral implications: what spawn requires, what destroy does (destructive action?), what get vs list returns, rate limits, or side effects. For a multi-action tool with a destroy operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two lines). It's concise but borderline under-specified. The action list is useful but the overall description reads more like a stub or placeholder than an actual tool definition. Brevity here sacrifices necessary explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 5-parameter tool with an enum action field, nested objects (config), and no output schema. No annotations back it up. The description covers essentially none of the behavioral complexity—what each action does, return values, prerequisites, or error conditions. For a multi-action tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema (action enum, config, message, peer_agent, session_id each have descriptions). The description itself adds no parameter information beyond naming the actions. With high schema coverage, baseline 3 is appropriate, though no additional value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it's a 'Legacy alias for gc_peer_conversation' and lists actions, but it doesn't explain what the tool actually DOES beyond being an alias. It doesn't describe the purpose of spawn/turn/get/list/destroy operations in any meaningful way. The reader must infer that 'gc_peer_conversation' is a peer conversation tool from the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this vs alternatives. While it names gc_peer_conversation as the replacement, it doesn't say when a user should prefer the new tool, clarify the relationship, or explain what peer conversations are used for. There's no when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It reveals nothing about side effects: whether set_global persists across sessions, whether clear_tool_trust is reversible, how levels (cautious/normal/trusting) affect downstream behavior, or any authorization requirements. The reference to 'Story 3.6' and 'FR-6' provides no useful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the action list is compact. However, the reference to 'Story 3.6, FR-6' is meaningless to an agent and wastes tokens. The line about actions is borderline useful as a scope indicator, but the overall structure doesn't earn its minimal length — there's one sentence of actual value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a 4-parameter tool with enums and no output schema, the description should explain the semantics of acting on trust posture — but it doesn't. It doesn't describe what 'loosen_reasons' accomplishes, how levels map to behavior, what get returns, or how this interrelates with other gc_* capabilities. The specification reference suggests this is a niche internal tool that needs more context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the input schema. The description adds minimal value beyond schema — it repeats which action maps to which parameter via parenthetical hints ('for set_tool_trust/clear_tool_trust'), which the schema already states. There's no added depth about value semantics or constraints, but the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description describes gc_posture as an 'Operator-tunable trust posture' and lists actions, but doesn't clearly state what the tool does as a verb+resource. 'Trust posture' is vague — it doesn't explain what a posture is, what changing it affects, or how it differs from the many sibling gc_* tools. The description reads more like a spec reference (Story 3.6, FR-6) than a functional explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus any sibling. The action list implies operations but gives no context about the decision flow — when would an operator get vs set trust, or what situations call for tool trust vs global posture changes. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It names 'requires Resolve to be running' but doesn't explain that the tool is effectively a dispatcher that requires a valid 'action' parameter, what side effects mutating actions have, whether actions persist state, or what happens on errors (e.g., when Resolve isn't installed on the host). The broad action list implies mutating capabilities (render, delete, add) but nothing is disclosed about their effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the action list is front-loaded, which is structurally reasonable. However, the list of 38 action names is essentially just a flattened enum dump that duplicates what the 'action' parameter's enum already provides. It's not redundant bloat, but it doesn't add meaningful structure; it reads like a copy-paste of the enum values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool with 41 parameters, 38 actions, no annotations, and no output schema. The description is far from complete: it doesn't explain parameter-to-action relationships, expected outputs, required parameters per action, or error modes. For a dispatcher tool of this complexity, the description should map actions to their relevant parameters or at least group related actions. This fails to meet that bar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each of the 40 optional parameters has a description in the schema. However, the description adds essentially no semantic value beyond the schema - it simply lists action names. Critically, since this is a dispatcher pattern, the description does nothing to clarify WHICH parameters apply to WHICH actions. Given 41 parameters and 38 possible actions, this is a severe gap that the schema alone cannot bridge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool controls DaVinci Resolve Studio via scripting API and lists 38 actions. It names a specific resource (DaVinci Resolve) and verb (Control), but is essentially a mega-tool covering dozens of unrelated operations (render, markers, subtitles, timecode, media import). The action list gives some specificity but no single clear purpose; it reads more like a navigation menu than a focused tool definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Requires Resolve to be running', which is a prerequisite rather than guidance on when to use this tool vs alternatives. With 38 sibling tools present, there is no mention of when this tool is preferred, when not to use it, or how the 38 different actions should be selected. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions provisioning and offline operation, which implies state-changing behavior, but doesn't disclose side effects, prerequisites (e.g., does provisioning require an existing model file?), or whether these operations persist state. The mention of 'Story 2.10, AD-34' adds no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact - two sentences listing the action enum. It's efficient with no wasted prose. However, the second action list is fairly redundant with the schema enum, since it duplicates what the input schema already declares.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-action dispatcher with no output schema and no annotations, the description is under-specified. It doesn't explain return values, error behavior, or how actions interact with each other. Each action behaves differently, yet the description treats them uniformly. The 'Story 2.10, AD-34' reference is opaque to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all three parameters. The description adds minimal param context beyond noting model and endpoint are 'for provision' through the inline parenthetical. It doesn't explain what each action expects in terms of parameters (does status require model? does connectivity require endpoint?), which is a significant gap for a multi-action dispatcher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it handles local MLX model provisioning and offline operation status, which is clear enough as a purpose. However, it's a multi-action dispatcher (four distinct actions) rather than a single-focused verb+resource, so it's more a category description than a specific operation. It does distinguish from siblings via the MLX model scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. It lists four actions (provision, status, offline, connectivity) but doesn't explain when each would be appropriate, nor does it mention any exclusions or alternatives. The sibling set includes many gc_* tools where such guidance would be crucial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description lists actions but reveals nothing about behavioral implications: whether deletion is destructive, whether spawning requires a specific agent name, whether turns mutate session state, or rate limits. It describes what actions exist but not the consequences or lifecycle of sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and the action list is helpful, but the second sentence is largely a restatement of the schema enum and could earn more value. It's appropriately short but the space used could carry more useful behavioral or usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, 7 parameters, nested objects, and 5 distinct actions each with different parameter needs, the description is too thin. The action enum alone doesn't explain which parameters apply to which action, what each action returns, or the session lifecycle. For a multi-action tool this is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter labels (alias notes for id/agent, 'for spawn' parentheticals on config/agent_name/message). The description simply restates the action enum without adding meaning. Baseline 3 is appropriate since the schema already documents each parameter well, though the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Chat-style sessions with local GC agents' which gives a clear conceptual domain, and lists the five actions (spawn, turn, get, list, delete). However, it doesn't say what the tool DOES with a specific verb+resource framing that distinguishes it from similar objects like gc_conversation and gc_peer_conversation in the sibling list. The purpose is understandable but the distinction from sibling conversation tools is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus gc_conversation, gc_peer_conversation, or gc_sessions. It lists actions but gives no context about selection criteria, prerequisites (e.g., an agent must be spawned before turning), or when not to use it. This is a significant gap given the large sibling set of conversation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It names six actions but provides zero detail on side effects, whether operations are destructive, what 'seat-switch' mutates, whether launching creates persistent side effects, or what responses look like. Story/FR references are unhelpful without external context. For a multi-action orchestrator with no annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence plus action list) which is efficient, but the brevity comes at the cost of clarity. Referencing 'Story 2.11, FR-21' and internal action vocabulary (plant, seat, tree) without definitions makes it cryptic. It is short but not well-structured for an external agent, trading usefulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 6 actions, no output schema, and no annotations, the description is severely under-specified. It does not explain the return format, the relationships between actions (plant→tree→node→launch sequencing), or required parameter combinations per action. An agent invoking this tool would need substantial external knowledge to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the per-parameter descriptions are thin, mostly restating 'for plant'/'for launch' without clarifying semantics. The description's action list maps roughly to parameter groups, adding modest value by hinting which params apply to which action. However, with 9 parameters and ambiguous action behaviors, the description does not meaningfully compensate beyond the schema's minimal per-parameter notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it handles 'Orchestration trees: create + seat-switch for agent hierarchies' with a list of six actions (plant, launch, seat, tree, node, list). This identifies a general purpose but is terse and does not differentiate from siblings beyond broad naming. The verb+resource is present but the action semantics are opaque (e.g., what 'plant', 'launch', 'seat' mean operationally) without further context, so it falls short of a clear, self-contained purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references Story 2.11, FR-21 and lists actions, but gives no guidance on when to use this tool versus alternatives like gc_workflow or gc_run. There is no when-to-use, when-not-to-use, or alternative-naming. The action enum in the schema implies some dispatch logic but the description offers no decision guidance for an agent selecting among the many gc_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to state whether actions mutate state (e.g., upsert_resource, upsert_profile likely write), whether next/replan consume or modify the queue, whether simulate is read-only, or whether solve_and_validate has side effects. It lists actions but gives no behavioral detail about effects, prerequisites, or side effects whatsoever.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but the second sentence is a raw action-name dump that uses significant space to enumerate actions without explaining them. Every token could 'earn its place' with even a one-line gloss per action group. The opening 'Resource-constrained scheduler' and question are useful but the action list adds little value as written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 19 parameters, 15 distinct actions, no output schema, and no annotations. The description fails to convey the state machine between actions (e.g., profile → resources → capacity → simulate → solve), which actions are required in sequence, what each action returns, or what inputs each action needs from the 19 available parameters. This is a significant completeness gap for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 19 parameters have descriptions in the schema, which sets the baseline at 3. The description itself adds zero parameter context. However, many parameter descriptions reference named entities (e.g., 'Leonidas' default resource, scenario names like 'revenue_mode') that are opaque without further explanation, and the description does nothing to clarify these domain-specific values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Resource-constrained scheduler' and poses a guiding question ('What should I work on next?'), which establishes the general domain. However, it does not use a specific verb+resource structure for this single tool, and it lists 15 potential actions without explaining what each does. The purpose is understandable at the domain level but opaque at the operation level; an agent cannot tell what outcome to expect from any individual action without deeper inspection of the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs. alternatives, nor when NOT to use it. The sibling tools include gc_schedule and gc_work, which could plausibly overlap with scheduling/replanning, yet no differentiation is offered. The description simply lists available actions without context on which to pick or when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the four actions but does not describe side effects, permission requirements, authentication needs, or what happens on failure. For a tool that can read/similar/search documents in a database, it does not disclose behaviors like rate limits, database access requirements, or return value shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core purpose in one sentence and enumerating actions in a clear, scannable format. The action list is useful and efficient even though it overlaps the schema enum. No wasted words, though the action enumeration could arguably be trimmed given the schema already declares the enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a multi-action tool with 6 parameters, no output schema, and no annotations. The description is thin: it names actions but does not explain return shape, error behavior, or the meaning of partial parameters per action (e.g., which params apply to 'search' vs 'read'). The schema covers parameter types but the description does not guide an agent through action-specific usage, leaving significant interpretive burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 6 parameters are individually documented in the schema. The description does not repeat parameter details but also adds nothing beyond what the schema already states. With full coverage, baseline 3 is appropriate; the actions list overlaps the enum description without adding new value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search and retrieve documents from DEVONthink' gives a clear verb+resource (search/retrieve + DEVONthink). It lists four distinct actions that help define scope, but the actions are covered by the input-schema enum for 'action', so the description somewhat duplicates what the schema already provides. Purpose is clear but not strongly differentiated from the many sibling gc_* tools beyond naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use devonthink vs alternatives, nor when-not-to-use. It does imply usage through the action list (search, similar, read, databases), which gives partial context, but there are no exclusions, prerequisites, or sibling comparisons. The description names the tool's action taxonomy but never instructs an agent when each action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It lists actions including 'delete' (implying mutation/destruction) but reveals nothing about side effects, whether deletion is permanent, what 'turn' does to state, authentication needs, or consequences across the action set. The one-line summary is insufficient for a tool with five distinct mutating behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief — two sentences. However, this is under-specification rather than genuine conciseness; for a 7-parameter, 5-action tool it's too terse to be useful. Still, there's zero wasted words. The format is clean and readable. It earns a 4 for brevity despite lacking substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 mutating actions (including delete), 7 parameters, no annotations, and no output schema, the description is far too minimal. It doesn't explain return formats, what 'turn' requires, how spawn works with persona/business_name/pre_research preconditions, or side effects. With a complex action-based tool this level of description is inadequate for an agent to invoke it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are described in the schema (id, action, message, persona, instance_id, pre_research, business_name). The description lists the action names, providing some semantic context that maps roughly to parameters, but it adds minimal meaning beyond the schema (e.g., doesn't clarify that 'id' and 'instance_id' are aliases, though the schema already notes that). Baseline 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Aden conversation instances' and lists actions (spawn, turn, get, list, delete), which conveys that this is a resource-management tool for Aden conversation instances. However, 'Aden' is undefined — what is Aden? This lacks specificity about what spawn/turn/get actually do at the domain level, and the ambiguity doesn't help distinguish it from siblings like gc_conversation, gc_agent_conversation, and gc_peer_conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With siblings gc_conversation, gc_agent_conversation, gc_peer_conversation, gc_sessions all plausibly related to conversations, the description offers zero direction on which one to choose. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists many actions but does not explain what side effects occur (e.g., does 'reset' destroy data? does 'bootstrap_apex' create persistent resources? what happens on destructive actions like 'reset_node'?). The description is purely a catalog of action names with no disclosure of mutation behavior, persistence, or reversibility for this clearly stateful orchestration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a compact ledger format that front-loads the core actions and groups the rest into categories. It is reasonably sized given the enormous action surface (50+ enum values). Every line adds action-tier information with no filler. However, it is essentially a long list rather than a structured explanation, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 16 parameters, many with nested untyped objects, 50+ enum actions, and no output schema. A careful mapping of which parameters apply to which actions would be necessary for an agent to invoke it correctly. The description only gives terse inline hints in the schema (e.g., 'for launch_node') and the grouped list in the description, leaving significant ambiguity about the dispatch contract, return values, and required parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a description (e.g., 'New node status (for update_node)', 'Override params (for launch_node)'). The descriptions add per-action relevance notes. However, they remain terse and don't explain formats, constraints on nested objects (params, answers, context, metadata are all untyped open objects), or which parameters are required for which actions. Baseline 3 is appropriate given the full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Onboarding DAG orchestration and setup generation' which identifies the domain, and lists many distinct actions. However, the verb+resource clarity is diffuse because the tool is a multi-action dispatcher with 50+ enum actions; it reads more like a menu than a focused purpose statement. It does help distinguish the tool's scope from siblings like gc_orchestration and gc_workflow, but only at a high level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description groups actions into functional categories but provides no guidance on WHEN to use this tool vs alternatives (e.g., when to use gc_onboarding vs gc_workflow, gc_schedule, or gc_directive). It says 'Onboarding DAG orchestration' but never states when onboarding is appropriate versus other workflow/control tools, and there are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 lists 10 actions (several of which are mutating: delete, log, start_timer, stop_timer) but does not disclose what side effects occur, whether data is destroyed on delete, permission requirements, or persistence behavior. It does note 'actual time spent on work' and 'duration models,' but there's no behavioral disclosure about destruction, overwrites, or system state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact (2 sentences plus a list of action names), and the core-purpose sentence is front-loaded. The list of actions is helpful for discovery but is presented as a bare comma-separated enumeration without any explanation or grouping. It's under-specified rather than genuinely concise, but the format is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 18 parameters, 10 dispatch actions, no output schema, and no annotations. The description must carry significant burden to make this usable, but it only provides a one-line purpose and a flat action list. It doesn't explain return formats, which action returns what, how duration_estimate differs from aggregate, how log differs from log_agent_job, or any of the many edge cases. For a tool with this breadth, the description is substantially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each of the 18 parameters has its own description in the schema (e.g., 'Start time (ISO 8601)', 'Task description (for log_agent_job)'). However, the tool's description adds nearly zero parameter-level meaning beyond listing the action names. Importantly, there is no mapping of which parameters apply to which action - for a 10-action dispatcher, the description should clarify which params pair with which action, but it doesn't. So the description does not compensate for the complexity of a multi-action tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Track actual time spent on work' with specific verbs for actions (start_timer, stop_timer, log, delete, query, etc.). It clearly indicates this is a time-tracking tool. However, it's a broad multi-purpose tool that dispatches to 10 different actions, so the primary purpose is 'time tracking' but the specific verb depends on which action is chosen. It doesn't deeply distinguish from sibling gc_timing which may be a timing-specific tool, but the resource/action framing is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists 10 available actions but provides no guidance on when to use each action, no prerequisites, and no context on how this tool relates to alternatives like gc_timing or gc_schedule. There is no explanation of when to choose time tracking here vs other sibling tools. The list of actions is enumerative, not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not clarify mutating actions' side effects, requirements, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, but the second sentence listing all ten actions is essentially restating the action enum already present in the schema, adding near-zero value. This is acceptable brevity but the space could have better been used for actionable guidance rather than redundant action enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-action tool (10 actions, 18 parameters) with no output schema and no annotations, yet the description does not map actions to their parameters, distinguish behaviors, or explain outputs. Given the complexity and the lack of structured support, the description is materially incomplete — an agent would not know which parameters are needed for each action or what the results look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully documents all 18 parameters; description adds minimal action-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Manages timeline events — deadlines, appointments, blocks, milestones' with a specific verb+resource and lists the entity types. It distinctly handles timeline/scheduling events unlike siblings like gc_schedule or gc_remind, though the purpose is somewhat aggregated across 10 different actions rather than a single focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. Siblings include gc_schedule, gc_remind, gc_timing, and gh_issue_create, which could plausibly overlap with timeline event or link operations, but the description provides zero exclusions or context about when each of the 10 actions is appropriate. The listing of action names adds no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't reveal whether delete/update are destructive to existing data, whether transitions mutate state, whether operations persist immediately, or what the response format looks like. Given that delete and transition are clearly mutating operations, their safety profile is entirely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient at 3 short sentences with a compressed telegraphic style. However, the final sentence ('Use params for Records query filters, sort, temporal constraints, and pagination.') is somewhat vague and the second sentence reads like terse shorthand. It's concise but sacrifices clarity for brevity; a touch more elaboration would improve value without bloating it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 8-parameter tool with no output schema and no annotations covering 9 distinct actions. The description doesn't explain return values, error behavior, or which actions are read-only vs mutating. For a tool of this complexity, the 3-sentence description is insufficiently complete to guide correct invocation across the full action surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters have descriptions in the schema. The description adds value by explaining which params go with which actions ('Use definition for define_type', 'Use params for Records query filters'), which is genuinely helpful disambiguation beyond the schema. However, parameter-specific format details (e.g., what 'temporal constraints' look like, the pub_id format) are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it covers 'Runtime record definitions and instances' with a clear verb+resource framing, and lists the 9 actions. However, it's a polyglot tool bundling many distinct operations (CRUD, type definitions, transitions), so the purpose is diffuse rather than a single specific task. The title is null and the description reads as a header for a family of actions rather than a tightly-scoped function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There's some guidance ('Use definition for define_type and data for create/update', 'Use params for Records query filters') that maps actions to parameters. But there is no when-to-use guidance versus sibling tools, no exclusions, and no mention of when this tool is preferred over the many gc_* siblings. The action-specific usage hints are minimal and don't cover all 9 actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It does not disclose whether create/delete are destructive, whether operations are persisted permanently, what happens on failure, or what statistics are included. The description mentions 'stats' action but doesn't explain what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a clear action-to-purpose mapping. It is efficient and front-loads the primary purpose. Minor deduction for the inconsistency (describing 3 actions while the schema has 4) and for using shorthand quotes around action names that could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, this is under-specified. The delete action is entirely absent from the description despite being a first-class action in the schema and having its own special 'force' parameter. It doesn't clarify edge cases like force deletion behavior, whether create overwrites, or what stats output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all 5 parameters. The description adds marginal value by mapping each action to its relevant params (name for create/delete, keywords/description for create), which reinforces the schema rather than repeating it. Some useful grouping of params to actions is provided, earning above-baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages memory banks and lists actions (list, create, stats), which is clear for the primary purpose. However, it omits the 'delete' action from the action list even though it's in the schema, creating inconsistency. The purpose is identified as managing banks but the scope is muddled by the missing delete reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs sibling tools like gc_retain, gc_recall, or gc_memory-related tools. No exclusions or alternative tools are named. The action enum provides some context but no description explains which scenario calls for which action or tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions 'report durability' and 'flush buffers,' which hints at internal state effects, but it doesn't explain what flush does destructively, what status returns, what durability means in this context, or any side effects of actions. The behavior of each action remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief—two sentences with a clean action list. Every sentence earns its place. However, the brevity borders on under-specification since the tool has a four-way action dispatch with 11 parameters, so a bit more detail per action could have been warranted while staying concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-action tool (four distinct operations) with 11 parameters and no output schema and no annotations. The description gives only a one-line summary of each action without semantics around input requirements, return values, or failure modes. For its complexity, the description is significantly incomplete—an agent would struggle to know what parameters matter for each action and what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema itself annotates each parameter with its relevant action ('for ingest', 'for report'). The description adds a concise action list that maps roughly to parameter groups. While the description doesn't deeply elaborate beyond the schema, the schema already does the heavy lifting by pairing each parameter with its action context, so the bar for additional value is met reasonably.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (beat accumulation) and lists four concrete actions (ingest, status, flush, report). However, it's terse and doesn't explain the overall purpose with a verb+resource pattern meaningfully; 'Beat accumulation' is somewhat ambiguous and doesn't clearly distinguish this from siblings like gc_recall, gc_retain, or gc_checkpoint without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The action list implies different use cases (ingesting turns vs checking status vs flushing buffers vs reporting durability), but there's no explicit direction about which action to choose under what circumstances, and no exclusions or alternatives referenced despite the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses it is a 'legacy alias' (a meaningful behavioral trait) and that it 'returns' data (implying read-only). However, it doesn't disclose what the snapshot contains, whether it's cached/stale, or any side effects. The read-only nature is implied rather than explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the alias identity then the function. Concise and focused. However, being this brief leaves out important behavioral context that would have earned a higher completeness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, a single optional parameter, and a legacy-alias identity, the description is thin. It doesn't describe the snapshot's contents, the meaning of 'latest', whether data could be stale, or what 'overview' includes. Given zero annotation coverage, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions it returns a status snapshot but doesn't explain how the 'name' parameter (project name or 'all') affects the result beyond what the schema states. The 'all' value for overview is in the schema, so the description adds no meaningful parameter semantics beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'Legacy alias for gc_ticker/get' and 'Returns the latest ecosystem status snapshot.' This gives a clear verb+resource (returns status snapshot), but it's vague about what 'ecosystem status' actually encompasses and doesn't differentiate meaningfully from sibling gc_ticker, which it aliases. It establishes the purpose but leaves the domain ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance. It identifies itself as a legacy alias for gc_ticker/get, which implicitly suggests gc_ticker/get should be preferred, but it does not state this explicitly or give context for when to use this tool versus alternatives. The alias relationship is stated but not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes what the snapshot represents (feature availability for front-end) but doesn't disclose return format, whether it reflects server-synced state live or cached, what the single 'action: state' produces, or any side effects. With zero annotation coverage, this is thin behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words. The parenthetical '(features-light-up)' is informal jargon but brief. Reasonably efficient, though the opening sentence is somewhat cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (single required parameter), and there's no output schema. The description explains what the snapshot is used for (front-end feature availability), which is reasonable. However, it lacks return format details and the relationship to gc_capability_watch, which is a meaningful gap given zero annotations. For such a simple tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the only parameter (action) has a const value and a description. With a single const-constrained parameter, the schema is self-documenting. The description adds the context that the tool returns a capability-state snapshot, but the parameter itself requires no extra explanation. Baseline 3-4 is appropriate and justified here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns a capability snapshot the front-end uses to decide feature availability. The verb is implicit ('Returns') and the resource is 'capability snapshot', which loosely distinguishes it. However, the phrasing 'Reflected capability-state snapshot (features-light-up)' is Airtable-like jargon that may confuse an agent rather than clarify purpose. It's understandable but not crisp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this tool vs alternatives. Given there are siblings like gc_capability_watch, gc_control, and gc_cost, the description gives no differentiation. The agent cannot tell whether to call this once, repeatedly, or how it relates to reading other gc_* state. No context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state 'read-only' upfront, which is good. However, it doesn't disclose behaviors like what happens on empty results, date range validation, label matching behavior, or database accessibility/unavailability handling. For a DB query tool with zero annotations, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the key facts (read-only, source, actions). The action list is efficiently packed into one line. Efficient use of space without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database query tool with 4 parameters, an enum action field, and no output schema, the description is fairly minimal. It identifies the actions but doesn't describe expected return shapes for any action, no examples of parameters, and no indication of how labels or date ranges affect results. It's adequate to understand what the tool does but insufficient for confidently predicting behavior for each action combination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions (ISO date filters, labels for duration, action enum). The description adds a bit of value by mapping each action name to its semantic meaning (summary=project totals, duration=estimate from labels). But it doesn't elaborate on interaction between 'since'/'until' and specific actions, or which actions are compatible with which parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states read-only queries against macOS Timing.app SQLite database and lists the actions (summary, capacity, duration, hours_by_label). It identifies the resource (Timing.app database) and specific query actions, which distinguishes it from siblings. However, it doesn't fully explain what each action returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives, no prerequisites mentioned. It declares read-only nature but doesn't specify when to use each action or how it relates to other gc_* tools. The action names are listed but without explanation of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description mentions key behaviors (actions supported, drift detection as a feature) but doesn't disclose mutation semantics (what delete/update destroy), auth requirements, or rates. For a tool with multiple mutating actions and no annotation coverage, it provides only minimal behavioral context beyond the action list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at 3 sentences and communicates the core purpose and action list efficiently. However, it's somewhat under-specified—20 parameters with 9 actions deserve slightly more structural explanation (e.g., grouping which params apply to which action) to be most useful. Still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 20 parameters, 9 enum-driven actions, no output schema, no annotations. The description lists actions but fails to map actions to their relevant parameters or explain the behavioral differences between actions. Given the high complexity and available surface area, the description should provide far more (e.g., which params each action requires/accepts, what runway/forecast/drift return) but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 20 parameters. With high coverage, baseline is 3. The description adds the distinction that amount can be 'cents or euros' which the schema also states, so no additional meaning beyond schema is added. The description doesn't clarify how 'action' interacts with the 19 other optional params (e.g., which params apply to which action), which would be genuinely additive value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Track money in/out' with the specific derived functions (runway, forecasts, drift detection), establishing it as a cash-tracking tool. It lists 9 actions (add/update/delete/get/query/runway/monthly/forecast/drift) which gives concrete scope. However, it doesn't explicitly distinguish from the gc_cost sibling, and 'drift detection' is mentioned without explanation, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists what actions are available but gives no guidance on WHEN to use this tool vs alternatives like gc_cost or gc_banks. No when-to-use, when-not-to-use, or prerequisites (e.g., must input cash_on_hand for runway) are provided. The nine-action enumeration is just a catalog, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions auth types and actions but does not disclose what happens on responses, how errors are surfaced, whether non-2xx responses throw or return, rate limiting, or whether the tool has network access constraints. For a tool that makes arbitrary external HTTP calls, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and a compact enumeration of actions and auth types. No wasted words. Could arguably be considered slightly under-specified, but what's there is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic HTTP client with 7 params, nested objects, no output schema, and zero annotations, the description is under-specified. It doesn't explain response formats, status code handling, error semantics, rate limits, or security considerations of making arbitrary external calls. The complexity of this tool type demands more context to be safely invoked by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 7 parameters. The description adds the auth mechanism list (bearer, basic, header), which maps to the auth.type enum, and the action enum, but doesn't add semantics beyond the schema. Baseline 3 is appropriate since schema does the heavy lifting and the description provides marginal confirmation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Generic HTTP client for external API calls' with a specific verb+resource. It lists the four supported actions (get, post, put, delete) and auth mechanisms, which distinguishes it from siblings like gc_relay or gc_mcpclient that handle other transport concerns. However, it doesn't explicitly differentiate itself from those siblings, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('external API calls') but doesn't provide when-to-use vs when-not-to guidance or mention alternatives. There's no guidance on when to prefer this over sibling tools like gc_mcpclient, gc_relay, or gc_control. The context is clear for a generic HTTP client but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden of behavioral disclosure. The description explains that 'get' fetches a render payload + risk dot and that resolve supports edit-then-approve, which is some context. But it doesn't disclose what happens on reject (terminates? re-queues?), whether resolve is idempotent, what payload/risk dot represent, or any side effects. For a tool with get/resolve semantics, critical behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a bulleted list for the two actions. Each line is dense with information about the sub-operations. The only minor issue is the cryptic 'Story 3.5a' reference that adds no functional value for an agent. Otherwise efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool dispatches across two distinct operations (get and resolve) with a nested object parameter (edited_args) and no output schema. The description explains render payload/risk dot for get and approve/reject for resolve, which is reasonable, but it doesn't describe the output format of get (what the render payload looks like), the full resolve flow (what happens after approve/reject), or failure scenarios. For a multi-action dispatcher with a nested object, more detail would help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters (id, action, decision, edited_args) are documented in the schema. The description adds the meaning of the action enum values ('get' vs 'resolve') and the edited_args use case (edit-then-approve), which enriches beyond raw schema. However, it doesn't clarify how decision and edited_args interact (e.g., is decision required when edited_args present?), leaving some ambiguity. Baseline 3 is appropriate given high schema coverage with modest description augmentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this is for 'Approval checkpoints (Story 3.5a)' and distinguishes two sub-actions: 'get' fetch a held action's render payload + risk dot, and 'resolve' approve/reject. The verb and resource are clear, though the 'Story 3.5a' reference is cryptic. It's distinguishing internally between actions but doesn't differentiate from sibling tools (though checkpoint semantics are fairly unique among siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two actions and what they do, which implies when each would be used (get before resolve, resolve to complete a checkpoint). However, it doesn't explicitly state when to use this tool vs sibling tools, nor does it describe the workflow ordering clearly (must get before resolve, is resolve required after get, etc.). The edit-then-approve concept is mentioned but not fully explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Screen-first by default' and 'File output only when target=file|both', which is useful. However, it doesn't disclose key behavioral traits: what the audit entails, whether compute is destructive, what sensitivity changes, or what happens on errors. The action enum partially compensates by implying the range of behaviors, but significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by the default behavior and action list. The two-line format is efficient and scannable. Minor redundancy: the action list is fully mirrored in the schema's enum, so listing it again is somewhat redundant, but it aids quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fairly complex tool with 15 parameters and 6 actions, no output schema, and no annotations, the description is on the thinner side. It covers the default target, the action set, and the data sources, but doesn't explain the relationship between parameters like k_values/tolerance_minutes/bin_minutes and the sensitivity/audit actions, nor what the audit CSV includes. Given schema coverage of 100%, the description doesn't need to restate params, but should clarify action-specific behaviors for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 15 parameters thoroughly. The description adds value by explaining the default target behavior and listing the actions, but doesn't elaborate on parameter semantics beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting; the description's mention of 'target=file|both' and default tolerances adds modest context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Reconstruct engaged-attention hours from Timing presence plus project-touch events') and the resource (Timing + project-touch events across tools). It lists the specific actions available. However, it doesn't distinguish itself from siblings like gc_timing or gc_sessions, which could overlap with timing/attention data; the tool's unique value (merging Timing presence with project-touch events) is stated but not contrasted against related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implicit sense of when to use it (for reconstructing engaged-attention hours and various analysis actions), but provides no explicit when-to-use vs alternatives guidance. The list of actions hints at use cases (compute, audit, sensitivity, etc.), but there's no direction on which sibling tool to use instead when the user just needs raw timing data or session records. Also no prerequisites, default behaviors beyond target/tolerance are partly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the two actions at a high level but doesn't disclose what happens on failure, required prerequisites (e.g., whether message_id must be valid, whether block_json must match a specific schema), error behaviors, or side effects. The 'merge-field' concept is introduced (GC-2774) but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a bullet-style structure that front-loads the two key actions. Each sentence earns its place, and the ticket reference (GC-2774) provides traceability. It's efficient without being under-specified, though the terse formatting style could be marginally clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex multi-action tool with 7 parameters and nested objects, no output schema, and no annotations. The description covers the two action paths but omits critical details like expected object shapes for block_json/values, error handling, and what the placeholders output should look like. It's adequate for basic usage but leaves the agent to guess on real-world invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by mapping which parameters belong to which action (placeholders vs fill), but it doesn't elaborate beyond what the schema already states. Nested objects (block_json, values) aren't described in terms of expected structure or format, leaving meaningful gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies two distinct sub-operations (placeholders and fill) with specific verbs and resources, making the tool's purpose clear. However, the title is null and the tool name 'gc_template' alone doesn't fully convey that it handles merge-field templating; the description compensates reasonably well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when each sub-action is appropriate (placeholders to list available fields, fill to render), which gives the agent some guidance. However, it doesn't explicitly explain which sibling tools might be alternatives or when templating would NOT be the right choice, and the relationship to other gc_* tools isn't clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It tells the user the issue URL is returned, which is helpful, but it doesn't state that this is a write/mutating operation (schema implies POST semantics but nothing explicit), doesn't mention authentication requirements, rate limits, or whether existing labels/assignees are validated. The bare minimum write-side transparency is partially covered by 'a write never infers its target' in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence plus a return-value note. It's front-loaded with the core purpose and stays minimal. No wasted words. Could arguably include usage caveats, but what's there is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a straightforward create-with-5-params tool with no output schema and no annotations. The description covers purpose and return value but lacks guidance on when to use it vs sibling tools and what post-conditions hold (e.g., issue number assigned, labels must pre-exist). For a simple resource-creation tool with full schema coverage, it's minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 5 parameters have their own descriptions in the schema, which raises the baseline to 3. The description itself adds 'Returns the issue URL' but no additional parameter meaning. The labels comma-separated and assignee username details come from schema, not the description. This is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb+resource ('Create a GitHub issue') and notes the return value (issue URL). It doesn't explicitly distinguish from siblings like gh_issue_edit or gh_issue_comment, but the verb 'create' uniquely maps to this operation among them. Could add a note about the repo being the target, which is covered in schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies creation as the use case but gives no explicit when-to-use or when-not-to-use guidance. It doesn't differentiate from gh_issue_view, gh_issue_edit, gh_issue_comment, or gh_issues. The 'required; a write never infers its target' note on repo in the schema gives some context about requiring explicit target, but the description itself offers no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does disclose key behavioral traits: SSE mechanism, live streaming nature, initial snapshot before changes, and termination at timeout. However, it doesn't describe heartbeat behavior, error/EOF handling, or what happens on disconnect, leaving some gaps for a streaming tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core mechanism (SSE watch), immediately clarifying return pattern (initial snapshot + subsequent changes) and lifecycle boundary (until timeout). Zero waste, every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a streaming tool with no output schema and partial behavioral context (timeout, snapshot), the description covers the essentials but leaves out heartbeat semantics and stream-termination edge cases. The addition of gc_capability and gc_workflow_watch siblings and the rich 'none/infinity/infinite' timeout options suggest deeper behavior that isn't fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('Max watch time in seconds' and 'Heartbeat interval ms'). The description adds minimal value beyond the schema, though it does contextualize the timeout as the terminator of the stream ('until timeout'). Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('watch') plus resource ('capability-state changes') and clarifies the SSE mechanism. It states what the tool does: live SSE watch returning initial snapshot plus subsequent changes. It doesn't explicitly distinguish from sibling gc_capability or gc_workflow_watch, which is a minor gap, but among ~60 gc_* siblings, the watch-vs-query distinction is reasonably implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like gc_capability (the query counterpart) or gc_workflow_watch. It doesn't state common use cases for a capability watch, nor explain when a snapshot+watch is preferred over a one-shot fetch. The description gives no 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 lists actions but doesn't disclose important behaviors: whether turn is stateful across calls, what happens on session errors, rate limits, or whether sessions persist across agent executions. The 'backend-neutral' note adds some transparency value. Without annotations, the behavioral disclosure is thin but the action list does convey the core operations reasonably.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact given the tool's complexity (10 actions). The action list with short inline annotations is front-loaded and scannable. Each action gets a brief descriptor. It's not bloated, though the bullet format could be slightly tighter given the schema already defines each action in the enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 params, 1 enum (10 actions), no output schema, and no annotations, this is a high-complexity tool. The description covers the action catalog well but lacks depth on workflows (e.g., the spawn→turn→submit_tool_results→turn cycle, which appears to be a multi-step interaction pattern). It also doesn't clarify return/session semantics. Given the complexity and absence of annotations and output schema, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter has a description. The description adds value by indicating which parameters apply to which action (e.g., 'persona/agent_name, optional config, make_apex' for spawn, 'send a message' for turn). It also clarifies aliases (id for session_id, agent/agent_name for persona, results for tool_results). This mapping of parameters to specific actions is genuinely helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this handles 'Interactive AI conversation sessions' and enumerates actions (spawn, turn, submit_tool_results, cut_in, etc.). However, this is a multi-action dispatcher tool where the actual purpose depends on which action is chosen, and the description reads more like a menu than a concise statement of a single purpose. It's clear about scope (backend-neutral, inferring it abstracts across providers) but doesn't sharply distinguish it from the many conversation sibling tools (gc_agent_conversation, gc_peer_conversation, gc_aden).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action list implies usage contexts (e.g., 'turn: send a message and get the assistant response'), but there's no explicit guidance on when to use gc_conversation versus alternatives like gc_agent_conversation or gc_peer_conversation. The 'backend-neutral' framing hints at generality but doesn't state exclusions or which sibling to prefer in what circumstances. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While it lists actions and their basic intents, it doesn't disclose whether classify/dismiss are destructive (reversible or not), whether run triggers persistent side-effects, or whether specific permissions/auth are needed. The description hints at behavior through action names but leaves mutation semantics underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—a one-line purpose plus a terse action list with inline parentheticals. The format is scannable and front-loads the core purpose. A bit telegraphic, but appropriately sized for a dispatcher-style tool with many sub-actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 actions and a nested object param (resolution) with no output schema, the description reasonably maps each action to its input parameters. However, it doesn't explain what the classify resolution object should contain, what status/rules return, or how results are structured—gaps that matter for a multi-action tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by tying specific parameters to actions (id for classify/dismiss, reason for dismiss, resolution for classify, rule_file for run/rules), which helps the agent know which params apply to which sub-operation—beyond what the flat schema alone conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as a 'Reconciliation engine for data hygiene' and enumerates six distinct actions with parenthetical clarifiers (status = last runs/pending reviews, run = trigger sync, etc.), which maps actions to behaviors. It doesn't explicitly distinguish from siblings like gc_recall, gc_retain, or gc_reflect, though the reconciliation-for-hygiene framing provides some differentiation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action list implicitly conveys when to use each sub-operation, but there's no explicit guidance on when to choose this tool versus sibling reconciliation/retention tools like gc_recall or gc_retain. No exclusions or alternative recommendations are given, leaving cross-tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that execute 'may return held: true if the gate requires approval' (a gate/approval mechanism) and that execution is 'LLM-free' and 'deterministic'. However, it doesn't disclose side effects, what approved operations do, reversibility, or failure modes. Partially informative but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear bulleted break-down of the two actions. Every line earns its place. Slight deduction for the cryptic 'Story 3.1' reference and the dash-packed opening line which is somewhat opaque, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an execute action that runs arbitrary operations (tool, op, args, idempotency_key) and no output schema, the description is fairly thin. It doesn't explain the relationship between op/tool/args, what 'risk metadata' contains, what held:true implies for the caller's next step, or how approval gating works. For a tool that executes operations with a gate, more completeness is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a brief description. The description adds minimal value beyond the schema, though 'may return held: true' hints at execute behavior. The action enum is self-explanatory, and the description names the two actions. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it executes 'approved operations' via deterministic dual-path controls, with two specific actions (manifest and execute). It's clear about verb and resource. However, it doesn't sharply distinguish from siblings beyond mentioning the dual-path deterministic nature, which requires the reader to understand what 'Story 3.1' and 'gate' context implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use manifest (list operations/risk metadata) vs execute (run one control) but doesn't clarify when to prefer this over gc_tool_call, gc_dispatch, or gc_run — sibling tools that likely also execute operations. No explicit exclusions or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It's a read/search operation by nature ('find documents'), which is safe, but it doesn't disclose behavior like whether this is a full-text search or metadata-only, result ordering, or pagination semantics beyond the limit default. The title-substring LIKE hint in the param schema adds some behavior info, but the description itself is thin on behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence that front-loads the purpose. Zero waste. Could benefit from an example but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a find/search tool with 5 optional parameters and no required fields, the description is adequate but not complete. It doesn't explain which filters are combinable, how to construct effective searches (partial vs exact matches), whether domain/project/type are exact or substring matches, or what the result set looks like. With no output schema and no annotations, the description could reasonably do more, though the tool is plausibly simple enough that this is near-minimum-viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists the filter dimensions (domain, type, project, title) which confirms what the schema already documents. It adds marginal framing (these are metadata filters) but doesn't provide format examples, combinational semantics (AND vs OR), or how filters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('find documents') with specific filter dimensions listed (domain, type, project, title). It distinguishes from siblings like gc_recall (likely recall/retrieve) and gc_retain (store) by clearly indicating this is a metadata-driven search, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a metadata search tool but doesn't state when to prefer it over gc_recall or gc_docs. With over 60 sibling tools including some document-related ones (gc_docs, gc_recall, gc_obsidian_vault), explicit differentiation would strengthen this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose supported transports and actions, and explains 'connect (register + connect)'. However, it doesn't disclose behavioral traits like side effects of connect/disconnect/remove, error behavior, whether connect persists state, or rate/token considerations. For a tools-list/call proxy, it's reasonably transparent but leaves security/side-effect semantics underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose first, then a concise list of supported transports and actions. Two focused sentences plus a bulleted action list—efficient. Could arguably split transport and action details but current structure is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 params, nested objects, and no output schema, the description gives a reasonable overview of the tool's surface but doesn't fully clarify interactions between fields (e.g., which action requires which fields, what call returns, whether removing vs disconnecting differ). For a complex proxy tool with multiple actions, more per-action guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description mapping to specific actions (url for connect, name for disconnect/remove, etc.). Description adds some value by explaining which transport types exist and noting metadata is for stdio. But the parameter descriptions already carry the semantics adequately, so the description adds only marginal context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'General-purpose MCP client proxy' that connects to MCP servers and supports connect/disconnect/call/scan etc. actions. It distinguishes itself from siblings by its generic 'proxy' nature (no specific domain). However, it doesn't explicitly contrast with sibling tools like gc_tool_call, which could be a competing option, so it misses a direct distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists supported actions and transports (streamable_http, sse, stdio, websocket) which gives context on when to use it. But it doesn't name specific alternative tools or state when NOT to use this vs alternatives like gc_tool_call. No exclusions or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The description reveals it 'enqueues' a reindex (implying async), which is useful behavioral context, and describes what 'status' returns (config and indexed chunk count). However, it doesn't disclose side effects, whether reindexing destroys prior state, resource requirements, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the purpose sentence, followed by the action list. Every sentence earns its place. Minor redundancy ('Obsidian vault' appears twice) but overall tight and well-organized for a 1-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param enum tool with full schema coverage and no output schema, the description covers the core function and both actions adequately. However, it lacks context on whether this is read-only or mutating, how the vault path is configured, and what 'status' output format looks like. It's adequate but not comprehensive for a tool that can trigger a potentially heavy reindex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single 'action' parameter fully enumerated. The description adds meaning by explaining what each enum value ('reindex' vs 'status') actually does, which goes beyond the schema's bare 'Action to perform'. With full schema coverage, the baseline is 3, and the description does supplement with contextual detail, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool indexes Obsidian vault .md files into the memory bank for retrieval via gc_recall. It distinguishes itself from siblings by naming its integration point (gc_recall) and specifying the file type (.md). A slight weakness is that the title is null and the verb 'indexing' is somewhat general, but the resource and action are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates the two valid actions ('reindex' and 'status') with their meanings, which provides clear usage context. However, it doesn't offer guidance on WHEN to use this tool vs alternatives, nor does it mention prerequisites (e.g., is an Obsidian vault path configured?) or any exclusions. The action enumeration is helpful but not a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided (no readOnlyHint, no destructiveHint), the description carries full behavioral burden. It states actions include delete and dismiss (implying mutation) but doesn't disclose whether reminders fire automatically, how state transitions between pending and fired work, or whether Eve-managed reminders behave differently from human-created ones. The 'managed by Eve or directly' hint adds context but not deep behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the essential purpose ('Human reminders') followed by the action list. The 'Due accepts' line is useful. It could arguably drop the parenthetical explanations since the schema enums already cover those, but it's not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a 9-parameter multi-action tool with no output schema and no annotations, the description should carry more weight, but it covers the action semantics and due format. Missing: what the response looks like for list vs add, whether reminders persist across sessions, and how the recurrence field interacts with date-based firing. Given the tool's complexity (9 params, 5 actions), the description is adequate but leaves workflow questions open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema already conveys—params like due, status, created_by, recurrence, snooze_for are all self-describing in the schema itself. The description mentions 'Due accepts: ISO timestamps, relative times' which slightly enriches the due parameter, but this is marginal beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Human reminders' and enumerates five distinct actions (add/list/dismiss/snooze/delete), giving a clear verb+resource+scope for what the tool does. It could distinguish itself more from siblings like gc_schedule or gc_beat, which may overlap in timing/cadence territory, but the reminder semantics are reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the actions and their purposes ('add (create reminder)', 'dismiss (mark as handled)', etc.), which implicitly tells agents when each mode is appropriate. However, it does not mention when to prefer this over alternative tools like gc_schedule, gc_timing, or gc_notify, nor does it state exclusion criteria for which reminder scenarios belong elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. It states it returns running/connected status but doesn't describe the exact return format, whether it's a health check, or if it triggers any side effects. Given this is a read-only status tool with no annotations, the disclosure is modest but adequate for the simple behavior described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean, efficient sentence that fully states the tool's purpose with zero wasted words. Front-loaded and appropriately sized for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter status check with 100% schema coverage and no output schema, the description is largely sufficient. The only gap is not specifying return values or what 'connected' means precisely, but for a poller status check this is fairly minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there's only one parameter (action) constrained to 'status', which the schema already fully documents. With high coverage, baseline is 3; the description doesn't add extra semantics beyond what the schema states about the action parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific with a clear verb+resource+outcome: returns whether the Telegram bot poller is running and connected. It distinguishes itself from the many gc_* siblings by explicitly stating it's a status check for a specific component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like gc_beat or gc_ticker, which may also relate to system status. There's no when-not-to-use or alternative tool mention, though the specific 'Telegram bot poller' scoping implies it's only for this subsystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the 'tick' action forces a refresh (a behavioral trait) and identifies the underlying source (gc_daemon). However, it doesn't disclose side effects of 'tick' (does it mutate daemon state? is it reversible?), rate considerations, or what the returned snapshot contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose statement first. The action breakdown is compact and readable. Slightly under-specified but efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple one-parameter tool with no output schema and no annotations, the description is adequate but thin. It explains what it does and the action semantics, but doesn't clarify what the snapshot contains, how fresh it is, or why it would be preferred over the many gc_* sibling tools. For a low-complexity read tool this is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the action parameter having an enum and description in the schema. The description restates the enum values but adds the 'default' behavior for 'get' which is genuinely useful. Minimal added value beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the latest ticker state from gc_daemon. 'Situational awareness snapshot' gives context. However, 'ticker' is somewhat vague without defining what data the ticker contains, and sibling tools like gc_beat, gc_timing, and gc_time could overlap in purpose without clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two actions (get vs tick) are explained with 'force a fresh tick' clarifying when to use tick. But there's no guidance on when to choose this over siblings like gc_timing, gc_beat, or gc_cost, and no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the code tools need server-side execution enabled, which is useful, but doesn't disclose error handling behavior, what happens when a tool name doesn't exist, whether there are security/permission implications of dispatching arbitrary tools, or what the response format looks like. For a generic dispatcher that can invoke arbitrary tools, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief classification of tool types. It's front-loaded with the core purpose, then adds the availability distinction for handler vs code tools. Each sentence earns its place, though the ticket reference (GC-2632) adds little value to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic dispatcher with nested objects and no output schema, the description conveys the core usage pattern but leaves gaps: it doesn't explain what the return value is (both for handler and code tools), doesn't cover argument formatting requirements, and doesn't address error cases like invalid tool names. It's adequate for a capable agent but not fully complete for a high-risk dispatch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The description adds context about cwd and session_id being for code tools, which aligns with the schema descriptions. The description doesn't add meaning beyond what the schema provides, but covers the nuance that arguments is a nested object and cwd/session_id are code-tool specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what it does: 'Execute any daemon tool by name through the uniform tool-call surface'. It uses a specific verb (execute), names the resource (daemon tool by name), and references a ticket (GC-2632). It distinguishes from siblings as a generic dispatcher vs. the specific gc_* handler tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Useful when you know the exact tool name and want to dispatch it without a dedicated MCP tool.' It distinguishes handler tools (always available) from code tools (require server-side execution enabled). It lacks explicit when-NOT-to-use guidance or named alternatives, but the intent is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Edit' implies mutation but nothing is said about permissions, reversibility, whether partial updates are OK (only provided fields changed), or what happens when conflicting update fields (e.g., assignee + add/remove labels) are combined. Minimal disclosure, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that conveys the verb, resource, and the primary mutable fields. No wasted words, adequately front-loaded. Slightly more detail on usage or semantics could have been added, but the economy is reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description covers the core action and accepted fields but omits important context: whether updates are partial or full replacement, permission requirements for labels vs assignee, and behavior when no editable fields are supplied (an issue with no mutable fields passed). Acceptable but leaves the agent guessing on edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the 7 parameters carries a description in the schema itself. The tool description adds the behavioral nuance that this is an 'edit' targeting multiple mutable aspects (assignee, labels, title, state), but doesn't explain semantics like whether add_labels/remove_labels are mutually exclusive or how assignee interacts with existing assignees. Baseline 3 holds given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Edit a GitHub issue') with a specific list of editable fields (assignee, labels, title, state). This distinguishes it well from gh_issue_view, gh_issue_create, and gh_issue_comment among siblings. It's specific enough though it doesn't name itself as distinct from gh_issue_create beyond the edit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it edits an existing issue (use view/create for other operations), but it provides no explicit when-to-use versus alternatives, no prerequisites, and doesn't enumerate the sibling operations (view, comment, create) it competes with. Adequate but the guidance is only implied by the verbs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the $GH_DEFAULT_REPO fallback behavior, which is useful, but doesn't mention pagination, rate limits, auth requirements, or the format of results. For a read/list tool this is partially adequate since it's clearly non-destructive from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no waste. It front-loads the primary purpose and then provides the fallback detail. Efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 100% schema coverage and no output schema, the description is adequate but not rich. It covers the fallback behavior and filter capabilities but gives no sense of result ordering, whether it returns paginated results, or how label format interacts with the tool. Given the moderate complexity (5 params), a bit more detail (e.g., 'returns most recently updated first') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema—it mentions state, assignee, labels as filters, which mirrors the schema parameters. It does add the fallback note for repo, which overlaps with the schema's description but confirms the behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List GitHub issues' with specific filters (state, assignee, labels), which is a clear verb+resource purpose. It distinguishes reasonably from siblings like gh_issue_view, gh_issue_create, gh_issue_edit as a list operation, though it doesn't explicitly contrast with gh_issue_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filter capabilities and the repo fallback behavior, which gives some usage context. However, it doesn't explicitly state when to use this tool vs alternatives like gh_issue_view, and provides no exclusions or guidance on limiting results beyond what the schema describes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the read/analysis nature implicitly ('Analyze coverage', 'Shows') but doesn't explicitly state it's read-only, doesn't mention that it spans ALL banks by default (a potentially expensive operation), and doesn't describe output format. The analysis nature is implied rather than confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by a compact list of what it shows. All sentences earn their place. Slightly terse for a tool with no annotations, but there's no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema means the description carries more burden. It mentions what the analysis shows (banks with facts, tag distribution, gaps, stale facts) which is decent. However, for a multi-bank analysis tool, it doesn't clarify whether output is a summary vs. detailed dump, any performance implications of running across all banks, or whether 'stale facts' implies destructive behavior. Adequate but with a few gaps given zero annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented in the schema. The description adds 'across all memory banks' to clarify the scope of topic analysis and the 'tag distribution, coverage gaps, stale facts' list gives meaning to what the analysis produces. Notably, the description does NOT explain the 'bank' parameter's role in restricting scope (though schema covers it), but the description's output list adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Analyze coverage for a topic across all memory banks.' It clearly distinguishes this from siblings like gc_recall (retrieval) and gc_retain (storage) by emphasizing analysis/coverage rather than data operations. Lacks a strong differentiator naming specific siblings but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need coverage analysis of a topic) but provides no explicit guidance on when NOT to use it or alternatives. It doesn't clarify the relationship to gc_find or gc_recall for search-style queries. Acceptable but minimal guidance beyond 'use for coverage analysis.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided (no readOnlyHint, no destructiveHint), so the description carries the full burden. It states the action is 'add' which implies mutation (creating a new comment), but it doesn't disclose behavioral details such as whether the comment is appended to a thread, whether it first requires the issue to exist, whether it requires authentication/permissions, or what it returns. For a write tool with zero annotation coverage, more behavioral disclosure would be expected, but the mutating intent is at least unambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero wasted words. It states the complete purpose efficiently and has no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 required params, no nested objects, no output schema). Given this modest complexity, the description plus schema is minimally adequate. However, it lacks context about what the operation returns, whether the comment appears immediately, or whether an existing issue is verified, and there are no sibling-differentiating hints. For a simple mutation tool without annotations, it meets the minimum but doesn't excel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters (body, repo, number). The schema descriptions are reasonably informative, including the notable note on repo ('a write never infers its target'). The description adds no additional parameter context beyond the schema, so the baseline of 3 is appropriate — the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a GitHub issue' clearly states the verb (add) and resource (comment on a GitHub issue). It distinguishes from siblings like gh_issue_create (creates issues vs comments) and gh_issue_edit (edits issues). It's specific enough to convey the action, though it doesn't elaborate on whether it appends a new comment vs updating, which makes it slightly less than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or when-not-to-use guidance. It doesn't contrast with gh_issue_create or gh_issue_edit, so an agent must infer that this tool is for threading a new comment onto an existing issue. The comment-targeting context is implied by the tool name and resource ('issue'), but there's no explicit alternative guidance or prerequisite note (e.g., 'issue must exist').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the action dispatch model and includes a validate action for package integrity, which is helpful. However, it doesn't describe return formats, pagination behavior, error cases (e.g., missing doc), or whether guide results are ordered/ranked, leaving behavioral expectations partially unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose followed by a compact action list. Each action is a single line with parenthetical qualifiers. It's slightly long with the enumerate actions but each earns its place since the action parameter drives behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter dispatcher tool with no output schema, the description covers all six action modes and which parameters apply to each. It would benefit from a note on what results look like (ranked guides, raw template bodies) but the per-action qualifiers provide reasonable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 9 parameters. The description adds marginal value by mapping each parameter to specific actions ('id/path for get', 'name for template', 'topic for guide'), which reinforces but doesn't fundamentally extend the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the gc_daemon user manual and enumerates the specific actions (search, get, list, guide, template, validate). It distinguishes from knowledge-memory siblings (gc_recall, gc_retain) by specifying it's the packaged manual, though it doesn't explicitly name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening line gives strong usage guidance ('whenever you need authoritative help with daemon setup, configuration, workflows, templates, or troubleshooting'), and the action list clarifies which action fits which need. However, it doesn't explicitly contrast with sibling tools like gc_recall or gc_find, nor state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose that this is a 'relay ingress' that sends messages and can create new sessions, and mentions the daemon-owned default agent (charon). However, it does not disclose any side effects of creating a session, whether operations are reversible, permission requirements, or what happens when a session already exists with a given session_id. Moderate disclosure but gaps remain for a message-mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tight and efficient. Covers purpose, behavior (send vs create), and the default agent. No waste, though it could arguably add more params explanation without hurting brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Schema covers all 4 params at 100%, so parameter documentation is complete. However, no annotations and no output schema means the description should carry more runtime behavior context. It does not explain the relationship between session_id and config (e.g., config only applies when creating), nor what the response contains or failure modes. For a tool that mutates state by creating sessions, this is a partial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds 'default charon' context that clarifies the agent param's default, and notes sessions can be created vs. reused which maps to session_id/config semantics. It adds marginal value beyond the schema, particularly the charon default which is genuinely helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Relay ingress for external peers... Sends a message to an existing agent session or creates a new one.' This distinguishes the tool from siblings like gc_recall, gc_retain, and gc_reflect (which are clearly different operations). The mention of Pluto as an example external peer adds concrete context. Well-scoped and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No direct sibling differentiation is given - it doesn't say 'use this instead of X' or 'when not to use'. However, the phrase 'for external peers' establishes a clear intended context, and the distinction between send-to-existing and create-new is implicit guidance. It lacks explicit exclusion context or alternative tool mentions, which matters given the large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. The description explains the cron-vs-legacy conversion behavior and notes that legacy params are deprecated but still accepted, adding useful behavioral context. However, it doesn't disclose side effects for mutating actions (create/disable/delete/fire), return formats, or error behavior for a tool with many mutating actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: actions, trigger types, and a detailed cron section with examples. The cron examples are valuable and worth the space. However, it is somewhat long, and the coverage of cron formatting could be considered slightly verbose relative to the broader tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with no output schema and no annotations, the description covers the core action/trigger semantics well, especially the complex cron syntax. It's not fully complete — it doesn't clarify which parameters are relevant to which actions (e.g., what create requires vs disable), and the 8 distinct actions have significant combinatorial complexity that isn't addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does add meaningful value for cron/legacy param semantics, going well beyond the schema's brief descriptions. However, many parameters (agent, task, issue, action_type, fire_at, cwd) remain documented only at the schema level with no elaboration on how they combine per action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages scheduled agent dispatches, with an explicit action list (list, create, enable, disable, delete, history, fire, tick) and trigger types (cron, interval, session_start, once). It uses a specific verb+resource pattern that distinguishes intent, though it doesn't explicitly contrast with siblings like gc_ticker or gc_timing which could relate to scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is heavily focused on 'when to use cron vs legacy params', explaining that cron is preferred and detailing exactly what the legacy params cannot express (day-of-month, month-of-year, ranges). This is strong guidance for the primary decision point in using this tool, though it doesn't address when to choose this tool over sibling scheduling tools like gc_ticker or gc_timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals search bypasses project_id tagging, punctuation-only queries return annotated empty results, list returns `total` pre-limit count, and ready has no default. This adds meaningful behavioral context beyond names, but doesn't discuss mutation effects, permission requirements, or what dependencies/DAG state changes look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact for a 20-parameter, 19-action tool, but front-loads a dense action list that is somewhat redundant with the enum in the schema. The essential guidance about search, ready, and plan is packed at the end, and some param context (search punctuation behavior, limit semantics) could be trimmed since these are also documented in the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-action, 20-parameter tool with 100% schema coverage and no output schema, the description covers the critical usage patterns (search for dedup, ready for unblocked, plan for critical path) reasonably well. However, it doesn't explain return-value structure or describe what most of the 19 actions produce, and with no output schema the agent must guess the shape of results for many actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping actions with their relevant params (q for search, days for stale/focus, dry_run for backfill_projects, limit defaults per action, include for show comments). It also explains action-specific defaults like list default 50/cap 500 and search default 10/cap 50, and clarifies punctuation-only search behavior, going beyond a bare parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Work coordination with dependency DAG' and enumerates 19 action verbs, making the purpose clear. It distinguishes from siblings like gc_plan (issue planning) and gc_workflow (workflow orchestration) by focusing on task issues with dependencies, but doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives concrete usage guidance: 'Use action=search to check if an issue about a topic already exists (FTS, ranked, matches title+description regardless of project_id tagging) instead of listing the whole DAG.' Also recommends 'ready' to see what's unblocked and 'plan' for critical path. However, it doesn't explicitly say when NOT to use this tool vs. gc_plan or gh_issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses some behavioral traits (non-SSE history read vs SSE live tail, events collect until terminal or timeout), which is helpful. However, it doesn't disclose what 'abort' really does, error conditions, auth requirements, or side effects of the control action — meaningful gaps for an operator-control tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with an intro line plus three short bullets. Every sentence earns its place, and the action names map directly to the enum values, making navigation effortless. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does a good job covering the three-action surface and mapping parameters to actions. However, with no output schema and no annotations, it doesn't describe return shape, error behavior, or the semantics of seq-based event history, leaving the agent somewhat under-informed about what to expect from each call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains all 8 parameters. The description adds some multi-action context by noting which params apply to which action (since for events/watch, timeout/heartbeat for watch, reason/control_action for control). This maps parameters to actions usefully but doesn't go deep on format or behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it handles 'Observable run control and event history' with three distinct actions (events, control, watch), each briefly explained. It's specific about the resource (run) and the operations, and the compact bullet format distinguishes the three sub-modes from each other. Slight downgrade because the sub-actions within one tool make the overall purpose somewhat composite rather than singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Each action has a one-line usage context: events is a 'non-SSE history read', watch is 'SSE live tail' collecting until terminal or timeout, control is operator abort. This distinguishes when each sub-action applies, though it doesn't explicitly tell when to prefer gc_run over siblings like gc_timeline or gc_workflow_watch, which could overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 matching behavior (scored against aliases, name, slug, intent tags; project-scoped preferred; mode biases baseline/deep) and lifecycle actions (create/update/deprecate implying mutation). However, it doesn't mention side effects, required auth, or whether mutations are reversible—moderate disclosure for a multi-action registry tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections ('Key actions', 'Matching behavior') and front-loaded purpose. It's efficient but slightly long given the schema already documents parameters well. The action breakdown and matching rules earn their place, though some duplication with schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and 7 possible actions, the description covers the action taxonomy and matching behavior well. However, it lacks guidance on what each action returns (no output schema exists to compensate), prerequisites for create/update/deprecate, and cross-action parameter requirements. It's complete for discovery but incomplete for safe invocation of mutation actions. Moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the individual parameter descriptions in the schema are already detailed (mode, scope, status, defaults like 'suggest defaults to 5, list defaults to 20'). The description adds cross-parameter context by explaining how action orchestrates the others (e.g., task required for suggest/resolve, name for create, slug for show/update/deprecate). This goes somewhat beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'GC-native procedural skill registry' with a specific 'Key actions' list distinguishing suggest, resolve, list/show, and create/update/deprecate. It distinguishes from siblings like gc_recall (recall memory) and gc_project_registry (project data) by focusing on reusable procedures. However, it doesn't name alternative tools explicitly, so it gets a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: 'Use this when you want to know whether GC already has a reusable procedure for a task before inventing a new workflow.' It differentiates suggest from resolve ('safe yes/no pick') and explains list/show vs create/update/deprecate. It lacks explicit 'when not to use' exclusions or named alternatives, so it misses 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It states it returns 'full body and comments,' which is useful behavioral info about output content. However, it doesn't disclose pagination behavior for large comment threads, rate-limit considerations, or what happens with not-found issues. For a read-only viewing tool, this is acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Every word earns its place — the verb, resource, and return scope are all captured. This is an example of appropriate conciseness for a straightforward single-resource view tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view tool with 100% schema coverage and no output schema, the description covers the essential details: what it does, what it returns. There's no complexity requiring extensive documentation. The description is complete enough for an agent to select and invoke this tool correctly, guided by the schema for parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema. The description adds the 'full body and comments' detail but doesn't add parameter-level meaning beyond the schema. However, with 100% coverage and only 2 simple params (number, repo), the schema already does the heavy lifting, so a baseline of 3-4 is appropriate. The description confirms the scope of what gets returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'View a single GitHub issue with full body and comments' uses a specific verb (view) and clear resource (single issue) with notable scope (full body and comments). It distinguishes from siblings like gh_issue_create and gh_issue_comment, though it doesn't explicitly name them. It's clear but could explicitly differentiate from gh_issues (which lists issues).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for viewing one issue's full content, which contextually contrasts with gh_issues (listing). However, there's no explicit when-to-use or when-not-to-use guidance, no mention of whether it requires the repo param or defaults, and no alternatives named. The schema documents the repo default but the description itself provides little usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses meaningful behavioral traits: upsert 'supports partial payloads' and 'metadata is merged', and sync pulls 'from ~/.config/gc/registry.toml into the registry DB'. These reveal merge semantics and the sync source path, which is valuable behavioral transparency for an otherwise 24-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a leading summary line followed by a bulleted action list and a closing guidance sentence. It's front-loaded and wastes no words. Minor deduction: the action list overlaps with the schema's enum which is already self-documenting, though the brief per-action glosses do add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter tool with no output schema and no annotations, the description does a solid job: it enumerates actions, highlights merge semantics for upsert, and explains the sync source. However, it doesn't describe the return format for list/get/repos actions, what happens on sync conflicts or failure, or destructive implications (e.g., does upsert overwrite all fields or only provided ones?). Slight gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema thoroughly documents all 24 parameters. The description adds a small amount of extra meaning (upsert supports partial payloads with merged metadata), but otherwise the semantics are carried by the schema. At this coverage level, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's the 'Canonical project registry for Grand Central' and enumerates five concrete actions (list, get, upsert, sync, repos) with specific semantics. It also distinguishes itself from alternatives by stating it should be the 'source of truth' for project metadata and to 'prefer over maintaining sidecar maps'. This is a specific verb+resource tool with clear action enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance to use this as the source of truth for project metadata (repo paths, canonical docs, related projects, strategy-sync metadata) and explicitly says to prefer it over sidecar maps. However, it doesn't explicitly name sibling tools to use instead, only generically references 'maintaining sidecar maps' and doesn't state when NOT to use it in favor of specific alternatives among the many gc_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses that directives are 'injected into agent context automatically', that remove is a 'hard delete', deactivate is 'soft' with later reactivation, and that confirm:true is required for pinned removals. This is meaningful behavioral context that goes beyond the enum values in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the vocabulary named first and the action enumeration efficiently packed into one sentence. It's slightly dense — the action list is long and could benefit from being formatted as bullets — but every sentence carries meaningful content with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with 100% schema coverage and no output schema, the description covers the action semantics, scope behavior, persistence vocabulary, and confirmation requirements well. It could add more about what 'inject' returns or how list results are formatted, but given the schema already documents every parameter, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by tying parameters to actions (id for remove/deactivate/reactivate, content for add, expires_at for @until, query for inject, confirm for pinned). This cross-referencing between actions and the parameters that apply to them adds genuine value over the flat schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages behavioral directives using a specific vocabulary (@always/@never/@stop/@pin/@until). It names the exact actions available and their semantics. The verb 'manage' plus the explicit vocabulary and scope ('scoped to specific agents or global') makes the purpose specific and effectively distinguishes it from sibling memory tools like gc_recall and gc_retain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates all six actions with one-line definitions, giving clear context for when to use each sub-operation. However, it doesn't explicitly state when to prefer gc_control or gc_hindsight over this tool for related directive/behavior tasks, nor does it name alternative tools explicitly. The action list is a strong usage guide but lacks cross-tool exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses durable mailbox creation and unread/read semantics, but does not say what happens on push after drain, how duplicates or re-delivery are handled, or any failure/error behavior. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, then the actions, then the integration pattern. The use of bullets and the integration steps is well structured. It's slightly verbose in the trailing 'daemon guarantees' sentence which could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and 7 params, this covers the core integration flow well. It explains the checkpoint-driven polling contract, which is the most important behavioral context. Missing details include return format and error handling, but for a mailbox abstraction the polling loop guidance is the critical piece and it's present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds two values: the 'drain' action's checkpoint semantics (since) and the 'harnesses decide how to surface drained events' guidance. It also contextualizes the push/drain/list actions against their parameters, adding meaning beyond the plain schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'notification mailbox for durable consumer polling' with the three actions (push/drain/list) explicitly enumerated. It distinguishes from siblings by describing a specialized durable mailbox with unread/read semantics, which no sibling name suggests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 4-step recommended integration pattern (persist checkpoint, drain with since, handle events, advance checkpoint). This is strong alternative-usage guidance that tells the agent exactly when and how to invoke the drain action within a consumer loop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It transparently flags this as a maintenance/emergency operation rather than a routine read, implying it could disrupt service or take time. The warning about severity of use ('not a daily tool') is valuable behavioral context. It doesn't disclose side effects (e.g., index downtime, rebuild duration), but does reasonably communicate that this isn't a safe routine operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler. The first sentence states the action, the second gives the triggering condition, the third adds the operational caution. Front-loaded and efficient with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple maintenance tool with no parameters and no output schema, so the description is nearly complete for the agent's needs. It explains what triggers use and flags it as non-routine. It could mention whether results are returned or confirm the operation, but for a fire-and-forget maintenance tool the gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema coverage is 100% (empty properties object). With no parameters to document, there's nothing the description needs to add. The description correctly focuses on usage guidance rather than pseudo-documenting nonexistent parameters. This is a clean baseline-4 scenario, and since there are literally zero parameters to explain, a 5 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear purpose: emergency rebuild of the memory-bank FTS5 index, used when recall/search returns stale results. The verb 'rebuild' plus the 'FTS5 index' resource is specific and clearly distinct from siblings like gc_recall, gc_retain, and gc_find. It loses a point for not naming an alternative tool that would serve the stale-results scenario, but it does distinguish itself functionally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives explicit when-to-use context: 'when recall/search is returning stale results despite facts existing in the bank.' It also frames it as 'a maintenance operation, not a daily tool,' which imparts an important usage qualifier. It doesn't name specific alternative tools to use instead, but the caution against routine use is genuinely useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well. It discloses distinct behavioral traits: superseded facts are EXCLUDED by default, each fact may include a superseded_by field, the fallback to deep-memory only occurs if local results are absent and the backend is available, and mode behavior is spelled out (pure BM25 debug for full, HS-imports for deep). Missing are details on pagination, exact cost boundaries, or error behavior, but the coverage is strong given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured and front-loads the core purpose and key differentiator (instant, zero cost). Sentences earn their place: the FTS5/BM25 note, the fallback behavior, the exclusion default, and the audit use case are all substantive and non-redundant. It's slightly longer than minimal but every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 parameters and no output schema, the description covers the essential behavioral context: result ranking, bank attribution, supersession handling, backend fallback modes, and audit use cases. Without an output schema, the description notably compensates by describing what returns look like (ranked facts, superseded_by field, match scores). Slightly more could be said about interaction with gc_banks or timeout/cost expectations, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 6 parameters are documented in the schema itself. The description adds marginal value beyond the schema by elaborating on the hindsight fallback semantics and the include_superseded superseded_by field, but these largely mirror what the schema already declares. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ("Search the memory bank for facts") and immediately distinguishes this from siblings by highlighting performance characteristics (FTS5/BM25, instant, zero cost) and the deep-memory fallback. It covers ranking, attribution, and match scores, giving a complete picture of what the tool does and its unique value among the gc_* memory/search family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use include_superseded (historical audits) and when not to (default current truth only). It also distinguishes the local fast path from the expensive deep-memory fallback, giving clear guidance on when the tool is cheap vs expensive. The mode parameter is explained across linear/deep/full semantics, giving the agent clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does a good job explaining the three action modes (status/preview/apply), the 'live-safe' distinction, and that all_safe excludes dangerous-sync and restart-required targets. It could add more about side effects or rollback behavior, but for a reload tool the safety semantics are reasonably disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear action/target/use-after/legacy sections. It's longer than minimal but every section earns its place — the target list is useful despite being partially redundant with the schema. The use-after section is the most valuable addition. Slightly verbose with the full target enumeration repeated, but structurally sound and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no required parameters, and no output schema, the description is thorough. It covers actions, targets, legacy compatibility, and usage scenarios. It doesn't explain return values or error behavior, but given no output schema exists, some guidance on what preview/apply return would strengthen it. Overall quite complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters have documented descriptions in the schema. The description adds value by enumerating target examples and clarifying the legacy vs modern target naming (telegram vs telegram_routing, etc.), and explains the all_safe expansion semantics beyond what the schema offers. This aligns with the baseline 3 for full coverage, with modest added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Runtime config reload control plane' with specific verbs for actions (status, preview, apply). It lists concrete target examples and distinguishes itself from siblings by being the config reload mechanism among gc_* tools. The verb-action pairing and resource targets are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use after: editing secrets.toml or YAML config, swapping models in LM Studio, rotating API keys, updating workflow definitions...' which gives clear when-to-use guidance. It also documents legacy section names for backward compatibility, helping the agent decide between target vs section parameters. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 this is an SSE/streaming watch mode, that it terminates on settle/timeout/abort, and mentions the client can abort. However, it doesn't describe auth requirements, what happens if the workflow is already settled when watch begins, or how stream events are batched or ordered beyond the 'since' seq parameter. The core behavioral traits are disclosed but some edge behaviors are underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences. The first states what the tool does (live SSE watch, event collection, terminal conditions). The second provides the alternative. Zero wasted words, fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a streaming watch tool with no output schema, the description conveys the essential lifecycle: events until settle/timeout/abort, with a simpler polling alternative. The return value is implicit (status events) and the terminal conditions are spelled out. Minor gaps: no mention of what 'settles' means precisely or whether the stream is resumable across aborts, but for a watch tool the core contract is adequately defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 5 parameters are already documented in the schema. The description adds context by explaining the event-collection lifecycle (until settle/timeout/abort) that the parameters operate within, and the sibling alternative clarifies that 'since' and 'timeout' relate to a streaming semantics not present in the polling mode. It adds modest value over the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a live SSE watch of workflow execution that collects status events until settlement, timeout, or client abort. The verb 'watch' plus resource 'workflow execution' is specific and it distinguishes itself from the sibling gc_workflow tool by explicitly naming action=wait as the polling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs when to use this tool ('collects status events until the execution settles, times out, or the client aborts') and provides a direct alternative: 'Use gc_workflow action=wait for a simpler polling alternative.' This names the sibling tool and its specific action, giving clear exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It thoroughly discloses the default fire-and-forget behavior vs wait=true blocking, explains provider route semantics (provider = GC dispatch route, not upstream vendor/CLI binary), clarifies model selection rules, and documents Claude-specific permission flags. There are no annotations to contradict. The one gap: the description doesn't disclose side effects of delete/prune/dismiss operations or auth requirements, but the semantics sections are quite rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense and well-organized with clear sections (Actions, Use cases, Semantics, Provider selection, Model selection, Claude-specific permission controls). It's front-loaded with the core purpose and action list. Some redundancy exists (provider semantics repeated between 'Semantics' and 'Provider selection' sections), but this is minor given the tool's complexity. Given 28 parameters and 13 actions, this length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool (28 params, 13 actions, multiple provider routing schemes) with no annotations and no output schema. The description is remarkably complete: it covers all action types, provider selection nuances, model selection constraints, the fire-and-forget vs wait behavior, Claude permission controls, and the relationship to sibling gc_peer_conversation. Given the complexity, the description is thorough enough for an agent to use nearly every action correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains the distinction between provider routes ('native', 'native:<backend>', 'claude', 'droid', 'pi', 'kimi'), clarifies that model should be a real provider-native id not a transport label, and documents permission_mode values with their CLI flag mappings. This meaningfully enriches the 28 parameters, though the description doesn't touch every parameter individually (e.g., issue, limit, since_hours defaults).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the tool as 'on-demand agent dispatch' with a clear list of 13 actions (dispatch, list_agents, list_providers, list_models, resolve_dispatch, etc.), each with a parenthetical explanation. It clearly states the default fire-and-forget behavior and distinguishes from the sibling gc_peer_conversation which handles ongoing dialogue. This is a specific verb+resource definition with strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use gc_dispatch for assignments and runnable work' and directly names the alternative: 'If you want an ongoing dialogue with an external A2A peer... use gc_peer_conversation instead.' It also gives action-oriented instructions like 'Do not inspect past sessions to guess provider/model defaults. Use list_agents, list_providers, list_models, and especially resolve_dispatch instead.' This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, and it mostly delivers: it discloses persistence, non-job-oriented semantics, absence of dispatch audit rows, local transcript preservation, and remote A2A context/threading reuse. Missing: no mention of rate limits, auth requirements, or failure/error behavior, but the core operational model is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear headers (Actions, Important semantics, Typical flow). The two-line semantic bullets are dense and informative. The typical flow section is concrete and actionable. No redundancy with schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with a nested config object and no output schema, the description is thorough: it covers all actions, parameter requirements, semantics, and gives an end-to-end example. The one notable gap is not describing the structure/content of responses (e.g., what a 'turn' reply contains), which matters since there's no output schema to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond the schema: it clarifies that peer_agent must be a registered A2A peer name, that session_id applies to turn/get/delete, and that message is required for turn. It also explains config's purpose (stored at creation) and the role of agent as an alias for peer_agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence nails it: 'Persistent chat-style sessions with external A2A peers such as Pluto.' It names the resource (peer conversation sessions), the domain (chat/dialogue), and the key differentiator (persistence, A2A peers). The action list further disambiguates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Exceptionally explicit: states when to use (dialogue, clarification, synthesis, coordination), when NOT to use ('Do NOT use gc_dispatch for conversational turns'), and contrasts with gc_dispatch's job-assignment role. The typical flow section reinforces correct usage with a concrete sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and discharges it thoroughly: it details sync vs async behavior (Oban persistence, crash-resume semantics), the response-shaping default walk-past-nil logic, per-action return shapes, timeout defaults (300s for run vs 15s others), and that async survives daemon restart. This is rich, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but justified given the tool's 17 actions and complex response shaping. It's well-structured with clear section headers (Actions, Response shaping) and scoped bullet lists. A few redundancies exist (list/get_execution aliases and execution_id/id aliases are restated), but overall it front-loads the most important info and organizes the rest coherently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 20-parameter, 17-action tool with no output schema and no annotations, the description is remarkably complete: it details every action, the response-shaping variants, timeouts, async semantics, and failure recovery. The tool is genuinely complex and the description rises to that complexity. The only minor gap is it doesn't document the YAML step-type pipeline format in depth (tool/prompt/dispatch/shell/each/branch/halt), but those are named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains the 'result'/'full'/'steps'/'trace' return-shape semantics, the 'select' priority behavior, the walk-past-nil default, and the 'walk-past-nil' last-step logic. It also clarifies timeout default durations which the schema only states generally. However, some params (interval, force, include_hidden, older_than_hours, dry_run) are only clarified by the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource ('Run deterministic workflows from ~/.config/gc/workflows/') and immediately enumerates the 15+ distinct actions available, distinguishing the tool's multi-action surface clearly. The structured action list with per-action semantics makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear per-action guidance on when to use each action (run, list_workflows, show, resume, wait, watch, cancel, etc.). However, it doesn't explicitly name sibling tools as alternatives (e.g., gc_workflow_watch exists as a sibling for watching, and the description doesn't reference when to use gc_workflow vs gc_workflow_watch vs gc_run). That gap on cross-tool exclusions keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden and exceeds it. Documents the response contract ('stored', 'duplicate', 'existing_id' fields), warns that 'ok: true' doesn't mean storage happened, explains dedup semantics (fingerprint only, supersedes bypass), and clarifies what supersedes does to recall visibility. Exceptionally transparent about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headers (Deduplication, Response contract, Supersedes + recall). Content is dense but organized. Slightly long for a tool description but every section earns its place — critical behavioral details that prevent data-loss mistakes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
8-parameter mutation tool with no annotations and no output schema — the description compensates fully. Documents all critical edge cases: dedup behavior, response contract, supersedes semantics, and recall interaction. An agent would know exactly what to expect from invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds value beyond schema: clarifies 'supersedes' bypasses dedup (a behavior nuance not in the schema), defines 'origin' values, and explains the routing behavior for 'bank'. Doesn't list every param but the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Store a fact in the memory bank.' Specific about auto-routing behavior ('Auto-routes to the best bank by keyword matching, or specify a bank'). Distinguishes from siblings like gc_recall (retrieval) and gc_banks (bank introspection) by its storage focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly documents when supersedes should be used ('an explicit replacement signal always stores'), when fingerprint dedup blocks storage, and how to retrieve historical versions ('Use recall with include_superseded: true'). Provides concrete behavioral contracts for decision-making. Notes the removal of fuzzy/BM25 dedup and its rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gc_mcp MCP server](https://glama.ai/mcp/servers/fosferon/gc_mcp/badges/card.svg)](https://glama.ai/mcp/servers/fosferon/gc_mcp)

Score Badge

Copy to your README.md:

[![gc_mcp MCP server](https://glama.ai/mcp/servers/fosferon/gc_mcp/badges/score.svg)](https://glama.ai/mcp/servers/fosferon/gc_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fosferon/gc_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server