GLPI MCP Server v2
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Tools are clearly grouped by entity (ticket, problem, change, asset, user, group), with consistent action prefixes. However, the get_X_timeline tools are redundant because get_X already includes the timeline, creating potential confusion. Otherwise, distinct purposes are clear.
Naming Consistency5/5All tools follow the glpi_verb_noun pattern perfectly, using lowercase snake_case consistently. Verbs like search, get, create, update, add, list are used uniformly across entities.
Tool Count2/5At 30 tools, the server is heavily over-scoped, exceeding the 25-tool threshold. While the domain is broad, many tools are redundant (e.g., timeline vs. get) and could be consolidated, making the count excessive for maintainability.
Completeness2/5Significant lifecycle gaps exist: no delete operations for tickets, problems, changes, or knowledge base items. Asset, user, and group management are read-only, lacking create/update/delete. This causes dead ends for agents attempting full CRUD workflows.
Average 3.2/5 across 29 of 30 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on
- 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not mention side effects, permissions, idempotency, or any behavioral details. The tool could be destructive or have side effects, but nothing is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is concise and gets to the point, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention return values, error conditions, or any other context that would help an agent understand the full behavior or requirements of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information beyond the schema. The schema only provides generic names and simple descriptions ('ID do problem' and 'Campos a serem atualizados'), and the input object is open-ended with additionalProperties. The description does not clarify what fields are valid or required, making it insufficient for effective invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Atualiza' - updates) and the target resource ('um problem existente' - an existing problem), distinguishing it from create/get/delete operations. However, it does not specify what aspects of the problem can be updated, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 instead of others (e.g., when to update vs. create, or any prerequisites). The description lacks any context for selection among sibling tools.
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?
The description does not disclose any behavioral traits beyond the basic action. It does not mention side effects, permission requirements, rate limits, or whether the operation is safe or has impact on the ticket's state. Since no annotations are provided, this lack of transparency leaves users uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. It is front-loaded and contains no unnecessary words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool, the description is incomplete. It does not mention what happens after adding a follow-up (e.g., return value, success indication), any error conditions, or whether a valid ticket ID is required. Given the tool's simplicity, this lack of context leaves important gaps for the user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters (ID, content, is_private), which gives high coverage. According to the rubric, a baseline of 3 is appropriate. The description itself adds no additional meaning to the parameters, such as constraints or format expectations, but the schema already covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds a follow-up to a ticket's timeline, using the verb 'Adiciona' and specifying the target as 'timeline de um ticket'. This distinguishes it from similar tools for problems and changes, but it could be more specific about what a follow-up entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing an existing ticket, or any conditions that would make this tool preferable to other related tools like glpi_add_problem_followup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states a creation action but does not disclose any behavioral traits: what the creation implies, any side effects, required permissions, or what happens on success/failure. Very minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, no fluff. It is appropriately sized and front-loaded. Could be more informative, but as written it is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a create operation with no annotations and no output schema. The description is just one line, giving no detail about required fields, validation, or response. Given the complexity of creating a change object, this is insufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'input' parameter, which is documented as 'object fields to be created (e.g. name, content)'. The description adds no extra semantics beyond the schema, so the baseline 3 applies. It does clarify it accepts an object, but that is already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Creates a new change' (in Portuguese). It is a clear verb+resource sentence, but it does not distinguish from sibling tools like glpi_create_ticket or glpi_create_problem, which have identical structure. It is not a tautology, but lacks detail to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No indication of prerequisites, required fields beyond 'input', or typical scenarios. The tool exists among many create/search tools, but no context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a read operation ('returns stats') but does not mention any side effects, authorization needs, rate limits, or output format. It is not misleading, but it is severely lacking 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff. It is concise and front-loaded, but it is almost too terse to be helpful. The length is appropriate for the simple purpose, but it lacks the substance needed for a full tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 should explain what statistics are returned or any constraints. It does neither, making it incomplete for an agent trying to understand the tool's behavior and output. The simple schema does not compensate for the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'id' with 'ID do ticket' (100% coverage). The description adds no further meaning or usage details, so the baseline score of 3 is appropriate as it does not enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns ticket statistics, which is a clear purpose but essentially restates the tool name without adding detail about what specific statistics are provided. It does not distinguish itself from siblings like glpi_get_ticket or glpi_get_ticket_timeline, other than the name itself, so it is not a 4 or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools (e.g., glpi_get_ticket, glpi_search_tickets). The description does not mention any context, prerequisites, or alternatives, so it fails to help the agent choose correctly.
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 at all, the description does not state how it handles read operations, side effects, permissions, or data scope. The phrase 'including used and managed items' suggests it can query user-managed assets, but this is not detailed enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single direct sentence, no redundant parts, and clearly front-loaded with an action ('Retorna...').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no return-value schema, no additional details on how the context is formed, no mention of permissions or errors, and the 'context' object itself is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The id parameter is described as 'user ID' (ID do usuário) and the schema covers 100%. The description adds a little beyond the field name, but not much and does not specify e.g. whether it is a numeric ID or a user key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says "returns the context of a user, including used and managed items." It clearly identifies the resource as a user context, but is vague about what a 'context' comprises, and does not distinguish whether it is a general user retrieval, inventory vs. tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool instead of glpi_search_user, glpi_get_computer, or other sibling tools. There are no prerequisites or alternatives.
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 does not disclose behavioral traits such as whether the operation is read-only, what the output structure looks like, whether it requires specific permissions, or any caveats (e.g., performance implications, data ranges). The description is generic and does not add behavioral context beyond the simple 'returns stats'. This is insufficient for a tool that aggregates 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence. It is front-loaded and to the point. No fluff. However, it is somewhat sparse for a tool with multiple parameters and potential complexity. It earns a 4 because it is efficient, though it could benefit from a tiny bit more detail while maintaining conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, no output schema, and no explanation of return values, the description is incomplete. It does not mention the output format, whether the stats are counts, sums, or other metrics. It also doesn't explain how date ranges interact or what 'associated assets' means precisely. For a tool that computes stats, more context is needed about what data is returned and any limitations. Because of the lack of annotations and output schema, the description should carry more weight and it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all parameters have descriptions. The 'itemtype' is an enum with allowed values, and date_start/date_end are described as dates with format. The description adds no new parameter semantics beyond the schema, but since coverage is high, the baseline is 3. The description does not explain the relationship between parameters (e.g., date_start/date_end are optional and define a range) but the schema already conveys that. Since the tool name suggests 'stats', the parameters are adequately specified. A score of 4 is justified because the schema descriptions are precise and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns statistics of assets associated with tickets, changes, or problems, which is a clear verb+resource. However, it doesn't distinguish from siblings like glpi_get_ticket_stats, glpi_get_problem_stats, or glpi_get_change_stats, which likely also compute stats. The name 'glpi_get_asset_stats' suggests it's focused on assets, but the description lacks specifics on what exactly the stats include. It's clear but not differentiated from similar stats tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, when one needs asset stats vs. ticket stats or problem stats. The description doesn't state any conditions, limitations, or context for use. It only says the tool returns stats, but not when to choose it over sibling stats tools. Given multiple sibling tools with similar names and purposes, the lack of guidance is a notable gap.
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 transparency burden. It only implies a mutation via 'Cria' (creates) but does not disclose consequences, permissions, response behavior, or anything else about the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It is efficient, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with one loosely structured object parameter, no annotations, and no output schema, the description is under-specified. It does not explain what fields should be provided, any constraints, or what a successful creation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters and the 'input' property is already described with examples like name and content. The description itself adds no parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Cria um novo problem' (creates a new problem), identifying both the action and the resource. It is clear enough to distinguish from sibling tools like create_ticket or create_change, though it lacks any additional scope or uniqueness details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as glpi_update_problem, glpi_create_ticket, or glpi_create_change. No prerequisites, exclusions, or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only implies a read operation by saying 'returns stats' but doesn't mention permissions, side effects, or what specific data is returned. This is insufficient for a stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, directly stating the purpose. It is front-loaded and efficient, though it lacks structure beyond that.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should clarify what statistics are included and any relevant context. It only says 'returns stats' without any detail, making it incomplete for a stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', and the description adds no additional meaning beyond the schema. Per the baseline for high coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns the statistics of a change, with a specific verb and resource. However, it does not elaborate on what statistics are included or differentiate from similar stats tools for tickets and problems, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like glpi_get_ticket_stats or glpi_get_problem_stats. It gives no context for use cases, 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?
No annotations are provided. The description discloses that it returns hardware and software context, but says nothing about safety, permissions/authorization, access sensitivity, or side effects. For a get operation it seems read-only, but that is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise Portuguese sentence in imperative form ('Retorna...') providing the essential scope. No extraneous details or fluff; but no structural formatting to separate scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's behavior is moderately described: returns the full context of one computer (hardware and software). However, with no annotations, no output schema, no distinctions between full inventory vs simple details, and no usage conditions/caveats (e.g., requires admin privileges), the completeness is not fully justified. An output schema would have helped express the return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required parameter 'id'. However, the description's 'ID do computador' adds no semantic depth beyond the schema's own description. No additional parameters or format hints are given; the method signatures are simple and clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'retorna' and defines the resource as 'contexto completo de um computador', listing hardware (CPU, memória, disco, rede) and software. This clearly identifies a single-computer context lookup tool, though it does not explicitly distinguish itself from sibling tools like glpi_list_computers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over alternatives. The description says what it returns but does not state prerequisites, exclusions, or scenarios where the full context is needed versus using list tools or get_computer.
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 bears full responsibility for behavioral disclosure. It mentions returning a complete context including timeline, which implies convenience but does not disclose side effects (though likely read-only), the size of the response, or any error conditions. It does not state whether it is read-only, which is pertinent since many sibling tools are reads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the primary function and the key benefit (no multiple calls). It is front-loaded with the action and resource. While it could be slightly more specific, it has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that aggregates multiple calls into one, the description is under-specified. It does not indicate what the timeline includes, what other context is covered, whether it includes follow-ups or comments, or the output structure. Given no output schema, this leaves the agent with inadequate expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter, 'id', which is documented as 'ID do problem'. The description adds no further meaning beyond the schema, but the schema already is sufficient, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Retorna' (returns) and the resource 'UM problem' (a problem), and adds that it includes 'timeline' context, though the description does not extensively distinguish from sibling tools beyond the emphasis on timeline and complete context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives like glpi_get_problem_timeline or glpi_get_problem_stats. It only implies that the tool aggregates multiple calls, but no explicit guidance on choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'returns statistics.' It implies a read operation but does not explicitly state that it is read-only, what statistics are included, how the response is structured, or whether any side effects exist. This is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately communicates the core action and object. Despite being short, every word contributes to the stated purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with no output schema, so the description should describe the nature of the returned statistics. However, 'estatísticas de um problem' is ambiguous (e.g., counts, timings, status breakdowns) and does not explain response format or any business context. The description is not complete enough for an agent to confidently use the tool without further guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the sole parameter 'id', described as 'ID do problem'. The description adds no additional parameter-specific meaning beyond what the schema already provides. Per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb ('Retorna' / 'returns') and a resource ('estatísticas de um problem'), making it evident the tool retrieves problem statistics rather than the problem record or its timeline. It distinguishes from siblings like glpi_get_problem and glpi_get_problem_timeline through the 'statistics' concept, though it does not explicitly frame it as an alternative to those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus other problem-related tools. It does not mention conditions, prerequisites, or alternatives. There is only a bare statement of what the tool returns, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It does not state that the operation is read-only, nor does it disclose pagination behavior, return format, or performance implications beyond the schema's note about include_specs. The description omits the include_specs option entirely, leaving the agent unaware of its existence and potential latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the core purpose and key features without any filler. It is fully front-loaded and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, so the description should adequately set expectations. It covers pagination and filter but completely omits the include_specs parameter, which is a significant feature. It also lacks any note about the return shape or usage context, making the description incomplete for an agent unfamiliar with the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the input schema. The description mentions start, limit, and filter but adds no new meaning beyond what the schema already provides; the filter example is also present in the schema. Thus, it meets the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'searches and lists computers (Assets)', providing a specific verb and resource. It distinguishes from sibling tools like glpi_search_tickets by explicitly naming the resource (computers), but does not explicitly contrast with glpi_get_computer or other asset-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as glpi_get_computer for individual assets or glpi_get_asset_stats for aggregated metrics. It only mentions capabilities (paginação and filtros) without context on when these are relevant or preferred.
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 burden of behavioral disclosure. It only mentions pagination and filtering, but does not disclose return format, default limits, error behavior, or whether it's read-only (though 'search/list' implies read). It doesn't contradict annotations since none are present, but it's minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the main purpose. It efficiently mentions pagination and filters without unnecessary words. However, it could have included a bit more context about RSQL syntax, but it's appropriate for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and no output schema, the description is somewhat thin. It covers the essentials (search, pagination, filter) but lacks details on how the filter works, examples, or expected results. For a simple tool with good schema coverage, it's minimally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the base is 3. The description adds minimal value by stating pagination (start, limit) and filter in RSQL, which aligns with the schema. It doesn't add details like parameter formats beyond what's in the schema, but it repeats the key concepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches and lists changes ('Busca e lista changes'), using specific verbs and a resource. It distinguishes from siblings like glpi_search_tickets and glpi_search_problems by the resource name, though it doesn't explicitly differentiate from glpi_get_change, but the listing/listing aspect is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It only mentions pagination and filters, but doesn't state when to prefer this over glpi_get_change or glpi_search_* for other entities. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only says 'updates fields' without explaining side effects, permissions required, idempotency, or the response format. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence in Portuguese, with no filler words or redundant explanations. It is appropriately terse, though its brevity limits the information conveyed, still earning a high conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested 'input' object and no output schema, the description is important for clarifying update semantics. It only says 'updates fields' with no examples, constraints, or guidance on how to structure the 'input' parameter, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (id and input), and the description does not add substantive detail beyond the schema. Since schema coverage is 100%, the baseline of 3 applies, and the description adds no complementary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Atualiza' (updates) and the target 'campos de um ticket existente' (fields of an existing ticket). It is specific enough to distinguish from creation or retrieval, though it does not explicitly contrast with other update tools (e.g., update_problem).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no mention of limitations. The description simply restates the tool's function without contextualizing its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'creates' without mentioning permissions, input requirements beyond the schema, potential side effects, or error behavior, which 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly communicates the core purpose without redundancy. It is appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the description lacks essential context for an agent, such as typical use cases, required fields, or interaction with sibling creation tools. The absence of output schema and annotations means the description should compensate, but it fails to do so comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'input' parameter, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already states ('Campos do objeto a ser criado').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cria um novo ticket' clearly states the tool creates a new ticket, with a specific verb and resource. It distinguishes from siblings like glpi_create_problem and glpi_create_change by explicitly targeting tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as create_problem or create_change. There are no usage exclusions, prerequisites, or references to sibling tools, leaving the agent without context for selection.
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 not provided, so the description must disclose behavioral traits. It states it 'adds' a followup, which implies mutation, but it does not specify whether it appends to a timeline, whether it overwrites existing content, or if it is a synchronous action. It also doesn't mention any permission requirements or potential limits. For a mutation tool with no annotations, the description is insufficiently transparent about behavior, so a score of 2 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Portuguese, perfectly front-loaded with the action and target. Every word serves a purpose, and there is no filler. This is an ideal length for a tool description, so a 5 is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple followup addition with 3 parameters and no output schema. The description is complete for a straightforward mutation: it indicates the action and target. However, given that annotations are absent, the description could have added context about the expected outcome (e.g., whether it's reflected in the timeline immediately) or whether the followup is added as private by default. These are minor gaps, making the description adequate but with room for enrichment, hence a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% descriptor coverage for all three parameters, so the schema already provides meaning. The description adds no additional semantics beyond the schema. Per the rubric, with high schema coverage, a baseline of 3 is appropriate. The description doesn't clarify details like formatting of content or whether is_private defaults to false, but the schema covers the essentials, so a 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Adiciona um followup (acompanhamento) à timeline de um problem' which is a clear and specific action: adding a followup to a problem's timeline. It distinguishes it from siblings like glpi_add_ticket_followup and glpi_add_change_followup by indicating it is for problems. A score of 4 is appropriate because while it clearly states the verb and resource, it does not explicitly contrast with its siblings, though the name itself already differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to add a followup to a problem) but provides no explicit guidance on when to use this over alternatives, nor does it mention when not to use it. It does not mention whether this is a privileged action or requires prior authorization. Since there are clear sibling tools for tickets and changes, a brief note could help. The context signal shows no annotations and the description gives no exclusions, so the usage context is implied and not fully explicit, warranting a 3.
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 must disclose behavioral traits itself. It does not mention that the tool is read-only, any error conditions, authentication requirements, or side effects. It simply restates the function without adding transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's function. It is appropriately sized with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description gives enough to understand its core purpose. However, it omits details about the return payload structure, ordering, or pagination, which could be relevant for an agent consuming the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (id) with 'ID do change', and the description adds no extra meaning beyond confirming it refers to a change. Since schema coverage is 100%, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns the timeline of a single change, listing example content (followups, tasks). It effectively distinguishes from sibling tools like glpi_get_change (which fetches change details) and glpi_get_change_stats (which provides statistics) by explicitly focusing on the timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of use cases, prerequisites, or exclusions. The description only says what it does, not when it should be selected over other timeline-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?
Without any annotations, the description must carry the full disclosure burden. It mentions pagination and filtering but omits critical read-only status, return format, or default limits. For a search operation, the lack of side-effect clarity is notable but not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that front-loads the primary purpose and then references the parameters. No wasted words; it efficiently communicates the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search endpoint, the description covers the essentials. However, it lacks important context like response structure, default pagination behavior, or examples, especially since no output schema is present. It's minimally sufficient but leaves room for ambiguity in advanced cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds grouping (pagination vs filter) and clarifies that 'filter' uses RSQL, but this repeats the schema's intent without additional semantic depth. Baseline of 3 for high coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Busca e lista tickets' clearly states the action (search/list) and resource (tickets). It differentiates itself from siblings like glpi_get_ticket (single ticket) and other entity searches, though it could be more explicit about its exclusive use for listing with filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching tickets with pagination and filters, but does not explicitly name alternatives or state when not to use it. It stops at delivering the core function without guidance on selection among similar 'search' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that a followup is added to a change's timeline but does not disclose side effects such as triggered notifications, permission requirements, whether is_private defaults, or idempotency. For a mutation tool, this is a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the full purpose without redundancy. The parenthetical clarification '(acompanhamento)' adds value for non-native speakers. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema or nested objects, the description is minimally complete but doesn't add context about when the is_private flag matters or what happens after a followup is added (e.g., notifications, visibility). Adequate but not enriching beyond the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the schema documenting all 3 parameters (id, content, is_private). Since the schema already handles parameter documentation, the baseline of 3 applies; the description adds no additional parameter semantics, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adiciona um followup (acompanhamento) à timeline de um change' uses a specific verb (Adiciona/adicionar) and clearly identifies the resource (a followup on a change's timeline). It uniquely distinguishes this from the sibling ticket/problem followup tools by its clear change-module 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the action verb — the agent can infer this tool is for adding followups to change entities. However, there is no explicit guidance on when to prefer this over the analogous ticket/problem followup tools, nor any exclusions or prerequisites (e.g., requiring an existing change).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool returns timeline data but doesn't explain what types of events are included (beyond followups and tasks), whether there are any side effects (likely read-only but not stated), or how comprehensive the timeline is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It provides the key information without wasted words, appropriate for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no output schema, and no annotations, the description is minimal but adequate for a basic retrieval tool. However, it lacks detail on the nature of the timeline content, which could be important for agent decision-making. Given the simplicity, completeness is acceptable but could be enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'id' with a description, so schema description coverage is 100%. The description doesn't add extra meaning beyond the schema, but the baseline is 3 for high coverage. No additional parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the timeline of a single ticket, including followups and tasks. It distinguishes from sibling tools like glpi_get_ticket and glpi_add_ticket_followup, though it could be more explicit about the resource type (it's implied from the name and siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving timeline data for one ticket, but provides no explicit guidance on when to use this tool versus alternatives like glpi_get_ticket or glpi_get_ticket_stats. No exclusions or context about prerequisites are 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 burden. It mentions pagination and filters, which are behavioral traits, but does not disclose return format, default behavior, or any side effects. For a read-only search tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and mentions key capabilities. No wasted words, and it is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no output schema, and full schema coverage, the description is adequate. However, it could benefit from mentioning the return format or default pagination behavior, but for a search tool with clear parameters, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value by mentioning pagination (start, limit) and filters (filter), but does not elaborate on the language parameter or provide examples beyond what the schema offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches knowledge base articles, with a specific verb ('Busca') and resource ('artigos na base de conhecimento'). It distinguishes from siblings like glpi_search_faq and glpi_get_knowbase_item by focusing on search with pagination and filters, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching knowledge base articles with pagination and filters, but does not provide explicit guidance on when to use this tool versus alternatives like glpi_search_faq or glpi_get_knowbase_item. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that it updates fields. It does not disclose whether the update is partial or full, what permissions/authorization are required, whether the operation is reversible, or what the response contains. This is a significant gap 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/5Is 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 target. There is no redundant or extraneous content, and it is appropriately sized for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description combined with the fully documented schema is adequate for basic usage, but the tool has no output schema and no annotations, leaving gaps around return values, side effects, and error behavior. It is minimally complete for a two-parameter update operation but not rich enough to be considered fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both required parameters ('ID do change' and 'Campos a serem atualizados'). The tool description adds no new meaning beyond what is in the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Atualiza campos de um change existente' clearly states a specific verb (update) and resource (fields of an existing change), making the tool's function immediately obvious. It also differentiates from sibling tools like glpi_create_change and glpi_update_ticket by explicitly targeting the 'change' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'change existente' implies this tool is for modifying an already-created change, which provides basic context for when to use it. However, there is no explicit guidance about when not to use it, no mention of prerequisites like the change needing to exist, and no comparison with alternatives such as glpi_add_change_followup.
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 of behavioral disclosure. It states the tool returns the full content, which indicates a read-only operation, but it does not mention any additional behaviors such as error handling, authentication requirements, or the effect of the optional 'language' parameter. For a simple get operation, this may be acceptable, but it lacks any caveats or specifics that would enhance transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the core function. It is front-loaded with the action and resource, containing no filler or redundant information. However, it is extremely brief, which might border on under-specification, but for a simple get tool, it is appropriately concise without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema, no nested objects), the description minimally covers the essential purpose. However, it does not inform the agent about when to use this tool over search alternatives, nor does it mention any prerequisites (e.g., needing a valid ID). The lack of usage guidance and behavioral notes means it is not fully complete for an agent to decide optimally. With no annotations and a minimal description, it only meets the basic requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (id and language), achieving 100% coverage. The tool description adds no additional semantic information about the parameters. According to the rubric, with high schema coverage, the baseline is 3. The description does not clarify how the language parameter affects the returned content (e.g., whether it falls back to a default). Thus, it neither adds nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning the full content of a knowledge base article. It uses a specific verb ('Retorna') and resource ('artigo da base de conhecimento'). This distinguishes it from sibling search tools like glpi_search_knowbase and glpi_search_faq, which are for finding articles. The description is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 glpi_search_knowbase or glpi_search_faq. It implies usage for retrieving a specific article by ID, but it does not provide explicit guidance on when to choose this tool (e.g., 'Use this when you have the article ID' or 'Prefer this over search for direct access'). The lack of explicit usage context makes it only adequate, not superior.
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 for behavioral disclosure. It does convey that this is a read operation returning timeline items, naming 'followups' and 'tasks'. However, it offers no detail on output format, ordering, error behavior, or the breadth of 'etc.', so transparency beyond the basics is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with zero waste. Every word earns its place, specifying the verb, resource, scope cardinality ('UM'), and examples of contents. It is appropriately sized for a simple read-from-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward single-parameter read operation with no output schema, this description is largely sufficient. The examples 'followups, tasks, etc.' give the agent a reasonable sense of the payload scope. It loses a point only because the trailing 'etc.' is vague and no guidance is given on filtering, pagination, or large timelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'id' param is documented as 'ID do problem'). The description reinforces that 'id' refers to a problem, matching the schema. Since the schema already fully describes the single parameter, the description adds no new parameter-level detail, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the timeline of a single problem, listing example contents (followups, tasks). It uses a specific verb ('Retorna') and resource ('timeline de UM problem'). It doesn't explicitly contrast with sibling tools, though the provider name glpi_get_problem_timeline itself is quite descriptive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(followups, tasks, etc.)' gives an implied sense of what this timeline includes, which indirectly signals when to use it versus glpi_get_problem or glpi_get_problem_stats. However, there is no explicit when/when-not or alternatives named, so the guidance is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects or error behavior, leaving the agent uncertain about read-only nature or failure cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, stating the purpose and key benefit without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and parameter but lacks an output schema or details on the returned structure, though the mention of timeline gives some insight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is clearly described as 'ID do change' and the schema covers 100% of parameters, so the meaning is unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full context of a change including timeline, distinguishing it from siblings that might only fetch the timeline or other details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'sem precisar de múltiplas chamadas' (without needing multiple calls), implying it consolidates data, but does not explicitly compare with alternatives like glpi_get_change_timeline.
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 transparency burden. It discloses a non-destructive search/list behavior and pagination/filter capabilities, but it does not mention pagination defaults, maximum limits, sorting, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single two-clause sentence that front-loads the main action ('Busca e lista problems') and then compactly enumerates supported capabilities. Every word earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list/search tool with fully documented parameters, the description is minimally sufficient. However, without annotations or an output schema, it leaves gaps around default pagination behavior, result shape, and when to prefer related tools like glpi_get_problem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter (limit, start, filter) already has a Portuguese description. The tool description only summarizes pagination and RSQL filtering, adding little beyond the schema, so it meets the baseline but does not enrich parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Busca e lista problems', giving a specific verb+resource (search/list problems). It clearly differs from sibling search tools by naming the 'problems' resource and from glpi_get_problem by indicating a list/search operation rather than a single-item get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('search and list problems; supports pagination and RSQL filters') but does not explicitly say when not to use it or name alternatives such as glpi_get_problem for single-record retrieval or glpi_get_problem_stats for statistics. Usage context is clear but no exclusions are stated.
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 that pagination and filtering are supported, which are key behaviors. However, it does not mention whether the operation is read-only, what the response looks like, or any authentication/rate-limit constraints. The word 'search' implies read-only, but this is implicit, not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence. It immediately conveys the action and resource, then adds the pagination/filter capability. There is zero fluff or redundant information (the parenthetical '(Users)' is minor but not harmful).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three optional parameters and no output schema, the description provides the essential context: it searches users, supports pagination, and allows filters. It does not describe return format, but that is largely implied by the tool's purpose. The absence of annotations is partly mitigated by the simple read-only nature implied by the description. Overall, it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – each parameter (limit, start, filter) has a description in the schema. The tool description only adds a high-level note about pagination and filters, which restates the schema fields without adding deeper semantics such as defaults, data types, or filter syntax details beyond the example. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'searches and lists users' (Busca e lista usuários), with a specific verb and resource. This distinguishes it from sibling tools like glpi_search_tickets or glpi_list_computers, which target different entities. The mention of pagination and filters further 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the resource name 'users' – an agent would use this when searching for users, but the description provides no explicit when-to-use vs alternatives, no exclusions, and no reference to sibling tools. It does not say 'for tickets use glpi_search_tickets' or similar, so guidance is only minimal.
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 the burden and does add useful behavioral context: the response includes the full ticket context and timeline in one call. However, it does not disclose output structure, error behavior, permissions, or any other operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core value proposition without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is largely sufficient: it explains the complete context scope and the timeline inclusion. With no output schema, a bit more detail about response fields would be helpful, but the sibling tools and simple nature keep the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter `id` with a description, so the schema covers 100% of parameter semantics. The description does not add additional meaning beyond implying that this ID targets a specific ticket.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete context of one ticket, including timeline, and distinguishes it from the sibling glpi_get_ticket_timeline by avoiding multiple calls. It uses a specific verb and resource ("get ticket") with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "sem precisar de múltiplas chamadas" implies this tool is the preferred single-call option for full ticket context, effectively contrasting with glpi_get_ticket_timeline. However, it does not explicitly state exclusions or when to use the timeline-only sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does add that pagination and filters are supported, and 'lista' implies a read-only listing. However, it does not disclose defaults, return format, or any access-related caveats, leaving some transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It front-loads the purpose and then mentions capabilities, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list/search tool with fully documented parameters and no output schema, the description is adequately complete. It identifies the entity, the operation, and the main capabilities; detailed parameter behavior is handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters (limit, start, filter) are already described in the schema. The description only adds generic mention of pagination and filters, providing no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Busca e lista') and the resource ('grupos (Groups)'), and notes that pagination and filters are supported. No sibling tool covers groups, so this is unambiguous even without an explicit differentiation statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for searching/listing GLPI groups, which is contextually distinct from all sibling tools. It does not explicitly state exclusions or alternatives, but the resource scope is clear enough that no confusion should arise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the underlying filter (is_faq=true) and implies a read-only search, but it doesn't specify return format, pagination behavior, or any other operational traits beyond the schema. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a clear use case. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema and all-optional parameters, the description provides the essential context: what is searched, the filter, and when to use it. It doesn't clarify the return structure, but the close sibling glpi_search_knowbase might cover general KB search; still, this is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no additional parameter-level meaning, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Busca artigos marcados como FAQ na base de conhecimento' and identifies the specific filter is_faq=true, distinguishing it from the broader glpi_search_knowbase sibling tool. The verb 'Busca' and resource 'artigos marcados como FAQ' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use para dúvidas rápidas de uso do GLPI antes de abrir ticket.' It doesn't explicitly name alternatives like glpi_search_knowbase for general knowledge base articles, but the FAQ-specific scope and use case make the intended usage clear.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Luizcc87/glpi-mcp-v2'
If you have feedback or need assistance with the MCP directory API, please join our Discord server