AgentLens

by agentkitai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct domain (agents, alerts, analytics, benchmarks, etc.) with clear boundaries. Even closely related tools like agentlens_sessions and agentlens_session_start/end are differentiated by lifecycle management vs. browsing. No significant overlap.
Naming Consistency5/5
All tools follow a consistent 'agentlens_' prefix with snake_case naming. The pattern is uniform across all 22 tools, with verb_noun style for actions (e.g., agentlens_session_start, agentlens_log_event) and noun style for collections (e.g., agentlens_agents, agentlens_alerts).
Tool Count4/5
22 tools is slightly above the typical 3-15 range but still appropriate for a comprehensive monitoring platform. Each tool serves a clear purpose, and the count reflects the breadth of functionality (monitoring, alerts, budgets, benchmarks, delegation, etc.) without being excessive.
Completeness5/5
The tool set provides full coverage for agent monitoring: session lifecycle, metrics, alerts, cost budgets, benchmarks, delegation, trust, guardrails, logging, prompt management, optimization, and reflection. It covers all common operational needs with no obvious gaps for the stated domain.
Average 3.9/5 across 22 of 22 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 258 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('query'), but with no annotations (e.g., readOnlyHint), the agent gets minimal behavioral clues. Absent details like pagination, sorting, or whether events are returned in chronological order, the description lacks transparency.
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 concise—just one sentence—with no superfluous words. However, it may be too terse, missing important context that could be added without much bloat.
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 simplicity of the tool (3 parameters, no output schema, no annotations), the description is incomplete. It fails to mention return format, potential event types, or behavior when limit is exceeded. The agent would need to guess or inspect schema only.
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?
All three parameters have descriptions in the input schema (100% coverage), so the description doesn't add new meaning beyond what's already provided. A baseline score of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'query' and the resource 'events from an AgentLens session', making the tool's purpose straightforward. However, it does not differentiate from sibling tools like agentlens_log_event or agentlens_reflect, which might also involve querying session data.
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?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include agentlens_log_event (which logs events) and agentlens_replay (which may replay events), but the description offers no distinctions or usage context.
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?
The description lacks behavioral details beyond action names. No annotations are provided, so the description should disclose side effects, permissions, or behavior (e.g., what 'create' returns, whether updates are versioned). It only briefly mentions 'auto-discovered prompt fingerprints' without elaboration.
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, well-structured with a header, bullet actions, and an example. It is front-loaded with purpose. However, the action list could be more compactly described.
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 12 parameters and 6 actions, the description lacks detail for each action (e.g., return values, metric definitions). No output schema. Missing complete behavior for 'create', 'update', 'analytics', and 'fingerprints'.
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% and each parameter has a description indicating which actions it applies to. The tool description echoes this with a list, but adds no additional semantics like constraints, defaults, or usage examples. 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 the tool manages prompt templates and versions, and lists specific actions. However, it does not differentiate from sibling tools like agentlens_agents or agentlens_context, lacking sibling distinction.
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 guidance on when to use this tool versus alternatives. The description lists actions but does not provide context or prerequisites for choosing this tool over sibling prompt-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?
No annotations are provided, and the description is too brief to disclose behavioral traits such as whether logging is synchronous, what happens if the session is inactive, or if there are rate limits. The description adds no value beyond the input 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 a single sentence with no wasted words. However, it could include more useful information without becoming verbose, so it is good but not perfect.
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 5 parameters and no output schema, the description lacks necessary context about return values, side effects, and how logged events relate to the AgentLens system. It does not mention that events can be queried later or the consequences of incorrect usage.
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 parameters. The description does not add any extra meaning beyond the schema definitions, warranting the baseline score of 3.
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 'Log' and the resource 'event' targeted at 'active AgentLens session'. It distinguishes this tool from related siblings like agentlens_log_llm_call and agentlens_query_events, which have more specific purposes.
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 alternatives (e.g., log_llm_call for LLM-specific events). It does not mention prerequisites like having an active session or that events can be queried later with agentlens_query_events.
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 disclosing behavior. It mentions 'emits paired events' but does not describe side effects (e.g., mutating the session), required permissions, error states, or whether it overwrites or appends data. The mutation is implied but not explicit.
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 of 18 words. Every word is necessary and no space is wasted. It is well-structured for quick understanding.
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's complexity (13 parameters, 9 required, nested objects, no output schema), the description is too brief. It fails to mention required parameters, usage patterns, or any caveats about the session state. A more detailed description is needed to guide correct 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 description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides. It does not explain relationships between parameters (e.g., messages vs systemPrompt) or provide examples. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('Log') and the resource ('complete LLM call'), and mentions the emitted events ('llm_call and llm_response'). It distinguishes itself from sibling tools like agentlens_log_event, which logs generic events, making it obvious when to use this tool.
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 does not provide any guidance on when to use this tool versus alternatives, such as agentlens_log_event. It also fails to specify prerequisites (e.g., requiring an active session from agentlens_session_start) or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'End', omitting consequences such as whether data is saved, if the session can be resumed, or any cleanup actions. This is insufficient for an agent to understand side effects.
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, no redundant words. Information is front-loaded and directly addresses the tool's core function. Highly 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?
Given the tool's simplicity (3 parameters, no output schema), the description provides minimal but adequate context for an agent to understand the basic function. However, missing behavioral details reduce 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 parameters. The description adds no extra meaning beyond the schema. Baseline score of 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's purpose with a specific verb (End) and resource (AgentLens monitoring session), distinguishing it from sibling tools like agentlens_session_start. However, it could be more specific about what 'end' entails (e.g., stop and archive).
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 explicit guidelines on when to use this tool versus alternatives. While the context implies it is the counterpart to agentlens_session_start, there is no mention of prerequisites or related tools, leaving the agent to infer usage 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 discloses the basic behavior (starting a session, returning an ID) but omits details like session expiration, concurrency limits, or required 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 sentences with zero wasted words. The first sentence states the primary purpose, and the second adds the key return value. 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?
For a simple session creation tool with no output schema and absent annotations, the description covers the essential purpose and return value. It could mention uniqueness or limitations of session IDs, but overall adequate.
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%, and the description does not add any parameter-specific context beyond what the schema already provides. 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 identifies the action ('Start') and resource ('a new AgentLens monitoring session'), and specifies the return value ('Returns a sessionId'). It distinguishes itself from sibling tools like agentlens_session_end and agentlens_sessions.
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 initiating monitoring, but provides no explicit guidance on when to use vs. alternatives (e.g., agentlens_sessions for listing), nor any prerequisites or restrictions.
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 must carry the full burden. It only states the function and gives an example, but fails to disclose the return format, whether it's read-only, any side effects, or error conditions. This is insufficient for a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear purpose statement, a 'When to use' section, and a code example. No wasted words, well-structured for an AI agent.
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?
The tool lacks an output schema, so the description should explain the return value. It does not describe what the trust score looks like (e.g., numeric range, confidence level). Also, no error handling info. This leaves the agent guessing about the response format.
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 value by explaining the action enum (only 'score') and clarifying that agentId is required for score. The example further illustrates usage, going beyond the schema's bare 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 'Get trust scores for agents', which is a specific verb and resource. It distinguishes from siblings like agentlens_agents or agentlens_health by focusing on trust scores.
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 'When to use' guidance: to check trust before delegating or monitor reputation. Though it doesn't mention when not to use or alternatives, the context is clear and helpful.
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 correctly indicates the tool is for querying (non-destructive) and lists actions. However, it does not disclose any additional behavioral traits such as pagination, rate limits, or authorization requirements. The absence of such details is acceptable for a simple query tool but could be improved.
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 well-structured: a brief intro, when-to-use, actions list, and an example. Every sentence adds value, and it is front-loaded with the purpose. 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 tool has 6 parameters (one required) and no output schema. The description explains the actions and provides an example, which is sufficient for a query tool. It does not explain return values, but since no output schema exists, the description could be slightly more complete regarding expected output format.
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. The description adds value by explaining the 'action' parameter's options, the 'range' shorthand, and providing an example. This clarifies parameter usage beyond the schema definitions.
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 queries operational analytics covering metrics, costs, agent performance, and tool usage. The verb 'Query' and resource 'analytics' are specific. However, it does not explicitly differentiate from similar sibling tools like agentlens_stats, leaving some ambiguity.
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 includes a 'When to use' section that explicitly lists use cases like understanding system performance trends, cost breakdowns, etc. It provides context for when the tool is appropriate, but it does not mention when not to use it or provide alternatives.
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 must disclose behavioral traits. It lists actions including delete, but does not warn about irreversible deletion or other side effects. The example shows a create action but lacks details on error handling or performance impacts.
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 well-structured with clear sections (When to use, Actions, Example). It is concise, front-loaded with purpose, and every sentence adds value. No unnecessary text.
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 11 parameters and no output schema, the description could be more complete. It lacks details on return values for actions like status or list, and does not explain error scenarios or configuration nuances for anomaly detection.
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 parameters are documented. The description adds an example that maps parameters to values, but does not elaborate on parameter meaning beyond what the schema already provides. Thus, it adds marginal 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 'Manage cost budgets and anomaly detection.' It lists specific actions like create, update, delete, and status, making the tool's purpose precise and distinguishable from sibling tools that focus on agents, alerts, analytics, etc.
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 includes a 'When to use' section: 'To create/manage spending limits, check budget utilization, or configure cost anomaly detection.' This gives clear context, though it does not explicitly state when not to use or provide alternatives.
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 describes the two actions and their outputs (storage stats, overview metrics) and includes an example. However, it does not disclose whether the tool has side effects, requires authentication, or has rate limits. Given the read-only nature implied by 'get', a 3 is appropriate.
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 extremely concise with no wasted words. It uses a clear structure: one-line summary, when-to-use sentence, bulleted actions with descriptions, and a code example. Every sentence serves a 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?
Given that the tool has only one parameter with 100% schema coverage and no output schema, the description does enough. It explains both action values and gives an example. While it could be more precise about the exact fields in the output (e.g., specific metrics returned), it is not required since there is no output schema to complement.
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% with a single parameter 'action' defined as an enum. The description adds meaning by explaining the enum values ('storage': Get storage stats, 'overview': Get overview metrics) beyond the schema's 'Action to perform'. This helps the agent understand the parameter's semantics clearly.
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 storage statistics and system overview metrics. It distinguishes itself from sibling tools by specifying 'storage statistics' and 'system overview' which are not covered by other agentlens_* tools like agentlens_agents or agentlens_alerts. However, it could be more precise about the exact scope of metrics.
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 when-to-use guidance: 'To check database/storage utilization or get a high-level system overview.' It also lists the two actions with descriptions, which helps an agent decide which action to invoke. Does not explicitly state when not to use or list alternatives, but the sibling tools cover other domains, so the context is 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 provided, so description carries full burden. It lists actions and gives an example, but doesn't disclose side effects, success/failure behavior, or idempotency. Adequate but not comprehensive for a multi-action 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?
Well-structured with a summary, usage section, actions list, and example. Each sentence adds value, no fluff. Front-loaded with key purpose and usage context.
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?
Given 10 parameters and no output schema, the description covers actions and provides an example. However, it lacks explicit details about return values for each action (e.g., what list returns). Still fairly complete for CRUD-like management.
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 parameters. The description adds an example that maps params to actions, but doesn't provide significant additional meaning beyond the schema. 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 the tool manages alert rules and views history, with specific actions (list, create, update, delete, history). It distinguishes itself from sibling tools like agentlens_analytics by focusing on alerts. The example reinforces the purpose.
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?
Explicitly states 'When to use' for creating alerting rules, managing existing rules, or reviewing triggers. Provides a concrete example. While it doesn't mention when not to use, the context is clear for typical alert management scenarios.
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?
Annotations are absent, so the description fully carries the burden. It describes lifecycle actions (create, start, complete) and what each does, but it omits details about side effects, data persistence, or required permissions. The behavioral profile is adequate but not deep.
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 headers and sections, and it front-loads the main purpose. It is moderately concise; every sentence adds information, though it could be slightly trimmed without loss.
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?
Given the tool's complexity (9 parameters, 1 required, no output schema), the description covers the main actions, workflow, and key parameters. It lacks details on return values, but the example and action list provide good context. Annotations would have helped, but overall it's fairly 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%, but the description adds value by explaining the workflow, listing required parameters per action (e.g., 'name required for create'), and providing an example. This enriches understanding beyond the raw 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 the tool's purpose: 'Manage A/B benchmarks: create, list, check status, get results, and control lifecycle.' It uses specific verbs and a concrete resource (benchmarks), and it distinguishes itself from sibling tools by focusing on experiment lifecycle management.
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 includes a 'When to use' section that explains the context ('set up controlled experiments comparing different agent configurations') and provides a workflow. While it doesn't explicitly exclude alternatives, the workflow and action list give clear guidance on typical 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 bears full responsibility. It explains the core action but does not disclose behavioral traits such as whether the call is synchronous, what happens on failure, or if the operation is reversible. The schema includes fallback and retry parameters but the description does not elaborate on their behavior.
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 with four sentences front-loading the purpose, usage guidelines, and an example. No extraneous information is present.
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?
Given the tool has 7 parameters and no output schema, the description effectively covers the usage context and prerequisite. However, it lacks information about return values and edge cases, which would be needed for full completeness. Nonetheless, it is nearly complete for a delegation 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 description coverage is 100%, so the schema already documents all parameters. The description adds no additional semantic value beyond the example usage. 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 verb 'delegate' and the resource 'another agent', and distinguishes it from siblings by referencing agentlens_discover as a prerequisite. 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition for use: after discovering an agent via agentlens_discover. It also provides a concrete example, leaving no ambiguity about when to invoke this tool.
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 full burden. It discloses that results are ranked with trust scores, estimated cost, and latency. It implies a read-only operation with no side effects, and the fixed action parameter reinforces this. While it could mention permissions or rate limits, for a discovery tool this is adequate.
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 extremely concise: two sentences plus an example. It uses a header to highlight when to use, and the example is clear and labeled. No redundant information.
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?
Given 6 parameters and no output schema, the description explains the purpose, usage context, and return type (ranked results with scores, cost, latency). It does not detail the output structure, but the mention of fields provides a sufficient mental model. For a tool with no annotations and no output schema, this is fairly 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 coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema; it only provides an example call. The example is helpful but not essential for understanding parameter 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 discovers agent capabilities in the network, with a specific verb and resource. It distinguishes from sibling tools like agentlens_agents (list all) and agentlens_delegate (delegate tasks) by focusing on discovery based on task type.
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 when to use: before delegating, to find agents for a specific task type. It also lists what it returns (ranked results with trust scores, cost, latency). However, it does not explicitly mention when not to use or provide alternatives, which would elevate it to a 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?
With no annotations provided, the description carries the full burden. It explains the tool analyzes patterns and returns recommendations, but doesn't explicitly state that no changes are made to the system, which could be inferred. It lacks details on authentication or rate limits, but these are less relevant for an analysis 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 concise with clear sections: summary, when to use, what it returns, and an example. Every sentence adds value, and it is front-loaded with the main 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?
Given no output schema, the description adequately explains the return format (list of recommendations with savings, confidence, success rate comparisons). It is complete enough for a simple analysis tool, though it could explicitly mention that no actions are taken on the system.
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?
Both parameters have descriptions in the schema (100% coverage), and the description adds an example call showing usage and expected return format, including savings, confidence levels, and success rate comparisons. This adds value 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 clearly states the tool provides cost optimization recommendations by analyzing LLM call patterns and suggesting cheaper model alternatives. This differentiates it from sibling tools like cost_budgets, which focus on budget management.
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 includes a dedicated 'When to use' section that explains the tool is for identifying cost-saving opportunities by switching to cheaper models for tasks that don't require the most capable model. It provides clear context but doesn't explicitly list alternative tools or when not to use.
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. The description uses 'Browse and inspect' implying read-only, but does not explicitly confirm non-destructive behavior or provide other behavioral traits. The actions are query-based, adding some transparency.
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: 3 sentences plus a bullet list of actions. It's well-structured with sections and an example, no fluff.
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 9 params and no output schema, the description covers all actions and key parameters. Example shows typical usage. Lack of return value documentation is acceptable given no 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 baseline is 3. The description groups parameters by action (e.g., sessionId required for detail/timeline) and provides an example, adding meaning 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 clearly states 'Browse and inspect AgentLens sessions' and lists specific actions (list, detail, timeline). It distinguishes from sibling tools like agentlens_session_start by focusing on past session inspection.
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 'When to use' section explicitly states the tool is for finding/inspecting past sessions, debugging, auditing, reviewing. It doesn't explicitly say when not to use, but the sibling context implies alternatives.
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 explains that the tool returns an overall score (0-100), trend indicator, and dimension breakdown. Though it does not explicitly state read-only behavior or side effects, the nature of 'checking health' implies safe, non-destructive operation, and the return structure is clearly defined.
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 well-structured with clear sections (description, when to use, what it returns, example). Every sentence adds value without redundancy. 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?
Given the low complexity (one optional parameter), the description fully covers what the tool does, when to use it, and what data it returns. No output schema is provided, but the description details the return structure, making it complete for agent decision-making.
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% (one parameter 'window' with a description). The description includes an example but does not add additional semantic meaning beyond what the schema already provides. 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 the tool checks the health score of the current agent, with a specific verb ('check') and resource ('health score'). It distinguishes itself from sibling tools like agentlens_stats and agentlens_agents by focusing solely on health assessment.
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 guidance on when to use the tool: 'To assess the current health and performance of the agent, to check if error rates or latency are degrading, or to get a quick overview of agent reliability metrics.' It lacks explicit when-not-to-use or alternative tool references but still offers clear 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 given, so the description carries the full burden. It discloses the return format (session header with agent, status, duration, cost, event counts, followed by numbered steps) and special behavior like summaryOnly mode for large sessions. This provides sufficient behavioral context beyond the input 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 well-structured with clear sections (general purpose, when to use, what it returns, parameters, example). It is informative but not excessively long. The information is front-loaded and each sentence 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?
Given the tool has 5 parameters with 100% schema coverage and no output schema, the description adequately explains the return values (header plus steps) and parameter nuances. It is complete enough for the tool's complexity, though an explicit note on pagination or step limits would be a minor addition.
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 explaining the purpose of fromStep/toStep (specific step range), eventTypes (comma-separated filter), and summaryOnly (fast for large sessions). It also provides a concrete example, making parameter usage clearer than the schema alone.
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 replays a past session as a structured timeline. It uses a specific verb (replay) and resource (session), and the context of debugging or post-mortem analysis distinguishes it from sibling tools like agentlens_sessions or agentlens_analytics.
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 provides 'When to use' with concrete scenarios (understand failures, decision patterns, timing, cost accumulation). It lacks explicit 'when not to use' or mention of alternatives, but the provided use cases are clear enough for an AI to decide.
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 describes the return value as a list of structured insights with type, summary, data, confidence score, and metadata, and gives an example. It does not discuss authorization, rate limits, or destructive actions, but the behavioral transparency is good for a non-destructive analysis 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 well-structured with clear sections: overall purpose, when to use, what it returns, and an example. Every sentence adds value, and there is no redundancy or fluff.
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?
Given the complexity (6 parameters, nested objects, no output schema), the description covers the main aspects: purpose, usage guidelines, return value shape, and an example. It could mention error handling or pagination, but it is complete enough for the agent to understand and invoke the tool 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the analysis enum values with context in the 'When to use' section and providing a concrete example that shows how parameters are used together. This additional context aids understanding beyond the 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 analyzes behavioral patterns from agent sessions, listing four specific analysis types (error_patterns, tool_sequences, cost_analysis, performance_trends). It distinguishes from sibling tools like agentlens_agents or agentlens_stats by focusing on reflection and patterns rather than listing agents or raw statistics.
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?
There is an explicit 'When to use' section that details use cases for each analysis type, including identifying recurring errors, understanding cost drivers, and tracking performance. It does not explicitly state when not to use the tool or mention alternatives among siblings, but the guidance is clear and context-rich.
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?
Each action is described (e.g., unpause clears paused state), and the tool's primary behaviors are disclosed. However, no annotations exist, and the description could further clarify that list/detail are read-only and unpause is a write 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?
The description is concise with a clear structure: purpose, when-to-use, action list, and example. Every sentence adds value without 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?
The description completely covers the tool's functionality given the 3 parameters and no output schema. It explains all actions and their outcomes adequately.
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 context by explaining what each action does (e.g., 'list: List all agents with error rates'). This supplements the schema's 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 'List, inspect, and manage AgentLens agents' with specific actions (list, detail, unpause) differentiating it from sibling tools like agentlens_alerts or agentlens_analytics.
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 provides 'When to use' guidance covering listing, inspecting details, and unpausing agents, though it does not explicitly mention when not to use or alternatives.
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, so description carries full burden. Explains return structure (related sessions, lessons, relevance scores) and gives example. Does not mention read-only nature or potential caching, but is transparent for a retrieval 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?
One paragraph and an example, no wasted words. Front-loaded with purpose. Every sentence adds value.
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?
No output schema, but description fully explains return structure with sessions, lessons, summaries, relevance scores. Covers use cases, parameters, and example. Complete for a context retrieval 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%, baseline 3. Description adds meaning by explaining tool's use of parameters (e.g., topic as natural language, limit for max sessions) and provides example. Adds moderate value beyond 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 it retrieves cross-session context for a topic, with specific verb and resource. It distinguishes from sibling tools like agentlens_sessions or agentlens_query_events by focusing on context retrieval.
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?
Explicitly lists when to use: at start of session, building system prompt, handling familiar topic, audit. Does not state when not to use or name alternatives, but use cases are clear.
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?
Without annotations, the description carries the burden of behavioral disclosure. It describes the return value (list of guardrail rules with status and trigger history) but does not explicitly state that the operation is read-only or mention any side effects. However, it is clear enough for a safe read 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?
The description is concise and well-structured with clear sections for when to use, what it returns, and an example. Every sentence adds value without unnecessary elaboration.
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 (one optional parameter, no output schema), the description is complete. It explains purpose, usage, return format, and provides an example, leaving no ambiguity.
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 mentions the default behavior for agentId, which matches the schema. No additional semantics are added beyond what the schema provides.
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: 'Check guardrail status for the current agent.' It identifies the specific verb and resource, and the focus on guardrails distinguishes it from sibling tools like agentlens_agents or agentlens_alerts.
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 provides a 'When to use' section, stating it is for checking guardrail protection, recent triggers, and configured conditions/actions. This gives clear context and implies when not to use it, such as for configuring guardrails.
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:

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

Score Badge

Copy to your README.md:

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

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/agentkitai/agentlens'

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