looplens-mcp

by musaceylan

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are largely distinct: session lifecycle, event ingestion/query, loop detection, convergence, and diagnostics each have clear separation. Minor overlap exists between get_session and get_convergence, but descriptions clarify their different purposes.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case, e.g., create_session, ingest_event, detect_loops. No mixed conventions or vague verbs, making the API predictable and easy to navigate.
Tool Count4/5
16 tools is slightly above the ideal 3-15 range, but each tool serves a distinct function within the domain. The count feels justified given the breadth of session management, event processing, analysis, and export capabilities.
Completeness4/5
The domain covers session lifecycle (create/get/list/close), event ingestion (single/batch), querying, annotation, loop detection, convergence analysis, and export. Lack of session update/delete is a minor gap, but core workflows are well supported.
Average 3.3/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states what it gets, not how it behaves. For instance, the parameter 'include_false_positives' implies default filtering, but the description says 'all detected loop patterns', which is misleading or at least unclear. No mention of error handling, what happens if a session doesn't exist, or return format.
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, concise sentence that is easy to parse and front-loaded with the core purpose. However, it is so sparse that it fails to include necessary details, but for conciseness alone it earns a 4 as it has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is far from complete. It does not explain parameter semantics, return values, or edge-case behavior. A simple getter still needs to clarify what 'loop patterns' are, how false positives are handled, and what the output looks like. The description is minimally functional at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. It mentions 'for a session' which implies the session_id, but 'include_false_positives' is entirely undocumented. The description adds no semantic value beyond the raw schema field names.
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 'Get all detected loop patterns for a session' clearly specifies a getter operation for loop patterns scoped to a session. It is unambiguous about the resource and action, though it doesn't explicitly differentiate from sibling tools like 'detect_loops' or 'get_convergence'. The name and description together make the purpose apparent.
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 about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., that loops must be detected first), exclusions, or when to prefer a sibling tool like 'detect_loops'. The description gives no situational 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'analyze convergence trend over time' without indicating whether the operation is read-only, what data it uses, what computation it performs, or any side effects. This is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise, though the brevity sacrifices informative content that could aid in 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 absence of annotations and output schema, the description is overly thin. It does not explain what a convergence trend is, what the return format might be, or how this tool differs from sibling get_convergence. This incompleteness undermines correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with window documented as 'Number of recent scores to analyze' but session_id lacking any description. The tool description does not elaborate on either parameter, particularly leaving session_id semantics implicit. The description fails to compensate for the missing schema documentation.
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 action (analyze) and the resource (convergence trend over time for a session). However, it does not explicitly differentiate from the sibling tool get_convergence, relying on the phrase 'trend over time' to imply a temporal analysis.
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 get_convergence or other session tools. No alternatives, prerequisites, or contextual cues are mentioned, leaving the agent without clear selection criteria.
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, the description carries the full burden of behavioral disclosure. It only says 'search events' without explaining return format, ordering, pagination, or read-only nature. The description is too minimal to give the agent confidence in side effects or output details.
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 concise sentence with no fluff, but it is arguably too terse for the tool's complexity. It is well-structured and front-loaded, though could include more detail without becoming verbose.
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 description is insufficient given no output schema, no annotations, and three parameters. It does not explain the response structure, the required session_id, or the limit semantics, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with limits and session_id lacking descriptions. The description adds meaning for tool_name ('by tool name') but does not explain session_id or limit behavior, leaving gaps that the schema cannot fill.
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 searches events in a session by tool name, with a specific verb and resource. It distinguishes from siblings like get_session_events by the filter criterion, but does not explicitly mention the return structure or that it is a filtered list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this should be preferred over get_session_events when filtering by tool name, nor any exclusions or prerequisites.
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. It states the action ('Close') but does not disclose consequences such as whether the session becomes read-only, whether events are still accepted, or whether the action is reversible. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and options. No filler or redundant content. It earns top marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, no output schema, and no annotations. The description is minimally sufficient to understand the basic operation, but it omits behavioral context like side effects or error conditions. For a simple mutating tool, it is adequate but not thorough.
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 documents both parameters (session_id and status) with descriptions, including the allowed status values. The description's phrase 'as completed or abandoned' adds no new information beyond the schema's status description. Baseline 3 is appropriate because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Close') and a specific resource ('debug session'), and it mentions the two possible statuses ('completed or abandoned'). It clearly distinguishes from sibling tools like create_session or list_sessions by indicating an end-of-life action, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not state prerequisites (e.g., session must exist) or indicate when 'completed' vs 'abandoned' is appropriate. The description simply states what it does, not when 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state whether the tool has side effects (e.g., writes data), requires specific permissions, or is safe to call repeatedly. It only says it 'runs algorithms' and 'returns patterns', offering no insight into side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes to the purpose, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and partially documented parameters, the description is incomplete. It does not explain what a 'loop pattern' is, what the return value looks like, whether there are prerequisites, or how it relates to get_loops. While simple, it misses essential context needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only window_size has a description). The description mentions 'session' but does not elaborate on session_id or window_size. It adds no meaningful parameter details beyond what the schema already provides, and it fails to compensate for the undocumented session_id parameter.
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: 'Run loop detection algorithms on a session and return detected loop patterns.' It uses a specific verb ('Run') and identifies the resource (a session) and the output (detected loop patterns). This distinguishes it from the sibling tool 'get_loops', which likely retrieves existing loops rather than performing detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like 'get_loops'. The description implies usage for running detection, but it does not mention prerequisites (e.g., session must exist), exclusions, or compare with sibling tools. This is 'no guidance' beyond the basic action.
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?
Annotations are absent, so the description must disclose side effects. It only states the action without explaining what changes occur, whether it is reversible, or how it affects downstream analysis. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. Every word earns its place, and the structure is straightforward.
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 lack of annotations and output schema, the description is too terse. It does not clarify the operational impact (e.g., whether marked detections are excluded from get_loops or export_eval_cases), leaving the agent uncertain about side effects and downstream behavior.
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 fully describes the only parameter with 100% coverage, and the description does not add any additional nuance about how pattern_id relates to the action. The baseline score of 3 applies because the schema already documents the parameter.
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 'mark' with the resource 'loop detection' and the qualifier 'as a false positive', clearly distinguishing it from sibling tools like detect_loops and get_loops.
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 annotate_event, nor any prerequisites or expected workflow context. The description does not mention any exclusions or distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that a new debug session is created, but does not disclose any behavioral details such as whether a session ID is returned, whether sessions need to be closed, or any side effects or limits.
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, concise sentence that is front-loaded with the main action. It avoids fluff, but could have included more useful context without becoming verbose.
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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns, whether any prerequisites exist, or how it fits into the workflow with related tools like ingest_event and close_session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond the schema's own descriptions for label, metadata, and source_type. It merely provides context about tracking tool events.
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 'Create' and the resource 'LoopLens debug session', with the purpose 'to track tool events'. This distinguishes it from sibling tools like get_session, list_sessions, and close_session.
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 (create a session when starting to track tool events) but does not explicitly state when to use this tool versus alternatives like ingest_event or close_session. There are no exclusions or alternative tool mentions.
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. The only behavioral trait disclosed is pagination, but it does not mention ordering, default limit/offset semantics, error behavior, or whether the result is a list with metadata. This is insufficient for a read operation without 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 concise sentence that front-loads the core purpose. Every word earns its place, and there is no verbosity or redundancy.
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 lack of an output schema, the description should at least mention what is returned (e.g., a paginated list of events), but it only says 'retrieve events'. It also omits details about pagination behavior, such as default page size or how to navigate pages. The tool is simple, but the description leaves several gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'pagination' which hints at limit/offset, but it does not explain that session_id identifies the session, nor does it describe how limit/offset work together. The description adds only minimal meaning beyond the schema itself.
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 ('Retrieve') and the resource ('events for a session'), making it obvious what the tool does. It is implicitly distinguished from siblings like get_session (session metadata) and list_sessions (all 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 purpose implies when to use the tool (when you need events for a specific session), but it provides no explicit guidance on when not to use it or how it differs from search_events or other related tools. This is better than no guidance but lacks exclusions.
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. Description only says it exports session data, with no mention of side effects, auth, read-only nature, or how the export is delivered (file, response body). The absence of behavioral detail makes it hard for an agent to anticipate consequences.
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 sentence, no filler, verb-first with purpose embedded. Efficient and front-loaded.
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?
With no output schema and no annotations, the description does not state what the export returns, whether it writes a file, or if it has side effects. For an export operation in a session-management tool, this is a significant gap for an agent to safely invoke it.
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 covers 'format' (jsonl or json) but not session_id. The description's 'session data' gives context for session_id but doesn't clarify format options or output details. Since coverage is exactly 50%, the description adds only 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?
Clear verb+resource: 'Export session data as structured eval cases for model evaluation.' It specifies exactly what it does and distinguishes from sibling tools like get_session or get_session_events by the transformation into evaluation cases.
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?
Implied usage for model evaluation, but no explicit alternatives or when-not-to-use. Does not mention which sibling tools to prefer for plain session viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose a non-obvious behavioral trait: 'computes if not cached,' indicating possible computation and caching side effects. However, it omits other relevant details like whether the operation is read-only, potential error conditions, or whether computation is expensive. This adds some value but is not comprehensive.
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, front-loaded with the primary action and resource. It wastes no words and is appropriately minimal for a simple getter. The parenthetical adds necessary behavioral context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description does not explain the return format, scale, or error behavior. It says 'convergence score' but not what the score represents or how to interpret it. The lack of annotations and output schema places a heavier burden on the description, which it only partially meets. This is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, session_id, but the description does not explain its semantics, format, or how to obtain it. Schema description coverage is 0%, so the description should compensate, but it only references 'a session' without connecting to the actual parameter. The agent is left to infer that session_id is the session identifier, which is trivial given the name, but no further meaning is added.
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: 'Get convergence score for a session' with a specific verb and resource. It distinguishes itself from siblings like get_session (general session info) and analyze_convergence_trend (trend analysis) by focusing on the convergence score. The parenthetical adds a useful behavioral detail.
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. While the description implies use for a single session's convergence score, it does not mention when not to use it, such as when needing a trend (analyze_convergence_trend) or loop detection (detect_loops). The absence of any exclusionary language leaves the agent without decision support.
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, the description carries the full burden of behavioral disclosure. It only states the batch action and does not mention side effects, ordering, atomicity, error handling, or return behavior. This is a significant gap for a mutating batch 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 a single, front-loaded sentence that is concise and directly states the tool's action and scope. Every word earns its place with no wasted or redundant text.
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 has a single parameter but no output schema or annotations. The description does not explain what 'ingest' entails (e.g., whether it is synchronous, validates events, returns a result, or handles partial failures). The minimal description is insufficient for an agent to fully understand the tool's behavior.
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% (the events parameter has a detailed description). The tool description adds no extra parameter semantics, so the baseline of 3 applies; the schema already provides the necessary 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 'Ingest multiple tool events at once' clearly states the verb (ingest), resource (tool events), and scope (multiple at once). It implicitly distinguishes from the sibling ingest_event by emphasizing batch handling, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at once' implies the tool is intended for batch ingestion, providing an implied usage context. However, it does not explicitly mention when to prefer this over ingest_event or when not to use it, so guidance is limited to implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is idempotent, what side effects occur on the session, or how status values like 'error' or 'timeout' are handled.
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, direct sentence with no wasted words. It is concise and front-loaded.
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 has 7 parameters and no output schema, yet the description provides almost no context about the broader behavior, return values, or how it fits into the session lifecycle. The description is too sparse to be fully self-contained.
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 parameters are fully described in the schema. The description adds no additional parameter semantics, but the schema already covers all fields.
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 (ingest), the object (a single tool event), and the destination (a session). The word 'single' distinguishes it from the sibling tool 'ingest_batch'.
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 individual tool events, but it does not explicitly state when to use this tool versus alternatives like 'ingest_batch' or 'annotate_event'. No exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a write operation ('Add') but does not disclose side effects like whether existing annotations for the same key are overwritten, whether the event must exist, or any 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, clear sentence with no redundant information. It efficiently conveys the tool's purpose without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool, the description covers the essential 'what' but lacks context on return values, error handling, or relationship to events. Given no annotations and no output schema, more detail would be expected to fully understand the tool's behavior.
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?
Despite 0% schema coverage, the description implicitly defines the parameters: 'key-value annotation' explains the roles of key and value, and 'specific event' indicates event_id. This gives semantic meaning beyond the raw schema, though it lacks format constraints or examples.
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 ('Add') and the target ('a key-value annotation to a specific event'), making the tool's purpose unambiguous. It distinguishes itself from siblings by focusing specifically on annotations, which no other tool mentions.
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 ingest_event or get_session_events. There is no mention of prerequisites, intended workflow, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is a read operation (via 'list') and mentions optional filtering and pagination. However, it does not describe return structure, default behavior when no status is given, or any potential side effects, which is acceptable but minimal.
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 sentence that is front-loaded with the core purpose, then adds the two key optional aspects. Every word contributes value, with 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 low complexity of a list operation, the description is sufficient: it states the action, the resource, and optional parameters. No output schema exists, but the return value is implied. It doesn't mention how results are ordered or whether all sessions are returned by default, but these are minor gaps for a simple 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 baseline is 3. The description adds only a high-level mention of 'optional status filter and pagination' which aggregates the parameters but does not add semantic detail beyond what the schema already 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 function: 'List debug sessions with optional status filter and pagination.' The verb 'List' and resource 'debug sessions' are specific, and the mention of filter and pagination distinguishes it from sibling tools like get_session which retrieves a single session.
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 listing sessions, but provides no explicit guidance on when to prefer this over get_session or other listing tools. It mentions optional status filter and pagination, giving context, but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies read-only behavior, but it does not explicitly state that the operation has no side effects, require permissions, or mention error conditions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It front-loads the core action and resource, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description gives helpful return content hints ('loop count and convergence score'), which partially compensates for the missing output schema. It could mention that it returns the full session object, but overall it is sufficient for a simple getter.
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 100% coverage for the single parameter session_id with 'Session UUID'. The description does not add extra meaning to the parameter, so it meets the schema-driven baseline 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 is a specific verb+resource: 'Get details for a debug session including loop count and convergence score.' It clearly distinguishes the tool from siblings like get_session_events or get_loops by indicating it returns session-level summary details.
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 usage when an agent needs high-level session details (loop count, convergence score) rather than granular events or loop lists. However, it does not explicitly mention alternatives or exclusions, so it earns a 4 instead of 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?
No annotations are provided, so the description carries the full burden. It specifies the returned diagnostics (session counts, event totals, DB path), which is useful transparency. However, it does not explicitly state that the operation is read-only, nor does it mention permission requirements or potential side effects, though 'get' implies a safe query.
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: it starts with the action and resource, then lists specific content. No filler or redundant information, making it highly concise and well-structured.
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 no-parameter diagnostics tool, the description adequately covers what the tool does and what data it returns. It lacks an explicit return format or operational context, but given the simplicity and absence of an output schema, it is mostly complete. A minor gap is not mentioning any broader usage context, but this is 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 empty input schema fully covers parameter semantics. Per the rubric, a baseline score of 4 is appropriate when there are no parameters, even though the description adds no parameter details.
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 ('Get') and the resource ('LoopLens server diagnostics'), and enumerates specific data elements (session counts, event totals, DB path). This distinguishes it from sibling tools focused on individual sessions, events, and loop analysis.
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 this is for retrieving overall server health and statistics, which is self-evident from the word 'diagnostics'. However, it does not explicitly state when to use it over alternatives or mention any exclusions, but the diagnostic role is clear enough.
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:

[![looplens-mcp MCP server](https://glama.ai/mcp/servers/musaceylan/looplens-mcp/badges/card.svg)](https://glama.ai/mcp/servers/musaceylan/looplens-mcp)

Score Badge

Copy to your README.md:

[![looplens-mcp MCP server](https://glama.ai/mcp/servers/musaceylan/looplens-mcp/badges/score.svg)](https://glama.ai/mcp/servers/musaceylan/looplens-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/musaceylan/looplens-mcp'

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