mcp-ispkeeper

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Tools are generally distinct by domain (clients, invoices, tickets, connections, network). Some potential overlap between get_client_services and the connection-specific tools (list_internet_connections, etc.), but the descriptions explicitly clarify the boundaries. Overall, an agent can reliably pick the right tool.
Naming Consistency4/5
Predominantly uses a consistent verb_noun pattern (list_*, get_*, search_clients). Minor deviation with get_clients_summary (plural instead of singular) and list_fttx_infrastructure (FTTx not fttx_infrastructure), but the pattern is easily recognizable and predictable.
Tool Count5/5
25 tools is on the high side but still well within reason for a comprehensive ISP management system. Each tool has a clear purpose and covers distinct aspects (clients, invoices, collections, connections, tickets, network, infrastructure, reference data). No tool feels extraneous.
Completeness5/5
The tool set provides thorough coverage for an ISP management server: CRUD-like operations for clients, invoices, collections, internet/TV/phone connections, and support tickets. It also includes network status, infrastructure hierarchy tracing, and auxiliary reference data. I see no obvious missing operations for typical workflows.
Average 3.7/5 across 25 of 25 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden. It adds a caution about error handling but does not disclose other behavioral traits such as authentication requirements, rate limits, or the nature of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with a front-loaded warning using an emoji. No superfluous content; could be slightly more compact but appropriate for the message.
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 simple get tool with no output schema, the description does not specify what 'detailed information' includes (e.g., package, status, billing). It fails to differentiate from other get tools among the many siblings, leaving the agent with insufficient context.
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 coverage is 100% with one parameter (connection_id) whose description is 'TV connection ID'. The description adds no additional meaning beyond what the schema provides, so baseline 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 states the verb 'Get' and the resource 'detailed information about a specific TV connection', which clearly identifies the tool's action and scope. It distinguishes from siblings like list_tv_connections by indicating specificity.
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 includes a warning about not fabricating data on failure, but provides no guidance on when to use this tool versus alternatives (e.g., list_tv_connections, get_client_services). It lacks context about prerequisites or 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?
With no annotations, the description carries full burden. It only provides a warning about error reporting, but lacks disclosure on pagination behavior, authentication requirements, rate limits, or output format. The basic action (list with filters) is stated but deeper behavioral traits are absent.
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 efficient sentences: one for purpose, one for behavioral warning. No unnecessary words; the warning earns its place by preventing data fabrication. Front-loaded with the core action.
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?
Despite 6 parameters and no output schema, the description only mentions date and user filters. It omits pagination defaults (page, per_page), the 'relaciones' parameter for expanding relations, and any explanation of return value structure. The warning is helpful but the description is incomplete for a filtering endpoint with multiple options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that filters are by date and user, which the schema already documents (e.g., 'Filter by user', 'Created from date'). No additional semantic 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?
Description clearly states the verb 'List', the resource 'payment collections', and the filtering scope by date and user. This distinguishes it from sibling tools like get_collection (single) and other list tools. The schema parameters align with this purpose.
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 such as get_collection or search_clients. The warning about not fabricating data addresses error behavior but does not help the agent choose this tool over similar ones.
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 discloses the tool's listing behavior and includes a caution about error reporting, which hints at potential failure modes. However, it omits behavioral details such as pagination limits, rate limits, or auth requirements, making the transparency adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first sentence states purpose and filtering options, the second adds a critical behavioral instruction. Every word earns its place.
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 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return format, pagination behavior, the 'relaciones' parameter, or how results are ordered. The warning is useful but insufficient to make the tool fully understandable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description summarizes filters by date, category, and status, which aligns with schema properties but adds no new meaning beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'support tickets' along with filtering dimensions. It distinguishes from siblings like 'get_ticket' (singular) and 'list_tickets_log' (log), but does not explicitly contrast them, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a warning about not fabricating data on failure, but offers no guidance on when to use this tool versus alternatives (e.g., get_ticket for a single ticket, list_tickets_log for history). There is no context on prerequisites or optimal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions a failure handling guideline but does not disclose whether the tool is read-only, destructive, requires authentication, has latency, or returns historical vs real-time data. The failure instruction is a guideline, not a behavioral trait.
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 two sentences, the first clearly stating purpose and the second a critical guideline. No irrelevant information is included.
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 complexity (simple tool with only two optional parameters, no output schema, no annotations), the description adequately covers the tool's purpose and a key usage warning. However, it does not explain return values or behavior when no filters are applied, which is a minor gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions the optional date range filter, which aligns with the two parameters. However, it does not add semantic meaning beyond what the schema already provides (e.g., date format, default behavior without filter).
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 gets network status with an optional filter by outage date range. It distinguishes itself from sibling tools like get_network_element or list_internet_connections by focusing on network status rather than specific elements or connection lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use it (getting network status) and explicitly warns against fabricating data if the tool fails, which is a usage constraint. However, it does not differentiate when to use this vs alternatives like get_network_element or other network-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions that the tool returns 'movement/change history with timestamps and users', but omits details about side effects, permissions, rate limits, or behavior when no logs exist. The failure-handling warning is about agent behavior, not the tool's own traits.
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 a critical warning. Information is front-loaded with the purpose, and every sentence serves a clear function. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description is adequate but lacks details like pagination behavior, ordering of results, and filtering capabilities. The warning about error handling adds useful context, but the overall completeness is merely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (page and per_page), so the schema already documents them. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.
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 'List ticket activity logs across all tickets' using a specific verb and resource. It distinguishes itself from sibling log tools by focusing on tickets, though it does not explicitly contrast with other list tools like 'list_tickets'.
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 includes a warning about not fabricating data on failure, which is a valuable usage guideline. However, it does not specify when to use this tool versus alternatives (e.g., 'list_tickets' or 'get_ticket'), nor does it provide context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns 'database record snapshots before modifications' with timestamps and users, and includes a caution against hallucinating data. However, it omits details such as pagination limits, ordering, rate limits, or authentication requirements. The transparency is adequate but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two purposeful sentences and a warning. It front-loads the core purpose and return value. The structure is efficient with no filler. Could be slightly improved with structured bullets, but it earns a 4 for its lean design.
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?
Despite no output schema and 4 optional parameters, the description covers the return content (snapshots with timestamps and users) and the scope ('across all clients'). However, it lacks any mention of pagination behavior (e.g., max pages, default ordering) or how date filters affect results. For a log-list tool, this leaves some gaps in 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 input schema already documents all 4 parameters (page, logDesde, logHasta, per_page). The description adds no additional meaning or context for the parameters beyond what the schema 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 uses a specific verb 'List' and clearly identifies the resource as 'change history logs across all clients.' It distinguishes from sibling log tools (e.g., list_tickets_log, list_internet_connections_log) by specifying the scope is client-related. The return value (snapshots before modifications with timestamps and users) is explicitly stated.
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 get_client or list_tickets_log. There is no mention of prerequisites, when not to use it, or comparisons to sibling tools. The only behavioral instruction is a warning about not fabricating data, which concerns failure handling rather than 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?
With no annotations provided, the description must carry the full burden. It mentions the tool has filters and lists technology codes, which is helpful. However, it does not disclose pagination behavior, default limits, sorting, or whether the response includes only active connections or all. The warning against fabrication is good, but overall behavioral details are sparse for a complex list endpoint.
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 with two sentences plus a code table. The warning is front-loaded for importance. Every sentence adds value, though the technology table could be integrated into parameter descriptions for more structured readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is moderately complete. It covers filters and technology types but lacks details on pagination, response format, and usage with sibling list tools. The warning is a strong addition, but the overall description leaves gaps an agent might need to infer.
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 description coverage is 100%, so the baseline is 3. The description adds value by listing technology codes (R,T,O,H,S,P,D) which are not fully explained in the schema's enum description. However, it does not explain how filters combine (AND/OR logic), default pagination values, or the meaning of the 'relaciones' parameter. The added value is marginal.
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 lists internet service connections and mentions filters. It distinguishes itself from get_internet_connection (which retrieves a single connection) but does not explicitly differentiate from sibling list tools like list_tv_connections or list_phone_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a strong warning against fabricating data on failure, which is valuable usage guidance. However, it does not specify when to use this tool versus alternatives (e.g., get_internet_connection for a single record, or list_internet_connections_log for history), nor does it indicate required prerequisites or 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 carries the full burden. It includes a warning about never fabricating data and to report errors, which adds behavioral transparency. However, it doesn't disclose what the tool does if no logs exist, whether it respects permissions, or how it handles large date ranges.
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 short and to the point, with a front-loaded purpose. The only extra sentence is a warning which adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description does not fully cover what the response looks like (e.g., array of logs, metadata). It also omits the default page size and whether pagination is required. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds the context of date filters but no extra semantic detail beyond what the schema provides. 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 lists change history logs across all internet connections with date filters. The verb 'list' and resource 'internet connections log' are specific, though it doesn't distinguish itself from sibling tools like list_tickets_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions date filters, implying when to use. However, there is no guidance on when not to use this tool versus alternatives, nor any prerequisites or context like required permissions or pagination behavior.
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 of behavioral disclosure. It warns against data fabrication, which is a helpful behavioral constraint. However, it doesn't disclose whether the tool is read-only or destructive, what the response format looks like (e.g., paginated object or raw list), or rate limits. The warning adds value but leaves significant gaps.
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 at two sentences with no wasted words. It front-loads the core purpose and crucial behavioral warning. Every sentence earns its place.
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 8 parameters, no output schema, and no annotations, the description is somewhat minimal. It names the filter dimensions and adds a critical usage warning, but it doesn't describe the return type or pagination behavior. For a tool of this complexity, a bit more context (e.g., 'returns paginated results with connection details') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description provides a high-level summary of filter categories (client, date, status) which loosely groups the parameters, but it adds no additional semantics beyond what the schema already documents (e.g., date formats, enum meanings, or the 'relaciones' parameter). It doesn't enhance the schema's information.
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 lists TV service connections and identifies the three filter dimensions (client, date, status). It distinguishes itself from siblings like list_internet_connections and list_phone_connections by focusing specifically on TV connections. A score of 5 is not given because it doesn't explicitly state the scope (e.g., all connections for a client) or differentiate from the related get_tv_connection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a strong usage caution (never fabricate data, report errors), which guides agent behavior on failure. However, it gives no guidance on when to use this tool vs. alternatives like get_tv_connection (which likely returns a single connection), nor any prerequisites or context about pagination defaults.
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 implies a read-only operation ('Get detailed information'), and includes a valuable warning about not fabricating data on failure. However, it does not disclose other behavioral traits such as required permissions, rate limits, or whether the operation is safe to call repeatedly. The warning adds some transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear purpose, followed by a warning in a new line. It is front-loaded and efficient. The warning, while useful, could be considered extraneous to the core purpose, but it does not significantly bloat the text. Almost every word earns its place, though the warning could potentially be moved to a separate field.
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 no output schema, so the description should explain what the return value contains. It mentions items, consolidated data, or PDF print link, but does not describe the overall structure (e.g., JSON object with invoice fields, line items, etc.). The warning about error handling is a positive addition. For a simple 2-parameter tool, this is adequate but leaves the agent guessing about the return format.
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%: both parameters have descriptions in the schema. The description mentions 'items, consolidated data, or PDF print link' which aligns with the 'include' enum values, but adds no new information beyond what the schema already provides (e.g., 'print_link' is already described as a PDF URL hosted on AWS valid for 30 days). 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 retrieves detailed information about a specific invoice, including items, consolidated data, or PDF print link. It uses a specific verb ('get') and resource ('invoice'), and naturally distinguishes from sibling tools like 'list_invoices' (which lists invoices without details) and 'get_client' (different resource).
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 the tool is used when you have an invoice_id and need detailed information, but it does not explicitly contrast with alternatives like 'list_invoices' for listing or 'search_clients' for filtering. There is no guidance on when not to use it or prerequisites, though the warning about not fabricating data provides indirect error-handling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the hierarchical drilling pattern and the caution about error handling. However, it does not state whether the tool is read-only, if it requires special permissions, or what happens when parent_id is omitted alongside resource_type (e.g., for 'backbones'). A 3 is appropriate as basic behavioral context is present but safety and side-effects are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose and resource types, and uses an emoji and bold to highlight the critical caution about data fabrication. It is efficient and communicates key information without waste, though the second sentence could be more terse.
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 no output schema, the description should explain what the tool returns (e.g., list of objects, summary counts). It does not, leaving return format ambiguous. Parameter documentation is adequate, and the usage context (hierarchical querying) is clear. The tool has moderate complexity (2 parameters, multiple resource types, hierarchical relationships) and the description covers the usage pattern but not the output, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parent_id interacts with resource_type for hierarchy traversal, which goes beyond the schema. However, it does not describe the meaning or format of returned data fields or the 'seals' resource type in detail, so it does not elevate above baseline.
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 ('Query') and specific resource ('FTTx fiber infrastructure'), and then enumerates the sub-resource types (backbones, PONs, NAP boxes, ports, and seals). It distinguishes from sibling tools like search_clients or list_internet_connections by focusing on physical fiber infrastructure, though it could more explicitly differentiate from the sibling get_fttx_trace which also touches FTTx.
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 states how to use resource_type and parent_id to traverse the hierarchy (backbone→PONs→boxes→ports). It also warns against fabricating data when the tool fails. However, it does not specify when NOT to use this tool versus siblings like get_network_element or get_fttx_trace, omitting explicit 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?
No annotations are provided, so the description carries the full burden. It adds a key behavioral trait: the tool may fail, and the agent must report errors honestly. However, it does not disclose other traits like idempotency, rate limits, or whether it is read-only (reasonable given the purpose).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a critical usage warning. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input and a behavioral warning, but does not explain the return value structure or what 'details' are included (no output schema). For a retrieval tool, this leaves some uncertainty about the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having minimal descriptions ('Element ID', 'Type of element'). The description adds the list of valid types and a warning, but does not deepen parameter meaning (e.g., format of ID, case sensitivity). Baseline 3 is appropriate as the schema already describes the parameters.
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 details of a specific element by type and ID', and enumerates all supported element types (node, subnode, VLAN, etc.). This distinguishes it from sibling tools like get_client or get_invoice, which operate on different entities.
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 includes a strong behavioral instruction about not fabricating data on failure, but does not explicitly state when to use this tool versus alternatives (e.g., search_clients or get_network_status). The usage context is implied by the element types, but no direct comparison or exclusion is given.
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 adds the warning 'NEVER fabricate data if this tool fails — report the error to the user instead,' which is meaningful behavioral context about failure handling. However, it does not disclose authentication needs, rate limits, or whether the operation is read-only, leaving gaps in 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 three concise sentences, front-loaded with purpose, followed by type definitions and a critical warning. No excessive detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, filtering dimensions, type semantics, and a failure behavior warning. It does not explain the output structure (no output schema) or pagination behavior explicitly, which leaves some uncertainty for a tool with seven parameters, though the schema covers those details.
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%, giving a baseline of 3. The description adds value by grouping the type codes into invoices, credit notes, and debit notes, which is semantic information not present in the schema's flat list. This grouping helps agents choose appropriate type values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'invoices' and lists filter dimensions (date, type, point of sale). It distinguishes from sibling tools like get_invoice by implying plural listing rather than singular retrieval, and the type code breakdown clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus alternatives such as get_invoice or other list_* tools. It provides no explicit exclusions or alternative suggestions, so an agent receives no guidance for tool selection beyond the tool name.
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 adds a notable warning about not fabricating data if the tool fails, plus a summary of supported filter types. However, it does not disclose read-only status, pagination behavior, or error formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that front-load the purpose ('Search and list...'), mention key filters, and include a critical safety warning. Every sentence earns its place with no fluff.
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 has no output schema and 10 parameters, the description is somewhat thin; it doesn't describe the return structure or pagination behavior. However, the schema covers parameters and the warning adds operational context, making it minimally 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?
The input schema provides 100% coverage with detailed descriptions for all 10 parameters. The description's mention of text search, date range, and tax status only repeats schema information without adding new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search and list ISPKeeper clients with filters', which is a specific verb and resource. It distinguishes this from sibling tools like get_client by highlighting its filter/search scope.
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 searching/filtering clients but does not explicitly state when to prefer this tool over alternatives like get_client or get_clients_summary. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It includes a notable behavioral instruction—not to fabricate data on failure—which is valuable for agent behavior. However, it lacks disclosure of read-only status, authentication needs, rate limits, or error response format. The warning prevents hallucination but does not comprehensively describe the tool's 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 one clear sentence plus a warning—short, front-loaded, and no redundant information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-item retrieval tool with two parameters and no output schema, the description covers the core purpose and provides a critical behavioral warning. It does not detail the return values (basic vs consolidated), common errors, or when to prefer basic over consolidated. Overall, fairly complete but could benefit from a brief output summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description only echoes the optional consolidated flag ('optionally with consolidated data') without adding new meaning or usage details. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a specific collection/payment, with optional consolidated data. This distinguishes it from sibling tools like list_collections (which returns multiple items) and get_invoice (different entity).
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 when-to-use or when-not-to-use guidance is given, nor are alternatives mentioned. However, from the tool name and sibling context, its intended use (getting a single collection) is implied. A clearer statement like 'Use this instead of list_collections when you have a specific collection_id' would raise this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It correctly implies a read operation and notably includes a strong warning against fabricating data on failure, advising to report errors instead. While it could mention idempotency or authentication, the error-handling instruction adds valuable safe-use context beyond the default.
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 no fluff. The first succinctly states purpose and optional data. The second provides a critical safety directive. Every word earns its place, making it easy to read and process.
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 retrieval tool with two parameters and no output schema, the description covers core functionality and adds error-handling guidance. It is missing explicit mention of the default value for include (detail) and whether multiple values can be combined, but these are minor gaps. Overall, it is largely self-contained and sufficient for an agent to understand the tool's role.
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 defines the include enum values clearly. The description summarizes the optional attachments, reinforcing the schema but not adding new meaning. It slightly improves clarity by listing them in prose, but does not explain behavior like default when include is omitted or whether multiple values are allowed (schema implies single-select). 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 retrieves detailed information about a support ticket, listing optional inclusions (photos, movement log, checkin/checkout, chat attachments). This distinctively differentiates it from siblings like list_tickets (listing) and list_tickets_log (log entries), providing a specific verb and resource with scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_tickets or get_client. It does not mention context, prerequisites, or exclusions. The sibling list is provided externally but the description itself offers no decision-making support.
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 must disclose behavior. It clearly states the tool is read-only (no mutation) and includes a strong honesty directive to avoid hallucination. This adds trustworthy behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two well-structured sentences. The warning is front-loaded with an emoji for attention, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is parameterless and has no output schema, the description is nearly complete. It explains the behavior (read-only), the expected output (summary counts), and provides a fail-safe instruction. The only minor gap is not specifying the time period or criteria for 'active'.
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 0 parameters, so no explanation is needed. The description adds meaning by specifying the output content (total and active client counts), which is helpful.
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 specifies the verb 'Get' and the resource 'a quick summary of total and active client counts', making the purpose clear. It does not explicitly differentiate from siblings like 'search_clients' or 'get_client', but the mention of 'summary' implies a broader, aggregative function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage note about not fabricating data on failure, but does not explain when to use this tool over siblings. The summary nature is implied, but explicit guidance on when not to use it or alternatives is missing.
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 tool's behavior (getting detail or log) but lacks information on behavioral traits such as authentication requirements, rate limits, potential side effects, or error handling beyond the warning. The warning about not fabricating data adds some transparency but overall is 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 plus a clear warning. Every part is essential: the main action, the optional alternate mode, and the critical usage constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 well-documented parameters with 100% schema coverage and no output schema, the description is adequate for understanding what the tool does and its modes. However, it lacks completeness for the 'log' mode (e.g., date filtering, log format) and does not describe the output structure. Since there is no output schema, more context would be beneficial.
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 any parameter-specific semantics beyond what the schema provides (e.g., the 'include' enum values or 'connection_id' format). Thus it meets the baseline without exceeding it.
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 gets detailed information about an internet connection or its change log. The verb 'Get' and the resource 'internet connection' are specific, and the description distinguishes the two retrieval modes ('detail' vs. 'log'). It stands out from siblings like get_tv_connection or list_internet_connections which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns against fabricating data and instructs to report errors to the user, which is a clear when-not usage guideline. However, it does not mention when to use this tool versus sibling tools like list_internet_connections (which lists connections) or the various log tools, missing an opportunity for better guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly discloses the read-only nature implicitly via 'List' and adds a critical behavioral warning about never fabricating data if the tool fails, which is essential for an AI agent. This goes beyond merely stating the purpose.
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 that clearly state purpose and provide a critical usage warning. Every word earns its place, and the warning is front-loaded right after the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (1 param, enum) and no output schema, the description adequately covers the tool's purpose and behavior. The only minor gap is that it doesn't hint at the output format (e.g., list of objects), but with no output schema, the agent can infer from the resource types. The behavioral warning compensates for missing annotations.
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 the single 'resource' parameter with an enum. The description adds no further semantics about the parameter beyond repeating the enum values in the list, but the enum itself is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and enumerates the specific resources it covers (localities, branches, users, etc.), making the scope very clear. It also distinguishes itself from sibling tools by being the sole tool for auxiliary/reference data, while siblings focus on clients, invoices, connections, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use for non-client, non-financial, non-connection auxiliary data, but it does not explicitly state when to use it versus alternatives or when not to use it. The warning about not fabricating data provides a fallback behavior but no usage alternative.
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?
Since no annotations are provided, the description bears full responsibility for behavioral disclosure. It warns about data fabrication with a 'NEVER' directive and the '⚠️' icon, which is critical for an AI agent. It also implies the tool is read-only (list) and may fail, but does not disclose rate limits, authentication needs, or pagination behavior beyond the schema's default 50 per page. Still, the fraud warning is a strong transparency element.
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 relatively short (3 sentences) and front-loads the main purpose. The warning about data fabrication is important but could be integrated more tightly. There is no clutter or redundancy. It earns points for being succinct while still covering purpose and a strong behavioral note.
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 8 parameters, no output schema, and no annotations, the description covers the core purpose, key filters, and a critical behavioral warning. It does not describe return format, error scenarios beyond the fabrication warning, or how pagination works beyond per_page default. For a list tool with good schema documentation and no output schema, this is reasonably complete but could include more on response structure.
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 context by mentioning filterable dimensions (client, date, cut-off status) and the mobile identification hint, but does not explain each of the 8 parameters beyond what the schema already provides. The schema itself is detailed (e.g., enum values, date format hints), so the description's added semantic value is modest.
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 'List' and identifies the resource as 'phone/telephony service connections' with an explicit mention of 'SSMovil mobile'. It distinguishes itself from sibling tools like 'list_internet_connections' and 'get_phone_connection' by specifying the scope includes mobile connections and by listing available filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by listing filterable fields (client, date, cut-off status) and explaining how to identify mobile/SSMovil connections via 'telefonia_plan_movil=Y'. It also includes a strong warning against fabricating data when the tool fails. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'get_phone_connection' or 'list_internet_connections_log', 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns about not fabricating data on failure, which is a crucial behavioral trait. However, since no annotations are provided, the description carries the full burden. It does not disclose other behavioral aspects such as rate limits, authentication needs, or specific performance characteristics. The warning is valuable but partial.
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: one sentence for the core purpose, and one sentence for critical behavioral guidance. Every sentence earns its place with no wasted words. It is front-loaded with the main action.
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 1 parameter, no output schema, and no nested objects, the description covers the essential purpose and adds a crucial caveat. It is sufficient for an agent to invoke correctly. However, it could briefly mention what fields the detailed information includes to aid in deciding if this tool is needed over others.
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 has 100% coverage with one required parameter 'connection_id' and its description 'Phone connection ID'. The description does not add any extra meaning beyond what the schema already provides, such as format examples or location of the ID. According to the rubric, high schema coverage warrants a baseline of 3, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('detailed information about a specific phone/telephony connection'), and explicitly includes the variant ('includes SSMovil mobile'). This distinguishes it well from sibling tools like 'list_phone_connections' (which lists) and 'get_internet_connection' (which gets a different resource).
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 needing details of a specific connection, contrasting with listing tools. The explicit warning 'NEVER fabricate data if this tool fails — report the error to the user instead' provides clear guidance on usage behavior in failure cases, but it does not explain when NOT to use it or suggest alternative tools for specific scenarios.
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 were provided, so the description carries the full burden. It discloses that the tool returns a list and accepts optional filters, and importantly warns the agent not to fabricate data if the tool fails, which is a critical behavioral trait. It could mention pagination or response format but is generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 20 words. It front-loads the core purpose and then adds the critical caveat about not fabricating data. Every sentence earns its place, and there is no wasted text.
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 there is no output schema and 3 parameters with 100% schema coverage, the description is reasonably complete. It explains the tool's purpose and key filters, but could optionally mention the expected return format or default behavior (e.g., whether non-deleted, non-discontinued plans are returned by default). However, the enum defaults are clear from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that the 'borrado' and 'discontinuo' parameters filter for deleted and discontinued plans respectively, which reinforces and clarifies the enum options already documented in the schema. The 'q' parameter for text search is implied by the schema, but the description does not provide additional detail 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 verb 'list' and the resource 'internet plans', and specifies optional filters for deleted or discontinued plans. This distinguishes it from sibling tools which focus on clients, invoices, connections, tickets, and network infrastructure.
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 does not explicitly state when to use this tool versus alternatives like list_internet_connections or search_clients. However, it includes a warning against fabricating data on failure, which provides operational guidance but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly warns against fabricating data on failure, which is a key behavioral trait. However, it does not disclose other aspects like return format, read-only nature, or authentication requirements. Still, the warning adds significant value beyond what the schema provides.
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: three sentences with no wasted words. The first sentence front-loads the purpose, the second provides an exclusion, and the third delivers a critical warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers purpose, usage boundaries, and error handling. It omits the return format, but for a straightforward retrieval tool, the agent can infer it returns a list of the requested service type. This is adequate but not fully comprehensive.
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 lists the enum values (invoices, collections, tickets, additionals) which matches the schema, but does not add any additional parameter semantics (e.g., format, constraints, or examples). The alternative usage guidance is about tool selection, not 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 verb 'Get' and the resource 'services for a specific client', and enumerates the exact service types (invoices, collections, tickets, additionals). It also distinguishes itself from the sibling tool 'get_client' by explicitly stating its scope and when to use the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it tells the agent when NOT to use this tool (for internet/TV/phone connections) and names the alternative tool and its parameters ('get_client with relaciones=coninter,contv,contel'). It also includes a behavioral warning about error handling, giving clear instructions to avoid fabrication.
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 clearly indicates the tool is a read operation ('Trace') and warns about failure behavior ('NEVER fabricate data… report the error'). This is strong transparency for an unannotated tool. However, it does not mention whether the trace is recursive, what the depth limit is, or how errors manifest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence conveys the core purpose and chain, and the second adds a critical usage rule. Every word earns its place. It is front-loaded with the action and target.
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 moderate complexity (2 params, enum, no output schema), the description covers the essential behavioral and usage aspects. The missing output schema is offset by the description implying the trace chain. The only gap is the lack of mention of error conditions (e.g., what happens if the resource is not found).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds value by stating the tool's upward-navigation purpose, which implicitly explains the role of 'resource_type' (starting point) and 'resource_id' (specific element). However, it does not elaborate on valid enum values beyond what the schema lists, nor does it explain the expected format of resource_id.
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 ('Trace'), the target ('FTTx element'), and the direction ('upward through the hierarchy'). It also enumerates the specific chain of resources (port→box→PON→backbone), leaving no ambiguity about what the tool does. The purpose is distinct from sibling tools like 'get_network_element' (which likely fetches a single element without tracing) or 'list_fttx_infrastructure' (which lists elements).
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 warns against fabricating data if the tool fails, instructing the agent to report the error instead. However, it does not explicitly state when NOT to use this tool versus alternatives like 'get_network_element' or 'list_fttx_infrastructure'. The upward-trace behavior implies it's for hierarchical navigation, but no direct exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It clearly states the tool fetches data (not a mutation) and adds critical honesty instructions about error handling, which goes beyond typical transparency. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: purpose, parameter usage, and a critical behavioral warning. It is front-loaded with the core purpose and uses a clear warning marker (⚠️). Extremely efficient.
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 has 3 parameters (fully described in schema), no output schema, and is relatively simple, the description is complete: it explains the core function, parameter options, and error handling expectation. Nothing essential is missing for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaning to include (change log, payment commitment) and relaciones (expanding connections with examples), but this is mostly a terse summary of what the schema already says, earning a baseline 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 'Get detailed information about a specific client,' which is a specific verb + resource. It distinguishes itself from siblings like search_clients (searching) and get_client_services (services) by focusing on a single client with options to include change logs or payment commitments and expand relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use include and relaciones parameters, and includes a strong warning ('NEVER fabricate data if this tool fails — report the error to the user instead'), which tells the AI what NOT to do. This is a model for usage guidelines.
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:

[![mcp-ispkeeper MCP server](https://glama.ai/mcp/servers/dmayan-ss/mcp-ispkeeper/badges/card.svg)](https://glama.ai/mcp/servers/dmayan-ss/mcp-ispkeeper)

Score Badge

Copy to your README.md:

[![mcp-ispkeeper MCP server](https://glama.ai/mcp/servers/dmayan-ss/mcp-ispkeeper/badges/score.svg)](https://glama.ai/mcp/servers/dmayan-ss/mcp-ispkeeper)

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/dmayan-ss/mcp-ispkeeper'

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