rails-ai-context
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rails_analyze_featureA | Full-stack feature analysis: models, controllers, routes, services, jobs, views, Stimulus controllers, tests, related models, callbacks, concerns, and environment dependencies. Use when: exploring an unfamiliar feature, onboarding to a codebase area, or tracing a feature across layers. Pass feature:"authentication" or feature:"User" for broad cross-cutting discovery. |
| rails_dependency_graphA | Generates a dependency graph showing how models connect through their associations. Output as Mermaid diagram syntax or plain text. Use when: understanding feature architecture, tracing data flow, planning refactors. Key params: model (center graph on model), depth (1-3), format (mermaid/text). |
| rails_diagnoseA | One-call error diagnosis: parses the error, classifies it, gathers controller/model/schema context, shows recent git changes, pulls relevant logs, and suggests a fix. Use when: you hit an error and need to understand why. Key params: error (required - paste the error message), file, line, action (controller#action). |
| rails_generate_testA | Generate test scaffolding that matches your project's actual test patterns - framework, factories, assertion style. Use when: adding tests for a model, controller, or service. Generates copy-paste-ready test files. Key params: model (e.g. 'User'), controller (e.g. 'PostsController'), file (e.g. 'app/services/foo.rb'). |
| rails_get_callbacksA | Get ActiveRecord model callbacks grouped by type, in Rails event order: before/after/around for validation, save, create, update, destroy. Use when: understanding side effects, debugging callback chains, or checking what happens on save/create/destroy. Specify model:"User" for one model's callbacks. detail:"full" includes callback method source code. The list is what the model, its base classes and its concerns declare, and within one type the order is the order Rails runs them, a before_ or around_ callback with prepend: true first, and after_commit in the order the app's setting gives. |
| rails_get_component_catalogA | Returns ViewComponent and Phlex component catalog: props, slots, previews, which views render each component. Use when: building views with components, understanding component API, finding reusable components. Key params: component (filter by name), detail level. |
| rails_get_concernA | Get ActiveSupport::Concern details: public methods, included modules, and which models/controllers include it. Use when: understanding shared behavior, checking concern interfaces, or finding where a concern is used. Specify name:"Searchable" for full detail, or omit for a list of all concerns. Filter with type:"model" or type:"controller". |
| rails_get_configA | Get the app's configuration, one section per call. section: app (default: database, auth, assets, cache, session, queue, Action Cable, middleware, initializers), gems (notable gems by category), frontend (JS framework, build tool, TypeScript, package manager), api (serializers, GraphQL, versioning, CORS, rate limiting, pagination), engines (mounted engines and Rack apps), conventions (architecture and patterns), autoload (Zeitwerk paths, inflections), active_support (concerns, notifications, on_load hooks), env (names of environment variables and credentials keys), env_config (config/environments/*.rb per environment), i18n (locales, locale files, coverage). |
| rails_get_contextA | Get cross-layer context in a single call - combines schema, model, controller, routes, views, stimulus, and tests. Use when: you need full context for implementing a feature or modifying an action. Specify controller:"PostsController" action:"create" to get everything for that action in one call. |
| rails_get_controllersA | Get controller details: actions, before_action filters, strong params, and parent class. Use when: adding/modifying controller actions, checking what filters apply, or reading action source code. Filter with controller:"PostsController", drill into action:"create" for source code with line numbers. |
| rails_get_edit_contextA | Get targeted code context for surgical edits: returns matching lines with surrounding code and line numbers. Use when: you need to edit a specific method or section without reading the entire file. Requires file:"app/models/user.rb" and near:"def activate" (or line:42) to locate the code region. |
| rails_get_helper_methodsA | Get Rails helper modules: method signatures, the view helpers controllers declare with helper_method, framework helpers in use, and which views call each helper. Use when: finding available view helpers, checking what helper methods exist, or understanding shared view logic. Specify helper:"ApplicationHelper" for full detail, or omit to list all helpers with method counts. |
| rails_get_job_patternA | Analyze background jobs in app/jobs/, app/workers/ and app/sidekiq/: queues, retries, perform signatures, guards, and what they call. Use when: understanding job infrastructure, adding a new job, or tracing async workflows. Specify job:"SendWelcomeEmail" for full detail, or omit to list all jobs with queue names and retry config. |
| rails_get_mailersA | Get ActionMailer mailers: every mailer class with its delivery actions, delivery method, own defaults, layout and callbacks, template formats per action and preview class, the queue deliver_later uses, interceptors and observers, and the Action Mailbox mailboxes with the routing that sends inbound mail to each. Use when: adding an email, checking which mailer sends what, or finding the action to preview/test. Filter with mailer:"UserMailer". Omit for all mailers. |
| rails_get_model_detailsA | Get ActiveRecord model details: associations, validations, scopes, enums, callbacks, concerns. Use when: understanding model relationships, adding validations, checking existing scopes/callbacks. Specify model:"User" for full detail, or omit for a list. detail:"full" shows association lists. |
| rails_get_partial_interfaceA | Analyze a partial's interface: local variables it expects, where it's rendered from, and what methods are called on each local. Use when: rendering a partial, understanding what locals to pass, or refactoring partial dependencies. Specify partial:"shared/status_badge" to see its full interface. Supports both underscore-prefixed and non-prefixed names. |
| rails_get_routesA | Get routing table: HTTP verbs, paths, controller#action, route names. Use when: building links/redirects, checking available endpoints, verifying route helpers exist. Filter with controller:"users", use detail:"summary" for counts or detail:"full" for route names. |
| rails_get_schemaA | Get database schema: tables, columns, types, indexes, foreign keys. Use when: writing migrations, checking column types/constraints, understanding table relationships. Filter to one table with table:"users", control detail with detail:"summary"|"standard"|"full". |
| rails_get_service_patternA | Analyze service objects in app/services/, app/interactions/ and app/interactors/: patterns, interfaces, dependencies, and side effects. Use when: understanding how services are structured, adding a new service, or tracing what a service does. Specify service:"CreateOrder" for full detail, or omit to detect the common pattern and list all services. |
| rails_get_stimulusA | Get Stimulus controllers: targets, values, actions, outlets, classes. Use when: wiring up data-controller attributes in views, adding targets/values, or checking existing Stimulus behavior. Filter with controller:"filter-form" for one controller's full API, or list all with detail:"summary". |
| rails_get_test_infoA | Get test infrastructure and existing test files: framework, factories, fixtures, CI config, coverage setup. Use when: writing new tests, checking what factories/fixtures exist, or finding the test file for a model/controller. Use model:"User" or controller:"Posts" to see existing tests. detail:"full" lists factory and fixture names. |
| rails_get_turbo_mapA | Map Turbo Streams and Frames across the app: model broadcasts, channel subscriptions, frame tags, and DOM target mismatches. Use when: debugging Turbo Stream delivery, adding real-time updates, or understanding broadcast→subscription wiring. Filter with stream:"notifications" for a specific stream, or controller:"messages" for one controller's Turbo usage. |
| rails_get_viewA | Get view templates, partials, and their Stimulus/partial references. Use when: editing ERB views, checking which partials a page renders, or finding Stimulus controller usage. Filter with controller:"posts" for all views, or path:"posts/index.html.erb" for one file's content. |
| rails_migration_advisorA | Generates migration code for schema changes. Given an action (add_column, remove_column, rename_column, add_index, add_association, change_type), generates the migration, flags irreversible operations, and shows affected models. Use when: adding fields, changing schema, planning database changes. Key params: action, table, column, type, new_name (for rename_column). |
| rails_onboardA | Get a narrative walkthrough of the Rails application - stack, data model, authentication, key flows, background jobs, frontend, testing, getting started instructions, and the app's custom rake tasks, generators and Railties. Use when: first encountering a project, onboarding a new developer, or orienting an AI agent. Key params: detail (summary/standard/full). |
| rails_performance_checkA | Static analysis for Rails performance anti-patterns: N+1 query risks, missing counter_cache, Model.all in controllers, missing foreign key indexes, eager loading candidates. Use when: reviewing code for performance, before deploying, or investigating slow pages. Key params: model (filter by model), category (filter by issue type), detail level. |
| rails_queryA | Execute read-only SQL queries against the database. Use when: checking data patterns, verifying migrations, debugging data issues. Safety: SQL validation + database-level READ ONLY + statement timeout + row limit. Development/test only by default. Key params: sql (SELECT only), limit (default 100), format (table/csv). |
| rails_read_logsA | Read recent log entries with level filtering and sensitive data redaction. Use when: debugging errors, checking recent activity, investigating failed requests. Key params: lines (default 50), level (ERROR/WARN/INFO/DEBUG/FATAL/all), file, search. Search matches the redacted line, so a filtered value cannot be searched for. |
| rails_review_changesA | PR/commit review context: shows changed files with relevant schema/model/route context per file, detects warnings (missing indexes, removed validations, changed associations, new routes without tests). Use when: reviewing changes before merging, understanding what a commit changed and its impact. Key params: ref (default 'HEAD' for uncommitted, or 'main', 'HEAD~3', commit SHA). |
| rails_runtime_infoA | Live runtime state: database connection pool, table sizes, pending migrations, cache stats, job queues. Use when: debugging performance, checking database health, verifying deployment state, or understanding infrastructure. Key params: detail (summary/standard/full), section (database/cache/jobs/connections). |
| rails_search_codeA | Search the Rails codebase with smart modes. Use match_type:"trace" to see where a method is defined, who calls it, and what it calls - in one call. Use match_type:"definition" for definitions only, "call" for call sites only, "class" for class/module definitions. Requires pattern:"method_name". Narrow with path:"app/models" and file_type:"rb". |
| rails_search_docsA | Search a bundled index of the Rails guides and the Turbo, Stimulus and Hotwire Native handbooks. Use when: you need to reference Rails conventions, API details, or best practices. Pass query:"active record callbacks" to find matching topics. Filter with source:"guides", "turbo", "stimulus" or "hotwire". Set fetch:true to retrieve full content from GitHub (cached 24h). |
| rails_security_scanA | Run Brakeman static security analysis on Rails app. Use when: after editing controllers/models/views, reviewing code for vulnerabilities, or before deploying. Filter with files:["app/controllers/users_controller.rb"], set confidence:"high" to reduce noise. |
| rails_session_contextB | 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. |
| rails_validateA | Validate syntax and semantics of Ruby, ERB, and JavaScript files in a single call. Use when: after editing files, before committing, to catch syntax errors and Rails-specific issues. Pass files:["app/models/user.rb"], use level:"rails" for semantic checks (missing partials, route helpers, column refs in validates/permit/callbacks). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Database Schema | Full database schema including tables, columns, indexes, and foreign keys |
| Application Routes | All routes with HTTP verbs, paths, and controller actions |
| Conventions & Patterns | Detected architecture patterns, conventions, and directory structure |
| Notable Gems | Gem dependencies categorized by function with explanations |
| Controllers | All controllers with actions, filters, strong params, and concerns |
| Application Config | Application configuration including cache, sessions, middleware, and initializers |
| Test Infrastructure | Test framework, factories, fixtures, CI, and coverage configuration |
| Migrations | Migration history, pending migrations, and migration statistics |
| Mounted Apps | Mounted Rails engines and Rack apps with paths and descriptions |
TDQS
Scored across 35 tools
Most tools map to a distinct Rails artifact (schema, routes, callbacks, mailers, jobs, stimulus, turbo), but several boundaries blur: rails_analyze_feature and rails_get_context both promise 'full-stack context in one call' across the same layers, and rails_get_context vs rails_get_edit_context differ only by a word while doing very different things. rails_onboard also overlaps with rails_get_config, and rails_get_model_details subsumes rails_get_callbacks. Descriptions are detailed enough that an agent can usually recover, but misselection is a real risk.
All names use a uniform rails_ prefix and snake_case verb_noun form, which is highly readable. The only inconsistency is the verb layer: a large get_* family coexists with bare verbs (analyze_feature, search_code, review_changes, query, validate, onboard), so the 'get' prefix is applied unevenly. Predictable overall, minor deviation.
35 tools is heavy, sitting above the comfortable 3-15 band, and a few are redundant (analyze_feature vs get_context, session_context as a meta-bookkeeping utility). However, the server targets an entire Rails application surface, so most tools do correspond to a genuine distinct artifact type. Borderline over-scoped rather than gratuitous.
Coverage is unusually broad: schema, models, controllers, routes, views, partials, helpers, services, jobs, mailers, Stimulus, Turbo, components, tests, migrations, config, logs, security and performance, plus read-only SQL and docs search. Minor gaps remain around authorization policies (Pundit/CanCan), ActiveStorage/ActionText attachments, and API/GraphQL schema introspection. No dead ends for the core read-and-understand workflow.