Skip to main content
Glama
Sign In
rails-ai-context

rails-ai-context

by crisnahine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

rails_session_context

Read-only

Track previously queried Rails tools and parameters to avoid redundant calls, review session status or summaries, and reset context during long development sessions.

Instructions

Track what you've already queried to avoid redundant calls. Use action:"status" to see what tools you've called, action:"summary" for a compressed recap, action:"reset" to clear session, or mark:"tool:param" to record a query. Helps maintain focus during long development sessions.

Input Schema

NameRequiredDescriptionDefault
markNoMark a tool+params as already queried (e.g., 'get_schema:users', 'get_model_details:User').
actionNostatus: list queried tools with timestamps. summary: compressed recap. reset: clear session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv5.39.1

TDQS

B3/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, but the description says reset clears the session and mark records a query, both of which are state mutations. This directly contradicts the read-only annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence front-loads the purpose and action list. The final clause about maintaining focus is mild filler, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter session utility with full schema coverage, the description covers actions and mark format adequately. It omits return behavior for status/summary, and the read-only contradiction leaves behavioral expectations unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents both parameters and the action enum. The description restates action meanings and mark format, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States that the tool tracks already-queried tools to avoid redundant calls and enumerates its actions. It is clearly a session-tracking meta-utility, though it does not explicitly contrast itself with sibling retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains what each action and the mark parameter do, and implies use during long development sessions. However, it gives no explicit when-not guidance or alternatives for choosing this over sibling query tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools