Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ai-agent-logs-mcp list my recent sessions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server so Cursor agents can talk to ai-agent-logs-api (same data shown in ai-agent-logs-webui).
Run the API (local http://127.0.0.1:8120 or published https://ai-agent-log-api.xaigrok.ir).
Node.js 18+.
Related MCP server: Log MCP Server
cd C:\Users\armin\GitHub\ai-agent-logs-mcp
copy .env.example .env
npm install
npm run build~/.cursor/mcp.json)"ai-agent-logs-mcp": {
"command": "node",
"args": ["C:/Users/armin/GitHub/ai-agent-logs-mcp/dist/index.js"],
"env": {
"AI_AGENT_LOGS_API_URL": "https://ai-agent-log-api.xaigrok.ir",
"AI_AGENT_LOGS_USERNAME": "armin",
"AI_AGENT_LOGS_PASSWORD": "dopadopa123"
}
}Restart MCP / reload Cursor after changing mcp.json.
Tool | API |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
log_agent_responseFull turn fields sent to the API: model, rate, date, time, device, user_ip, duration_ms, project, app (default cursor), token_usage, user_prompt, refined_prompt, is_accepted, agent_response, session, title_of_session.
Authenticated tools auto-login with env credentials when no JWT is cached.
Variable | Default |
|
|
|
|
|
|
Create a prompt log row (POST /api/v1/prompts). Auto-logs in if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Agent mode (e.g. agent, ask, plan) | |
| rate | Yes | Integer prompt rate 0–10 | |
| title | Yes | Short title | |
| device | Yes | Device / hostname | |
| prompt | Yes | Full prompt text | |
| project | Yes | Project name | |
| duration_ms | Yes | Duration in milliseconds | |
| occurred_at | No | Optional RFC3339 timestamp; defaults to now on the API |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: 'Auto-logs in if needed.' It does not mention error handling, response behavior, or side effects beyond creation. With no annotations, this is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one short sentence with an optional technical detail (HTTP method). Every word adds value, and there is no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description is mostly complete. It lacks explicit mention of the return value (e.g., the created row) and error conditions, but given the schema's thorough parameter descriptions and the auto-login hint, it is adequate for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameters with descriptions (e.g., mode, rate, duration_ms). The tool description adds no additional parameter-specific meaning, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Create') and resource ('prompt log row'), and includes the HTTP endpoint. It is distinct from sibling tools like list_prompts and list_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description doesn't explicitly state when to use this tool over alternatives. It implies creation vs. listing, but there is no explicit 'use this for' or 'instead of' guidance, and the mention of auto-login is more about behavior than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one session and its prompt turns (GET /api/v1/sessions/:id). Auto-logs in if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Session id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior itself. It adds the notable side effect 'Auto-logs in if needed' and the GET method signals a read operation; however, it does not describe the response shape or error/not-found behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and endpoint, with the auto-login side effect in the second. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, this is largely complete: it states what is returned ('session and its prompt turns') and the auth-related side effect. It does not cover error cases, but the simplicity of the operation makes that a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one required parameter and 100% schema coverage, the schema already explains that id is a session ID. The endpoint notation conveys that id is a path parameter, but no extra format or lookup guidance is given, so the description adds only marginal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: 'Get one session and its prompt turns' and gives the exact endpoint. This clearly differentiates it from list_sessions (one vs. many) and list_prompts (prompts as a list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended trigger is evident: call it when a single session ID is known and its prompt turns are needed. It does not explicitly say 'use list_sessions for all sessions,' so it stops short of naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check ai-agent-logs-api health (GET /health).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP method (GET), implying a read-only, side-effect-free operation. However, it does not mention response format, potential error behavior, or rate limits. For a simple health check this is adequate, but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly-written sentence that conveys the purpose and exact endpoint without any fluff. Every word earns its place, and the description is appropriately front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple: no parameters, no output schema, and no annotations. The description states the action and endpoint, which is largely sufficient for an agent to call it. The only slight gap is that it does not specify the response content (e.g., status body), but for a health check this is a minor omission and the expected behavior is well understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (trivially). Per the rubric, a zero-parameter tool earns a baseline of 4. The description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check ai-agent-logs-api health' and includes the exact HTTP endpoint (GET /health). This clearly distinguishes it from sibling tools like login or list_prompts, which serve entirely different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for verifying service health, which is useful context. However, it does not explicitly state when to use it versus other tools, nor does it mention any prerequisites or exclusions. The usage is implied rather than clearly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored prompts newest first (GET /api/v1/prompts). Auto-logs in if needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It adds one useful trait: 'Auto-logs in if needed,' which reveals authentication handling. However, it does not state that the operation is read-only, mention pagination, or describe any side effects. For a simple read operation this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the auto-login note is secondary. Everything stated earns its place and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists, the description does not mention what the response should look like (e.g., an array of prompts) or any additional behavior such as limits or error responses. The ordering and auto-login are covered, but for a list operation, return structure information would make it more complete. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage). There are no parameter semantics to explain, so the baseline of 4 applies. The description does not need to add parameter information, and nothing is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a clear resource ('stored prompts'), and an ordering criterion ('newest first'). It also includes the exact endpoint, which unambiguously identifies the operation. This distinguishes it from siblings like create_prompt and list_sessions by resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to retrieve prompts), but it does not explicitly mention alternatives or exclusions. There is no guidance like 'for sessions, use list_sessions instead.' The intended usage is inferable from the purpose, but not explicitly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List agent conversation sessions newest first (GET /api/v1/sessions). Auto-logs in if needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It discloses the auto-login side effect, which is useful, but it does not mention pagination, rate limits, or the absence of filtering. For a read-only list tool, this is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences. The primary action (list sessions) is front-loaded, followed by the API path and a note about auto-login. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and the auto-login behavior, but with no output schema and no mention of response format or any query capabilities, an agent might lack enough detail to fully anticipate the result. For a simple list endpoint this is borderline sufficient, but it leaves room for clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description has nothing to add. Per the calibration, a baseline of 4 applies when no parameters exist; the description correctly avoids inventing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'List' plus resource 'agent conversation sessions' and ordering 'newest first' clearly identifies the operation. Naming the exact endpoint (GET /api/v1/sessions) and the auto-login behavior makes it distinguishable from siblings like get_session or list_prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for listing all sessions, but it does not explicitly contrast with get_session (for a single session) or state conditions for when to prefer this over list_prompts. No exclusions or prerequisites are given, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Login to ai-agent-logs-api and cache the JWT. Optional username/password override env defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| password | No | Password (default: AI_AGENT_LOGS_PASSWORD) | |
| username | No | Username (default: AI_AGENT_LOGS_USERNAME or armin) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It explicitly discloses the important side effect of caching the JWT and the env-default behavior, which is key security/state information for an agent. It does not disclose error handling or whether previous tokens are invalidated, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the verb and purpose, then adds the useful qualification about optional overrides. There is no filler, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small, optional-parameter login tool, the description covers the action, credential source, and side effect. The lack of an output schema is mitigated since the JWT is cached, so not much additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the schema already documents both parameters and their defaults. The description's 'optional username/password override env defaults' adds little beyond the schema, so it correctly sits at the baseline without extra parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Login') and resource ('ai-agent-logs-api'), and states the concrete side effect ('cache the JWT'). It is clearly distinguishable from the siblings like health_check or list_sessions, so an agent knows exactly when this tool is the right one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is clear: call this to establish an authenticated session before using sibling tools. The mention of optional username/password overrides tells the agent when the default credentials might be custom, though it does not explicitly state when to skip login or compare against an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_promptget_sessionhealth_checklist_promptslist_sessionsloginScored across 6 tools
Each tool targets a distinct resource and action: health_check for API status, login for authentication, list/create for prompts, and list/get for sessions. No overlap or ambiguity among them.
All tool names follow a predictable lowercase_with_underscores pattern, mostly verb_noun (list_prompts, create_prompt, get_session). The singular 'login' and compound 'health_check' fit naturally without breaking consistency.
With only 6 tools, the set is tightly scoped for the purpose of a logs API. Each tool serves an essential function, and the count is well within the ideal range.
The surface covers core prompt and session operations (list/create for prompts, list/get for sessions) plus health and login. Missing a get_prompt or delete operations, but for a logging server these are often unnecessary, making the gaps minor.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
Manage, version, and publish LLM prompts with blocks, variables, and evaluations.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
