AI Process Manager

by aipm-engine

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose and resource/action, with overlapping pairs (e.g., check_process vs. list_processes, list_windows vs. get_taskbar) explicitly disambiguated in their descriptions. The ui_* tools are further segmented by operation (find, read, invoke, set_value), leaving no ambiguity.
Naming Consistency4/5
Tool names predominantly follow a verb_noun snake_case pattern (get_, list_, check_, report_), but a few deviations like 'health_check' and 'wait_for' break consistency. The ui_* prefix creates a coherent subgroup, though it mixes verb positions (ui_find vs. ui_set_value).
Tool Count4/5
At 20 tools, the server is on the heavy side but each tool earns its place given the combined scope of process monitoring, UI automation, and telemetry. The count slightly exceeds the comfortable 3-15 range but is not bloated.
Completeness4/5
The tool set covers core workflows: observing processes/windows, reading and interacting with UI, waiting for conditions, and reporting outcomes. Notable gaps include lack of direct process start/termination and no file management beyond single-file checks, which agents may need to work around.
Average 4.3/5 across 20 of 20 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on July 26, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the point-in-time 'snapshot' behavior and the exact list of metrics, but does not disclose edge cases like GPU absence or permission requirements.
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 a single concise sentence that front-loads 'Machine snapshot' and efficiently enumerates all returned metrics. Every word adds value with no unnecessary content.
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 zero-parameter, read-only tool with no output schema, the description provides a thorough list of return contents. It is sufficient for an agent to understand what to expect, though it omits minor format details that are not critical.
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?
The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are required, and there is no parameter redundancy to penalize.
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 tool as a 'machine snapshot' and enumerates the specific metrics returned (CPU%, RAM, GPU, disk, network, uptime, displays). It is clear but does not explicitly distinguish from sibling tools like health_check or list_processes.
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 provided on when to use this tool versus alternatives such as health_check or get_audit_log. The description is purely informational and lacks any contextual or exclusionary cues.
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?
Annotations already indicate a read-only, non-destructive operation. The description adds valuable behavioral context beyond that: the log works even when the API is paused, and secrets (api_key=, value=) are masked before being recorded. This discloses privacy and availability characteristics that annotations do not cover.
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 concise, but contains four sentences rather than the ideal two. Each sentence adds valuable information (purpose, availability, use cases, masking behavior), and it is properly front-loaded with the main purpose. No redundant or fluff content.
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?
The tool is simple (one optional parameter, no nested objects). The description explains what the log contains (which agents called which endpoints and when), its availability, and its intended use cases. It does not describe the return format, but the output is implicitly an audit log list, and the lack of an output schema is not a critical 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?
The input schema fully documents the only parameter 'limit' with its description and defaults. Since schema coverage is 100%, the description does not need to add parameter details. No additional semantics are provided, which is acceptable given the high 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 states the tool retrieves a recent API audit log showing which agents called which endpoints and when. It has a specific verb ('get') and resource ('audit log'), and the details make its function unambiguous. It does not explicitly distinguish from siblings, but no sibling covers audit logs, so this is adequate.
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 context for when to use the tool: 'For compliance and debugging agent behavior.' It also notes a unique capability ('Works even when the API is paused') that differentiates it. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient.
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?
Given annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false, the description adds useful context about permission requirements ('action tier + app allowlist'). However, it does not disclose behaviors like parameter precedence when both hwnd and title_contains are provided.
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 concise and front-loaded with the primary purpose. The second sentence adds a critical requirement without unnecessary detail.
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?
The tool is relatively simple with two optional parameters and no output schema. The description covers purpose and permission, and annotations cover safety and idempotency. Missing details about behavior when no parameters or both parameters are provided, but overall it is reasonably 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?
The input schema already provides full descriptions for both parameters (100% coverage). The description adds no additional meaning about parameter usage or relationships beyond what the schema states.
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 action ('Bring a window to the foreground') and the resource (a window). This distinguishes it from sibling tools like list_windows or read_window, which have different purposes.
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 a prerequisite ('REQUIRES action tier + app allowlist') but does not explain when to use this tool versus alternatives such as ui_set_value or read_window, nor does it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details: it can detect file locks and identify the locking process, and it performs checks without opening Explorer. This goes beyond the annotations but doesn't cover error behavior or permissions.
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 concise sentences front-load the key information and provide an example use case. Every word earns its place with no redundancy.
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 one-parameter, no-output-schema tool, the description is fairly complete. It lists the specific status fields and the ideal use case. However, it doesn't explicitly state return format or error conditions, which would make it fully 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?
The schema provides comprehensive documentation for the single 'path' parameter, including an example. The description adds no further parameter meaning beyond what the schema already covers, so the baseline score of 3 applies.
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 checks file/folder status including existence, size, last modified, locked state, and locking process. This specific verb+resource combination distinguishes it from siblings like check_process and get_system_status.
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?
Provides a clear use case ('checking if a render/export finished') and implies the tool avoids opening Explorer. However, it does not explicitly mention alternatives or when not to use it, so it falls just short of a 5.
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?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: it uses UI Automation, works with specific app types, and requires window identification via title_contains or hwnd. This goes beyond the annotations without contradicting them.
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 two sentences, front-loaded with the core function and key differentiator. The second sentence provides a concrete example and parameter guidance. No unnecessary words.
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?
The description is sufficient for a read-only tool with full schema coverage and annotations. It covers what it does, how it works, when to use it, and how to identify the window. It does not explicitly describe the return value, but the absence of an output schema and the 'read text' phrasing make the output implicit.
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 parameters are already well-documented. The description adds minimal extra meaning beyond repeating the identification methods from the schema. It does not explain max_chars behavior beyond the schema's default, so the baseline score of 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 the tool reads text from a window via UI Automation and explicitly distinguishes it from screenshots. It also specifies supported targets (consoles, editors, native apps) and a typical use case, making the purpose unambiguous and distinct 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (e.g., reading render progress) and explicitly mentions the 'no screenshot' approach, which implies an alternative. It also references list_windows for obtaining hwnd, but does not explicitly name alternative tools or exclusion 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds meaningful behavior: 'Metadata only — never screen content or typed text' clarifies privacy constraints. It also discloses that failures become common_failures for future agents. This goes beyond the annotations without contradicting them.
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 three sentences long, front-loaded with the core purpose, and every sentence adds distinct value: what it does, how it feeds into recipes, and the importance of reporting failures. No filler or redundancy.
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 telemetry tool with 7 parameters and no output schema, the description covers the essential aspects: purpose, timing, and data sensitivity. It lacks details about return values or potential side effects, but these are less critical for a reporting tool. The schema and annotations fill remaining gaps.
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 parameters are individually described in the schema. The main description adds context about the purpose of ok=false and reason (e.g., 'they become common_failures'), which enriches understanding. However, it does not provide per-parameter details beyond what the schema already offers, so it stays at the baseline.
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 'Report one UI action outcome (invoke/set_value/focus)', which is a specific verb and resource. It also mentions 'Feeds per-app recipes in get_app_knowledge', distinguishing it from sibling tools like report_task_outcome. The purpose is unambiguous and well-scoped.
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 implies when to use it: after a UI action, report its outcome. It explicitly instructs to 'Report FAILURES too (ok=false plus reason)', giving concrete usage guidance. However, it does not explicitly contrast with report_task_outcome or name alternatives, so the guidance is not fully explicit.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds valuable context: the action-tier/allowlist requirement, the method (UI Automation, no key simulation), the limitation with modern apps (e.g., Win11 Notepad), and the recommendation to confirm with the user. This goes beyond annotations without contradicting them.
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 three sentences, front-loads the core purpose, and each sentence contributes essential information: what it does, requirements, caveats, and user confirmation. No wasted words, and the structure is clear and scannable.
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 mutation tool with 5 parameters, no output schema, and annotations present, the description covers the core purpose, requirements, limitations, and a usage precheck. It doesn't describe error behavior or return values, but given the tool's simplicity and the annotations, this is reasonably complete. A brief note on success/failure output would make it fully 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 the baseline is 3. The description adds minimal extra meaning beyond the schema: it clarifies that the value is set via UI Automation and mentions field exposure issues, but doesn't elaborate on individual parameters. The schema already documents all five parameters adequately.
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 function: 'Set text in an editable field via UI Automation.' It uses a specific verb ('Set') and resource ('editable field'), and distinguishes from siblings by noting it does not use key simulation and referencing ui_find as a precheck. This makes the purpose unambiguous and distinct from 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it requires action tier + allowlist, instructs to check can_set_value in ui_find, warns that modern apps may not expose fields, and advises confirming with the user first. While it doesn't explicitly name alternatives for non-text actions, it gives strong when-to-use guidance and prerequisites.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: it is a long-poll with a 50s cap, and multiple calls may be required. This goes beyond annotations by explaining the blocking and retry nature.
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 three sentences: it states the primary purpose, lists conditions, and gives the critical timeout/retry caveat. Every sentence earns its place with no redundancy or 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?
The description covers purpose, conditions, timeout limit, and retry behavior. It does not explicitly describe the full return value shape beyond mentioning 'satisfied=false', and there is no output schema, but for a simple waiting tool this is sufficiently 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?
The input schema provides 100% coverage with descriptions for all 7 parameters, so the schema carries the burden. The description adds marginal value by interpreting 'file_stable' as 'render/download done' and referencing the timeout, but does not add significant new semantics.
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 'Long-poll until a condition is met (or timeout)' and lists specific conditions (process_ended, process_started, file_stable, file_exists, window_title_contains). The phrase 'Replaces polling loops' distinguishes it from sibling tools that perform immediate checks, giving specific verb+resource+scope.
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?
It provides clear context for when to use it: 'Replaces polling loops' and 'if satisfied=false, call again to keep waiting'. However, it does not explicitly name alternatives or state when not to use the tool, so it lacks full 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: that ui_shape may be returned even when known=false, and that the data was learned passively from earlier reads. This explains what to expect from the tool beyond the structured 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 a compact but information-dense paragraph. Each sentence serves a purpose: purpose, usage timing, ui_shape caveat, and parameter guidance. It is not overly terse, and the structure flows logically from main purpose to additional details. Slightly verbose but every sentence earns 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?
With no output schema, the description carries the burden of explaining return values. It covers the main data types (recipes, common_failures, ui_shape) and the known=false case. It does not detail the exact JSON structure, but for an AI agent this level of context is sufficient to understand what the tool returns and how to use it.
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?
The schema already covers the 'name' parameter with an example, but the description adds 'Pass the process name as shown in task manager,' which clarifies the exact format expected. This is meaningful addition beyond the schema, and schema coverage is 100%, so the baseline is already high.
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 queries learned knowledge about an app, specifying the content: successful action recipes and common failures. It distinguishes itself from sibling tools like read_window or get_ui_tree by focusing on learned knowledge rather than direct UI reads. The verb 'Query' and resource 'what AIPM learned locally about an app' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call BEFORE acting in an app,' which is clear when-to-use guidance. It also tells the agent not to retry common_failures, which is actionable context. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the 24-hour time window and that process_ended events include duration, which are not present in annotations.
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, front-loaded with the core functionality (last 24h of PC events) and event types, followed by a practical use case. No redundancy, every word earns its place.
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?
Annotations cover safety, schema documents parameters, and the description explains the time scope and event types. For a simple read-only list tool, this is complete enough for an agent to select and invoke 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 both parameters (type, limit) are already documented. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 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 states a specific verb ('get') and resource ('recent events'), and lists concrete event types (process_started, process_ended, window_focused, file_changed). This clearly distinguishes it from sibling tools like list_processes and get_audit_log.
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 an explicit use case ("what happened while I was away") with a concrete example ("when did the render finish?"). This gives clear context for when to use the tool, though it does not explicitly mention alternatives or exclusions.
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?
Annotations already declare this as a safe, read-only operation (readOnlyHint: true, destructiveHint: false). The description adds valuable behavioral context by specifying the output structure (pinned apps, running apps, window titles) and the 'human' formatting aspect. It does not contradict the read-only hint, and it provides more concrete behavioral detail than the annotations alone.
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 a single, front-loaded sentence that immediately states the purpose and key output details. Every word earns its place—no filler, no redundancy. It is an ideal length for the tool's simplicity.
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?
Given the tool's simplicity (no parameters, no output schema), the description is fully sufficient for an agent to know what the tool returns and when to use it. It describes the taskbar's composition (pinned apps, running apps, window titles) sufficiently well within its context.
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?
The tool has zero parameters, and the schema coverage is 100% (identical). Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to clarify. The description does not need to add parameter info because there are none.
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 identifies the resource (taskbar) and the specific content (pinned apps, running apps, grouped window titles). The term 'Human view' implies a user-friendly representation, distinguishing it from sibling tools like list_windows or get_ui_tree that serve different UI introspection purposes.
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 for obtaining a taskbar-centric view, but it does not explicitly state when to use this tool versus alternatives such as list_windows or get_ui_tree. There are no explicit exclusions, alternative tool names, or prerequisite conditions, so guidance is only inferred.
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?
The description goes well beyond the readOnlyHint annotation by detailing specific behavioral traits: return fields (PID, CPU%, RAM, etc.), truncation of command lines at 120 chars, the full_command_line override, result cap at 10, and ordering (windowed first). This provides rich behavioral context beyond the structured annotations.
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 concise and front-loaded: the first sentence states the main purpose, followed by filter usage, return fields, and behavior notes. Every sentence adds value without repetition or fluff. Highly 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?
The description explains the return values (PID, CPU%, RAM, title, command line, start time) and edge behaviors (truncation, cap). However, it does not specify what happens when no matching process is found (e.g., return null vs. empty list), which is a minor gap given the absence of an output schema. Overall, it is mostly complete for this tool's simplicity.
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 adds examples ('python', 'ffmpeg', 'RENDER VIDEO 02') and clarifies the combined use ('and/or') and the full_command_line behavior, but these are more about usage context than core parameter meaning. The schema already documents each parameter effectively.
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 function: 'Check if a process is running on the user's Windows machine — no screenshot.' It specifies the verb ('check'), resource ('process'), and scope (running on Windows). It also distinguishes itself from visual tools by explicitly noting 'no screenshot'.
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 indicates clear usage context: checking a process by name fragment and/or window title, with examples. It doesn't explicitly name alternatives or exclusions, but the context is apparent, especially given sibling tools like list_processes and list_windows. It lacks an explicit 'when not to use' statement.
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?
Annotations already mark this as read-only and non-destructive, so the description only needs to add extra context. It does so by disclosing the two independent savings views and explicitly warning against summing them, which is a crucial semantic behavior. It also notes the store block identifies the source database.
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 sentences deliver a dense but well-organized summary: what metrics, what critical caveat, and what the store block means. No filler or redundant wording.
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 read-only, parameterless tool, the description covers the main output categories, the data-source distinction, and a warning. Without an output schema, it could be slightly more explicit about return format, but the stated content is sufficient for an agent to understand what this tool provides.
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?
With zero parameters, the schema provides no parameter details, but the description compensates by enumerating the dataset contents (metrics, trends, views). This exceeds the baseline for parameter-less tools by giving useful semantic structure.
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 provides local economy metrics including tokens/time saved, queries served, success rates, top apps, and trends. This specific resource and scope distinctly separate it from sibling tools like get_system_status or get_recent_events.
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 context for when this tool is relevant (querying economy statistics) but does not explicitly contrast it with alternatives or state when not to use it. The warning about never adding the two savings views implies careful usage but is not a usage guideline.
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?
Annotations are minimal (readOnlyHint: false, destructiveHint: false). The description adds crucial behavioral context beyond them: it emphasizes 'metadata only — never screen content', which is a privacy guarantee, and says it feeds other tools. This meaningfully supplements the sparse annotations without contradiction.
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, each earning its place: the core action, the usage timing, and the downstream effects. It is front-loaded with the main purpose and contains 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 an 8-parameter tool with no output schema, the description is fairly complete: it explains the purpose, when to call, and important safety constraints. It does not describe return values or error behavior, but these are likely minor for a telemetry reporting tool and are well-covered by the 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 fully described. The description adds a global semantic constraint that all fields are metadata and forbids screen content, which is not present in the schema. This extra layer helps avoid misuse, though it does not detail individual parameters beyond the 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?
Description clearly states the verb ('Report'), the resource ('task outcome'), and the destination ('local telemetry'). It also distinguishes from the sibling report_action_outcome by specifying 'at END of a computer-use task', making the scope unique.
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?
Provides explicit timing ('Call at END of a computer-use task') and mentions downstream consumers (get_app_knowledge, get_economy_stats) to help decide when to use. However, it does not explicitly name alternative tools or mention when not to use, leaving room for clearer exclusion guidance.
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?
Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint), it adds valuable context: stable global element_index, pagination behavior (total/offset/limit/has_more), result ordering, and that no action tier is required. These details significantly enhance understanding without contradicting the annotations.
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 concise yet information-dense: four sentences cover the listing scope, item attributes, pagination, and usage. Each sentence provides unique value, with the main action front-loaded and no redundant 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?
Without an output schema, the description explains the return structure (element_index, flags, pagination metadata) and how to consume results. It could be more explicit about requiring hwnd but implicitly states the tool operates on a window, so it is 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?
The input schema provides 100% coverage for all 6 parameters with descriptions. The description adds general pagination context and the element_index usage but does not elaborate on individual parameters beyond the schema, meeting the baseline.
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 uses the specific verb 'List' with the resource 'interactive UI elements in a window' and includes ordering (buttons, fields, menus first; grid cells last). It clearly differentiates from siblings by stating that element_index is passed to ui_invoke/ui_set_value, distinguishing its role as a discovery 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?
It provides clear context by stating it is read-only with no action tier required, and explains the output can be used with ui_invoke/ui_set_value. However, it does not explicitly mention when not to use it or compare directly to get_ui_tree, leaving some room for ambiguity.
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?
Annotations already declare readOnlyHint and destructiveHint as false/safe. The description adds behavioral context by specifying that it pings the backend and returns version, API URL, and reachability, which goes beyond the annotations and gives the agent a clear expectation of the tool's effect and output.
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 three concise sentences, each adding distinct value: what the tool does, what it returns, and when to call it. No unnecessary words or repetition.
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?
Given the tool's simplicity (no parameters, no output schema), the description fully covers its purpose, behavior, and usage. It is complete and sufficient for an agent to select and invoke correctly.
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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema coverage is 100% (vacuous), and the baseline for zero-parameter tools is 4, which is appropriate here.
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 pings the AI Process Manager backend and returns version, API URL, and reachability. This is a specific verb+resource, and it distinguishes itself from sibling tools like check_process and get_system_status by targeting the AI Process Manager specifically.
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 guidance with 'Call this first in a new session.' It does not mention alternatives or exclusions, but for a health-check tool, this is clear and actionable 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds useful context beyond annotations by enumerating the exact window properties returned (Z-order, focus, etc.), which is valuable for the agent. It does not contradict annotations.
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 a single, well-structured sentence that front-loads the purpose ('List open desktop windows') and provides specific detail. Every word earns its place with no redundancy.
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 zero-parameter, read-only tool, the description is complete. It explains both the action and the return content (title, process, state, position, Z-order, focus), which is especially important given there is no output schema. No critical gaps are apparent.
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?
The tool has zero parameters and the schema coverage is 100%, so the baseline for parameter semantics is 4. The description adds no parameter info because none exist, which 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 the tool lists open desktop windows with a specific set of attributes (title, process, minimized/maximized state, position, Z-order, focus). It distinguishes itself from siblings by focusing on windows (not processes) and by noting it replaces screenshots for 'what is open'.
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 phrase 'Replaces screenshots for "what is open"' provides clear context for when to use this tool: when an agent needs to know what windows are open on the desktop. However, it does not explicitly mention alternatives or exclusions, so it misses the highest bar.
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?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses additional behavioral context: it requires a user-enabled action tier and allowlist, returns action_denied if not permitted, and mandates user confirmation. It also clarifies that the action is a semantic click via UI Automation, providing richer operational expectations.
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 three sentences with no filler. The first sentence states the action and method, the second explains targeting and prerequisites, and the third gives an explicit user-confirmation requirement. All sentences contribute unique, actionable information and it is front-loaded with the core purpose.
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 click tool with four parameters, no output schema, and a destructive hint, the description covers the essential context: what the tool does, how to target elements, permission prerequisites and error case, and user confirmation. It is well-rounded and sufficient for an agent to know when and how to invoke it correctly, especially given the rich schema descriptions.
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?
The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds meaningful semantics by explaining the targeting strategy: it can use name_contains or element_index from ui_find, linking element_index to a sibling tool. This clarifies how parameters relate and which combinations are relevant, going slightly beyond the 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 uses a specific verb ('CLICK') and identifies the resource ('UI element') with the method ('via UI Automation'), and it lists element types (button, menu item, checkbox). It also distinguishes from sibling tools by referencing ui_find for element selection, making its role clear relative to related tools like ui_set_value and ui_find.
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 states when to use this tool (to click a UI element), how to target elements (name_contains or element_index from ui_find), and prerequisites (user-enabled action tier + allowlist) with the failure mode (action_denied). It also instructs to confirm with the user before acting. It does not explicitly say 'do not use for setting values or focusing windows,' but the clear verb and targeting guidance imply the scope.
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?
Beyond the readOnlyHint annotation, the description discloses important behavioral traits: it explains that low depth in Chromium/Electron apps yields empty Panes that can mislead, that the tree saturates at a certain depth, and that max_nodes is a cost brake. It also describes the truncation behavior and the response fields, adding substantial 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 longer than typical but every sentence provides actionable detail: it defines the purpose, explains parameter defaults, gives app-specific guidance, and describes truncation. It is well-structured, front-loaded with the definition, and contains no filler.
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?
Given that there is no output schema, the description adequately covers return values ('The response reports depth, max_nodes, nodes, depth_reached and truncated') and explains how to react to truncated trees. It also covers the main use cases and potential pitfalls, making it complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, but the description adds value by explaining the empirical reasoning behind depth choices (e.g., 'depth=8 -> 15 useless nodes; depth=17 -> 115 nodes') and clarifying that max_nodes is a cost cap, not a depth limit. This enriches the parameter semantics beyond the schema's own 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 opens with 'UI Automation tree of a window (roles, names, states) — the accessibility snapshot of a native Windows app,' which clearly states the tool's purpose with a specific verb and resource. It also explicitly distinguishes from ui_find by saying 'For finding a clickable target prefer ui_find,' showing differentiation from a sibling.
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?
It provides explicit when-to-use guidance: 'For finding a clickable target prefer ui_find' and instructs to repeat with higher depth/max_nodes when truncated=true. It also gives tailored depth recommendations for Win32 vs Chromium/Electron apps, making the usage context clear.
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?
Discloses key behavioral traits: processes are sorted by CPU, command lines are truncated unless full_command_line=true, and top has a default of 25 and max of 200. These go beyond the read-only and non-destructive annotations, adding valuable context.
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 two sentences, front-loaded with the main purpose, and every sentence adds useful information with no redundancy.
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?
Given only two parameters and no output schema, the description covers purpose, usage, behavioral details, and parameter semantics comprehensively. It is sufficient for an agent to select and invoke the tool correctly.
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?
Even though the schema already describes both parameters, the description adds crucial details: top's default and max values, and the condition for full command lines. This significantly enriches the parameter meaning.
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 lists running processes sorted by CPU, using a specific verb and resource. It also differentiates from sibling tool check_process, which is for searching a single process.
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 advises using check_process instead when searching for one process, and provides guidance on the top parameter with default and max values. This gives clear context on when and how to use the tool.
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:

[![AIPM MCP server](https://glama.ai/mcp/servers/aipm-engine/AIPM/badges/card.svg)](https://glama.ai/mcp/servers/aipm-engine/AIPM)

Score Badge

Copy to your README.md:

[![AIPM MCP server](https://glama.ai/mcp/servers/aipm-engine/AIPM/badges/score.svg)](https://glama.ai/mcp/servers/aipm-engine/AIPM)

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/aipm-engine/AIPM'

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