Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/raphael-florestasm/mcp-glpi/objetivogit clone --depth 1 https://github.com/raphael-florestasm/mcp-glpiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/raphael-florestasm/mcp-glpi/objetivo)<a href="https://agentmods.dev/rules/raphael-florestasm/mcp-glpi/objetivo"><img src="https://agentmods.dev/badge/rules/raphael-florestasm/mcp-glpi/objetivo.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.01259 | $0.01259 |
| Opus 5 | $0.00629 | $0.00629 |
| Sonnet 5 | $0.00252 | $0.00252 |
| Haiku 4.5 | $0.00126 | $0.00126 |
Grade A, and why
objetivo scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 243 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Objetivo Desenvolver um servidor MCP (Management Control Protocol) que interaja com a API do GLPI para gerenciar tickets de suporte de forma autônoma, permitindo que um agente de IA tome decisões sobre a abertura, atualização e fechamento de chamados com base em instruções recebidas. Requisitos Técnicos Autenticação
Implementar fluxo de autenticação na API do GLPI com:
URL base da instância GLPI App-Token (para autenticação da aplicação) User-Token (para autorização do usuário) Gerenciamento de session-token (obtido após login bem-sucedido) Configuração da Entidade padrão para operações
Funcionalidades Principais
Gestão de Sessão
Iniciar sessão e obter session-token Renovar session-token quando expirado Encerrar sessão adequadamente
Operações com Tickets
Pesquisa avançada de tickets por:
ID Requerente Título Status Categoria
Leitura completa de tickets (incluindo histórico de interações) Criação de novos tickets Atualização de tickets existentes Adição de acompanhamentos (follow-ups) Adição de soluções Mudança de status Fechamento de tickets
Consultas Especializadas
Listar tickets por status Listar tickets por status e requerente Listar tickets por categoria Obter lista completa de categorias disponíveis
Arquitetura e Organização
Estrutura Modular
Módulo de autenticação Módulo de gerenciamento de tickets Módulo de consultas e relatórios Módulo de tomada de decisão do agente
Interface para o Agente IA
API REST para comunicação entre o agente e o servidor MCP Endpoints específicos para cada operação Documentação clara dos endpoints e parâmetros
Capacidades de Tomada de Decisão do Agente O agente deve ser capaz de:
Analisar Demandas
Compreender a descrição da demanda Identificar a categoria apropriada consultando a lista disponível no GLPI Classificar a prioridade baseada no conteúdo
Determinar Ações
Decidir se deve abrir um novo ticket Decidir se deve atualizar um ticket existente Decidir se deve adicionar uma solução a um ticket Decidir quando um ticket deve ser fechado
Executar Operações no GLPI
Construir requisições adequadas para a API Interpretar respostas da API Verificar sucesso das operações Retornar feedback apropriado
Implementação e Integração com a API do GLPI Endpoints Principais a Implementar
Iniciar Sessão CopiarPOST /apirest.php/initSession Headers:
- App-Token: {app_token}
- Authorization: user_token {user_token}
Listar Tickets CopiarGET /apirest.php/Ticket Headers:
- Session-Token: {session_token}
- App-Token: {app_token} Query Parameters:
- Diversos filtros conforme necessidade
Criar Ticket CopiarPOST /apirest.php/Ticket Headers:
- Session-Token: {session_token}
- App-Token: {app_token} Body:
- JSON com dados do ticket
Atualizar Ticket CopiarPUT /apirest.php/Ticket/{id} Headers:
- Session-Token: {session_token}
- App-Token: {app_token} Body:
- JSON com dados atualizados
Adicionar Follow-up CopiarPOST /apirest.php/Ticket/{id}/ITILFollowup Headers:
- Session-Token: {session_token}
- App-Token: {app_token} Body:
- JSON com dados do follow-up
Adicionar Solução CopiarPOST /apirest.php/Ticket/{id}/ITILSolution Headers:
- Session-Token: {session_token}
- App-Token: {app_token} Body:
- JSON com dados da solução
Consultar Categorias CopiarGET /apirest.php/ITILCategory Headers:
- Session-Token: {session_token}
- App-Token: {app_token}
Encerrar Sessão CopiarPOST /apirest.php/killSession Headers:
- Session-Token: {session_token}
- App-Token: {app_token}
Recursos Adicionais Capacidade de "Thinking" (Raciocínio) Implementar um módulo que permita ao agente:
Analisar o conteúdo da demanda antes de tomar uma decisão Registrar o processo de raciocínio para auditoria Ponderar entre diferentes categorias possíveis Determinar a melhor ação com base em histórico de tickets similares
Capacidade de "Searching" (Pesquisa) Implementar um módulo que permita ao agente:
Buscar tickets relacionados antes de criar um novo Pesquisar na base de conhecimento por soluções conhecidas Consultar histórico de tickets do mesmo requerente Verificar padrões em tickets da mesma categoria
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 243 lines · 1,259 tokens per session scan A d1cace60e015
objetivo is a cursor rule published in the GitHub repository raphael-florestasm/mcp-glpi (5 stars, last pushed 1y ago), licensed Apache-2.0. It adds 1,259 tokens to every session, about $0.0063 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
development-workflow
AAMAD modular development workflow for context-aware agent coordination.
checkpoint
Write a committed handoff checkpoint so a fresh session can resume with zero loss. Use when crossing the 40% context line, on every stage transition, and at session end. Writes .trace/checkpoints/ - .md while the agent is still sharp.
feedback-enhanced
Enhanced feedback mechanism with 1-hour timeout - 增强反馈机制,1小时超时.
project-onboarding-rule
Automatically onboards existing projects into the AI-driven development workflow.
linear-in-review
After finishing a Linear issue, set its status to In Review (never Done).
sprint-planning
BMAD BMM Agent: sprint-planning.