F
licenseNot graded
qualityD
maintenanceAn MCP server that transforms codebases into intelligent, queryable knowledge bases, enabling AI assistants to perform semantic search, explore architecture, and analyze code relationships.
166
rails-lens
by ei-nakamura
Provides deep introspection of Ruby on Rails applications, exposing callbacks, associations, validations, concerns, routes, schema, dependency graphs, method resolution, gem injections, and impact analysis for AI coding tools.
Click on "Install 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., "@rails-lensIntrospect the User model"
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.
rails-lens
MCP server that reveals implicit Rails dependencies for AI coding tools.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DEAR RAILS DEVELOPERS,
All your hidden callbacks are belong to us.
All your implicit concerns are belong to us.
All your monkey-patched methods are belong to us.
You have no chance to survive make your code.
— rails-lens
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Overview
rails-lens is an MCP (Model Context Protocol) server that extracts and exposes Ruby on Rails application structure to AI coding tools like Claude Code and Cursor. It helps AI tools understand Rails implicit dependencies such as callbacks, associations, concerns, and dynamic method generation.
19 tools are provided to give AI assistants deep insight into Rails applications:
Phase 1–4 (Core Introspection)
Introspect models with callbacks, associations, validations
Find all references to a method or class across the codebase
Trace full callback chains including inherited and concern-injected hooks
Generate dependency graphs between models
Dump database schema and routes
Analyze shared concerns
Manage the introspection cache
Phase 5–8 (Advanced Analysis)
Explain method resolution order (MRO) and ancestor chains
Introspect Gem-injected methods and callbacks
Analyze the impact of changing a column or method
Map models and methods to their test files
Detect dead code (unused methods, callbacks, scopes)
Detect circular dependencies between models
Identify Concern extraction candidates from Fat Models
Trace data flow from HTTP request to database
Provide migration context and safety warnings
Phase 9–10 (Screen Mapping)
Map screens to source files (templates, partials, helpers, models)
Reverse-map source files to affected screens with impact analysis
Auto-generate a full screen inventory (Markdown/JSON)
Related MCP server: codeweave-mcp
Requirements
Required:
Python >= 3.11
Optional (for full functionality):
Ruby + Bundler — enables Rails runner for live introspection (e.g., accurate association traversal, runtime method resolution)
ripgrep (
rg) — used by search-based tools (find_references, etc.)
Without Ruby:
rails-lens works with file-based analysis fallback. Most tools return useful
results by parsing Ruby files directly. Results include
_metadata.source: "file_analysis" to indicate fallback mode.
Some tools return limited data compared to Rails runner mode.
Feature | With Ruby | Without Ruby |
Model listing | Live ActiveRecord scan | File glob + regex |
Schema info | DB introspection | db/schema.rb parse |
Associations | Runtime evaluation | Regex extraction |
Method resolution | Full ancestor chain | include/extend/prepend inference |
Gem introspection | Runtime method injection | Gemfile/Gemfile.lock parse only |
Installation
pip install rails-lensTools
Phase 1–4: Core Introspection
rails_lens_introspect_model
Introspects a single Rails model and returns its callbacks, associations, validations, scopes, and class methods.
Use case: Understand a model's full behavior before modifying it.
Parameters:
model_name(string, required): Rails model class name (e.g."User","Order")include_inherited(boolean, optional): Include inherited callbacks. Default:true
Example output:
Model: User
Callbacks:
before_save: :downcase_email, :strip_whitespace
after_create: :send_welcome_email
Associations:
has_many: :orders, :posts
belongs_to: :organization
Validations:
validates :email, presence: true, uniqueness: truerails_lens_list_models
Lists all ActiveRecord model classes found in the Rails application.
Use case: Get an overview of the data model before exploring specific models.
Parameters: none
Example output:
Models (12):
User, Order, Product, Category, Tag, Comment,
Organization, Role, Permission, Session, AuditLog, Settingrails_lens_find_references
Searches the codebase for all references to a given method or class name using fast text search.
Use case: Find everywhere a method is called before renaming or removing it.
Parameters:
name(string, required): Method or class name to search forfile_pattern(string, optional): Glob pattern to restrict search (e.g."app/**/*.rb")
Example output:
References to "send_welcome_email" (3 found):
app/models/user.rb:42 after_create :send_welcome_email
app/mailers/user_mailer.rb:8 def send_welcome_email(user)
spec/models/user_spec.rb:15 expect(user).to receive(:send_welcome_email)rails_lens_trace_callback_chain
Traces the full callback chain for a model event, including hooks from concerns and parent classes.
Use case: Debug unexpected behavior triggered by callbacks before modifying a model event.
Parameters:
model_name(string, required): Rails model class nameevent(string, required): Callback event (e.g."before_save","after_create")
Example output (Mermaid diagram):
graph TD
A[before_save] --> B[:downcase_email]
A --> C[:strip_whitespace]
B --> D[defined in Concerns::Normalizable]
C --> E[defined in User]rails_lens_dependency_graph
Generates a dependency graph showing associations between models.
Use case: Understand cross-model dependencies before a refactoring or data migration.
Parameters:
root_model(string, optional): Starting model for the graph. If omitted, graphs all models.depth(integer, optional): Maximum traversal depth. Default:2
Example output (Mermaid diagram):
graph TD
User -->|has_many| Order
User -->|has_many| Post
Order -->|belongs_to| User
Order -->|has_many| LineItem
LineItem -->|belongs_to| Productrails_lens_get_schema
Dumps the current database schema (from db/schema.rb) in a structured format.
Use case: Inspect column types and constraints before writing a migration.
Parameters:
table_name(string, optional): Filter to a specific table. If omitted, returns all tables.
Example output:
Table: users
id: bigint, primary key
email: string, not null, unique
created_at: datetime, not null
updated_at: datetime, not nullrails_lens_get_routes
Returns all defined Rails routes from config/routes.rb or rails routes output.
Use case: Verify available routes and their controller mappings.
Parameters:
filter(string, optional): Filter routes by path or controller name
Example output:
GET /users users#index
POST /users users#create
GET /users/:id users#show
PATCH /users/:id users#update
DELETE /users/:id users#destroyrails_lens_analyze_concern
Analyzes a Rails concern module and lists the methods, callbacks, and validations it injects.
Use case: Understand what a concern adds to a model before including or removing it.
Parameters:
concern_name(string, required): Concern module name (e.g."Normalizable","Auditable")
Example output:
Concern: Concerns::Auditable
Injects callbacks:
before_create: :set_creator
before_update: :set_updater
Injects methods:
:created_by_name, :updated_by_name
Injects validations:
validates :creator, presence: truerails_lens_refresh_cache
Clears and rebuilds the introspection cache by re-running Rails scripts.
Use case: Refresh stale cache after adding new models or modifying existing ones.
Parameters:
model_name(string, optional): Refresh cache for a specific model only. If omitted, refreshes all.
Example output:
Cache refreshed for: User, Order, Product (3 models)
Duration: 4.2sPhase 5: Method Resolution & Gem Introspection
rails_lens_explain_method_resolution
Returns the method resolution order (MRO), ancestor chain, and method owner for a Rails model.
Use case: Understand where a method is defined when multiple modules and concerns are included.
Parameters:
model_name(string, required): Rails model class namemethod_name(string, optional): Specific method to locate. If omitted, returns the full ancestor chain.show_internal(boolean, optional): Include Ruby/Rails internal modules. Default:false
Example output:
{
"model_name": "User",
"method_owner": "Concerns::Normalizable",
"ancestors": ["User", "Concerns::Auditable", "Concerns::Normalizable", "ApplicationRecord"],
"super_chain": ["Concerns::Normalizable#downcase_email"],
"monkey_patches": []
}rails_lens_gem_introspect
Returns methods, callbacks, and routes injected by Gems into a Rails model.
Use case: Discover what Devise, Paranoia, PaperTrail, or other gems add to a model.
Parameters:
model_name(string, required): Rails model class namegem_name(string, optional): Filter results to a specific gem. If omitted, returns all gems.
Example output:
{
"model_name": "User",
"gem_methods": [
{"gem_name": "devise", "method_name": "authenticate", "source_file": null}
],
"gem_callbacks": [
{"gem_name": "paper_trail", "kind": "after_update", "event": "after_update", "method_name": "record_update"}
],
"gem_routes": []
}Phase 6: Change Safety
rails_lens_analyze_impact
Analyzes the impact of modifying or removing a column or method — including callbacks, validations, views, mailers, and cascade effects.
Use case: Assess risk before renaming a column or changing a method signature.
Parameters:
model_name(string, required): Rails model class nametarget(string, required): Column or method name to analyzechange_type(string, optional):remove,rename,type_change, ormodify. Default:modify
Example output (Mermaid diagram):
graph LR
TARGET["User.email"]
I0["VL: validates :email, presence: true"]
I1["CB: before_save :downcase_email"]
I2["VW: app/views/users/show.html.erb"]
style I0 fill:#fa4
style I1 fill:#fa4
style I2 fill:#8f8
TARGET --> I0
TARGET --> I1
TARGET --> I2rails_lens_test_mapping
Detects test files related to a model or method and returns the run command.
Use case: Find which specs to run after modifying a model or method.
Parameters:
target(string, required): Model name (e.g."User") or method spec (e.g."User#activate")include_indirect(boolean, optional): Include indirectly related specs (shared examples, feature specs). Default:true
Example output:
{
"target": "User#activate",
"test_framework": "rspec",
"direct_tests": [
{"file": "spec/models/user_spec.rb", "type": "unit", "relevance": "direct"}
],
"indirect_tests": [
{"file": "spec/features/user_registration_spec.rb", "type": "feature", "relevance": "indirect"}
],
"run_command": "bundle exec rspec spec/models/user_spec.rb spec/features/user_registration_spec.rb"
}Phase 7: Refactoring
rails_lens_dead_code
Detects unused methods, callbacks, and scopes with confidence ratings.
Use case: Find safe candidates for removal during a cleanup or refactoring session.
Parameters:
scope(string, optional): Detection scope:models,controllers, orall. Default:modelsmodel_name(string, optional): Limit detection to a specific model.confidence(string, optional):high(certainly unused) ormedium(possibly dynamic). Default:high
Example output:
{
"scope": "models",
"total_methods_analyzed": 42,
"total_dead_code_found": 3,
"items": [
{
"type": "method", "name": "legacy_export", "file": "app/models/user.rb",
"line": 87, "confidence": "high", "reason": "No references found",
"reference_count": 0, "dynamic_call_risk": false
}
]
}rails_lens_circular_dependencies
Detects circular dependencies between models (mutual callback updates, bidirectional associations) and visualizes them as a Mermaid diagram.
Use case: Identify models that mutually trigger each other's callbacks, causing stack overflows or data corruption.
Parameters:
entry_point(string, optional): Filter to cycles containing this model.format(string, optional):mermaidorjson. Default:mermaid
Example output (Mermaid diagram):
graph LR
Order["Order"]
Invoice["Invoice"]
Order -->|"after_save → update_invoice"| Invoice
Invoice -->|"after_save → update_order"| Order
style Order fill:#f88
style Invoice fill:#f88rails_lens_extract_concern_candidate
Analyzes a Fat Model's methods by cohesion and suggests Concern extraction candidates with rationale.
Use case: Identify groups of related methods in a large model that should be extracted into concerns.
Parameters:
model_name(string, required): Rails model class namemin_cluster_size(integer, optional): Minimum number of methods per cluster. Default:3
Example output:
{
"model_name": "User",
"total_methods": 45,
"candidates": [
{
"suggested_name": "Notifiable",
"methods": ["send_welcome_email", "send_reset_password", "notify_admin"],
"cohesion_score": 0.87,
"rationale": "All methods relate to email/notification dispatch"
}
]
}Phase 8: Data Flow & Migration
rails_lens_data_flow
Traces data flow from an HTTP request through routing, strong parameters, callbacks, and into the database.
Use case: Understand the full lifecycle of a user-submitted attribute before modifying it.
Parameters:
controller_action(string, optional): Controller#action (e.g."UsersController#create")model_name(string, optional): Model name as an alternative entry pointattribute(string, optional): Specific attribute to trace. If omitted, traces all.
Example output (Mermaid sequence diagram):
sequenceDiagram
participant Client
participant Router
participant Controller as UsersController
participant Params as StrongParameters
participant Model
participant DB
Client->>Router: POST /users
Router->>Controller: #create
Controller->>Params: permit(:name, :email, :password)
Params->>Model: User.new(params)
Model->>Model: before_save :downcase_email
Model->>DB: INSERT INTO usersrails_lens_migration_context
Provides migration context for a table: current schema, migration history, safety warnings, and a migration template.
Use case: Get all relevant context and safety checks before writing a migration for a large table.
Parameters:
table_name(string, required): Table name (e.g."users")operation(string, optional): Planned operation:add_column,remove_column,add_index,change_column,add_reference, orgeneral. Default:general
Example output:
{
"table_name": "users",
"operation": "add_column",
"estimated_row_count": 2500000,
"warnings": [
{
"type": "large_table",
"message": "Table has ~2.5M rows. Adding a non-null column without a default will lock the table.",
"suggestion": "Use `add_column` with a default, then backfill and add NOT NULL constraint separately."
}
],
"template": {
"description": "Add column with default for large table",
"code": "add_column :users, :new_column, :string, default: nil\n# backfill...\nchange_column_null :users, :new_column, false"
}
}Phase 9–10: Screen Mapping
rails_lens_screen_map
Maps between screens (URLs/controller actions) and source files bidirectionally, and generates a full screen inventory. Supports three modes.
Mode: screen_to_source
Given a URL or controller#action, returns all related source files including templates, partials, helpers, models, decorators, assets, and i18n keys.
Use case: Understand all the files involved in rendering a specific screen before modifying it.
Parameters:
mode(string, required):"screen_to_source"url(string, optional): URL path (e.g."/users/123")controller_action(string, optional): Controller#action (e.g."UsersController#show")locale(string, optional): Language for screen name inference. Default:"ja"
Example output:
{
"screen": {
"url_pattern": "/users/:id",
"http_method": "GET",
"controller_action": "UsersController#show",
"screen_name": "User Detail",
"screen_name_source": "restful_convention"
},
"layout": {
"file": "app/views/layouts/application.html.erb",
"content_for_blocks": ["sidebar", "header"]
},
"template": {
"file": "app/views/users/show.html.erb"
},
"partials": [
{
"name": "users/header",
"file": "app/views/users/_header.html.erb",
"called_from": "app/views/users/show.html.erb",
"locals_passed": ["user"]
}
],
"helpers": [
{"method": "format_date", "file": "app/helpers/application_helper.rb", "line": 12}
],
"models": [
{"model": "User", "attributes_accessed": ["name", "email"]}
]
}Mode: source_to_screens
Given a source file path, returns all screens that use it and the impact level of changes.
Use case: Before modifying a partial or helper, understand which screens will be affected.
Parameters:
mode(string, required):"source_to_screens"file_path(string, required): Path to the source file (e.g."app/views/shared/_navigation.html.erb")method_name(string, optional): Helper method name to narrow the analysis
Example output:
{
"source_file": "app/views/shared/_navigation.html.erb",
"source_type": "partial",
"affected_screens": [
{
"controller_action": "UsersController#index",
"screen_name": "User List",
"url_pattern": "/users",
"impact_level": "high"
},
{
"controller_action": "OrdersController#show",
"screen_name": "Order Detail",
"url_pattern": "/orders/:id",
"impact_level": "high"
}
]
}Mode: full_inventory
Auto-generates a complete screen inventory covering all web screens and API endpoints.
Use case: Create a screen inventory document for the project, or get an overview of all screens at a glance.
Parameters:
mode(string, required):"full_inventory"format(string, optional): Output format:"json"or"markdown". Default:"json"include_api(boolean, optional): Include API endpoints. Default:truegroup_by(string, optional): Grouping:"namespace","resource", or"flat". Default:"namespace"locale(string, optional): Language for screen name inference. Default:"ja"
Example output (markdown):
# Screen Inventory
> Auto-generated by rails-lens
## Summary
- Total screens: 24
- Web screens: 18
- API endpoints: 6
## Web Screens
| Screen Name | URL | Controller#Action | Partials | Models |
|-------------|-----|-------------------|----------|--------|
| User List | GET /users | UsersController#index | 3 | User |
| User Detail | GET /users/:id | UsersController#show | 5 | User |Web Dashboard
rails-lens includes a built-in web dashboard to visualize your Rails project structure in the browser.
Installation
pip install rails-lens[web]Usage
uvicorn rails_lens.web.app:app --host 0.0.0.0 --port 8000Or using Python module:
python -m rails_lens.webPages
Core (6 pages)
Page | URL | Description |
Dashboard TOP |
| Project overview, model count, cache status |
Models List |
| All models with column/association counts |
Model Detail |
| Schema, callbacks, Mermaid callback chain |
ER Diagram |
| Entity-Relationship diagram (Mermaid erDiagram) |
Dependency Graph |
| Model dependency graph (Mermaid graph LR) |
Cache Management |
| Cache status, invalidation controls |
Extended (5 pages)
Page | URL | Description |
Project Health |
| Circular dependencies + dead code overview |
Request Flow |
| HTTP request → DB flow (Mermaid sequenceDiagram) |
Impact Analysis |
| Change impact visualization |
Refactoring Support |
| Concern extraction candidates |
Gem Info |
| Installed gems and their Rails integrations |
Tech Stack
FastAPI + Jinja2 + PicoCSS + Mermaid.js
All diagrams are rendered in the browser via Mermaid.js — no server-side image generation needed.
Configuration
RAILS_LENS_PROJECT_PATH
The absolute path to the root directory of the Rails application you want to analyze (the directory containing Gemfile, app/, config/, db/, etc.).
This can be configured in the following ways (listed in order of priority):
Environment variable
RAILS_LENS_PROJECT_PATH— Required when running as an MCP server (Claude Code / Cursor), since the server process does not run from the Rails project directory.rails.project_pathin.rails-lens.toml— Explicit path setting in the config file..rails-lens.tomllocation — If.rails-lens.tomlis placed in the Rails project root, the project path is automatically inferred from the file's parent directory. No explicitproject_pathsetting is needed.
Claude Code (~/.claude/claude_desktop_config.json)
{
"mcpServers": {
"rails-lens": {
"command": "rails-lens",
"env": {
"RAILS_LENS_PROJECT_PATH": "/path/to/your/rails/project"
}
}
}
}Cursor (.cursor/mcp.json)
{
"mcpServers": {
"rails-lens": {
"command": "rails-lens",
"env": {
"RAILS_LENS_PROJECT_PATH": "/path/to/your/rails/project"
}
}
}
}.rails-lens.toml (optional, in your Rails project root)
When placed in the Rails project root, project_path can be omitted — it is automatically resolved from the file's location.
[rails]
# project_path is inferred from this file's location
timeout = 30
[cache]
auto_invalidate = true
[search]
command = "rg"Developer Setup
git clone https://github.com/ei-nakamura/rails-lens.git
cd rails-lens
pip install -e ".[dev]"
pytest tests/Run with coverage:
pytest tests/ --cov=src/rails_lens --cov-report=term-missingSee CONTRIBUTING.md for contribution guidelines.
License
MIT
Available Tools
19 toolsrails_lens_analyze_concernBRead-onlyIdempotent
Rails ConcernのInclude関係・メソッドを分析
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| concern_name | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that the tool analyzes concern internals, which is consistent but does not provide additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description fails to explain the sole input parameter. For a tool with many siblings, more context about the analysis scope and output would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'concern_name' parameter. It does not add format, constraints, or examples, leaving the agent with no guidance beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: it states the tool analyzes Rails Concerns, focusing on include relationships and methods. It clearly distinguishes from sibling tools like 'analyze_impact' or 'data_flow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. The single sentence does not provide context about when not to use it or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_analyze_impactARead-onlyIdempotent
カラムやメソッドを変更した場合の影響範囲（コールバック・バリデーション・ビュー・メーラー等）を分析する
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the type of analysis (impact across multiple areas). It does not contradict annotations and provides behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Japanese that conveys the core purpose efficiently. Every word is necessary, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations cover safety and idempotency, parameters are well-documented in schema, and an output schema exists (not shown), the description sufficiently adds the analysis scope. It is complete for a non-destructive analysis tool.
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?
The input schema includes descriptions for all three parameters (target, model_name, change_type). The tool description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes impact range when changing columns or methods, and explicitly lists covered aspects (callbacks, validations, views, mailers). This distinguishes it from sibling tools like find_references or trace_callback_chain, which have narrower scopes.
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?
The description implies usage when planning a column/method change, but does not explicitly state when to use this tool vs alternatives (e.g., find_references for simple references). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_circular_dependenciesBRead-onlyIdempotent
モデル間の循環依存（コールバック相互更新・双方向association）を検出し、Mermaid図で可視化する
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, non-destructive hints. The description adds that it detects callback mutual updates and bidirectional associations, which is helpful for understanding scope. No contradictions with annotations.
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 description is a single sentence that effectively summarizes the tool's purpose. It is front-loaded with the main action. However, it lacks additional structure or context that would further improve clarity.
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?
While the tool has an output schema, the description only mentions Mermaid visualization, omitting that JSON output is also available. For a circular dependency detector, this is a notable gap. The description is adequate but not fully complete.
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?
The tool description does not describe any parameters, but the input schema provides full descriptions for both 'format' and 'entry_point' with defaults and optionality. Since schema coverage is high, baseline of 3 is appropriate.
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?
The description clearly states the tool detects circular dependencies between models and visualizes them with Mermaid diagrams, distinguishing it from related siblings like dependency_graph or dead_code. However, it only covers visualization in Mermaid, missing the JSON output option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as dependency_graph or trace_callback_chain. No mention of prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_data_flowBRead-onlyIdempotent
HTTPリクエストからDB保存までのデータフローを可視化する
ルーティング→Strong Parameters→コールバックの順で解析する。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the analysis order but does not elaborate on return values, side effects, or other behaviors beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly define purpose and analysis order with no redundancy. Front-loaded with the main purpose.
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?
Given the tool's complexity and presence of an output schema, the description provides minimal context beyond purpose. Parameter usage and output format are not described, but the schema covers parameters adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The input schema includes descriptions for each property, so the description adds no value for parameter understanding.
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?
The description clearly states the tool visualizes data flow from HTTP request to DB storage, specifying the analysis order. It distinguishes the tool from siblings by its broad scope, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the analysis order but provides no guidance on when to use this tool versus sibling tools like 'rails_lens_trace_callback_chain' or alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_dead_codeARead-onlyIdempotent
未使用のメソッド・コールバック・スコープを検出し、削除の安全性を confidence 付きで報告する
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that results include deletion safety with confidence, going beyond the structured metadata to explain behavioral output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence in Japanese efficiently conveys the tool's purpose without extraneous words. Front-loaded with key action verbs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality and output meaning, but could mention that output schema provides structured results. Given output schema exists, description is sufficiently complete for a detection tool.
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?
Main description has 0% parameter coverage, but input schema provides clear descriptions for scope, confidence, and model_name. Description does not add further meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool detects unused methods, callbacks, and scopes, with confidence reporting. This specific verb-resource structure distinguishes it from sibling tools like data flow or dependency analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like rails_lens_find_references or rails_lens_trace_callback_chain. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_dependency_graphCRead-onlyIdempotent
依存関係グラフ生成
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the tool is read-only, idempotent, and non-destructive. The description adds no further behavioral context, but it does imply a read operation via 'generation'. Given high annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (a single phrase), but it is under-specified, lacking necessary detail. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of dependency graphs and the presence of an output schema (unseen), the description is incomplete. It does not explain what the graph represents, how depth affects it, or how to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. With 0% schema description coverage, the description must compensate, but it completely ignores the parameters, leaving the agent confused about 'entry_point', 'depth', and 'format'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a dependency graph, but it lacks specificity about what kind of dependencies (e.g., Rails model/class relationships) and does not differentiate from sibling tools like 'circular_dependencies' or 'data_flow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 are no exclusions, prerequisites, or context clues about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_explain_method_resolutionCRead-onlyIdempotent
モデルのメソッド解決順序（MRO）・祖先チェーン・メソッドオーナーを返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the output content (MRO, ancestor chain, method owner). However, it omits other behavioral aspects like performance or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too brief given the tool has three parameters. It is front-loaded with the main purpose, but omits essential parameter details, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks explanation of parameters and does not provide enough context for correct invocation. The tool has one required parameter and two optional ones, but the description offers no hints on how to use them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters, but it fails to mention any of the three parameters (model_name, method_name, show_internal). The schema only provides names, leaving the agent without guidance on parameter usage.
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?
The description clearly states the tool returns MRO, ancestor chain, and method owner for a model. It uses a specific verb ('返す') and resource ('メソッド解決順序'), but does not differentiate from siblings like rails_lens_introspect_model, which may also return model 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/5
Does 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 (e.g., rails_lens_introspect_model). It does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_extract_concern_candidateARead-onlyIdempotent
Fat Model のメソッドを凝集度で分析し、Concern切り出し候補を根拠付きで提示する
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds valuable context about analyzing cohesion and providing evidence, which enhances transparency beyond the annotations.
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?
A single concise sentence that front-loads the purpose. No unnecessary words, but could be slightly more structured (e.g., break into steps). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. It mentions 'konsho' (evidence) which is helpful. However, it omits prerequisites (e.g., that the model must exist and be a Fat Model). Overall adequate for a read-only analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (though schema itself has parameter descriptions). The tool description adds no additional meaning beyond what the schema already provides for model_name and min_cluster_size. Does not explain parameter format, constraints, or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it analyzes Fat Model methods by cohesion and presents Concern extraction candidates with evidence. Uses specific verb-resource pairing and distinguishes from siblings like rails_lens_analyze_concern which deals with existing concerns.
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?
No explicit when-to-use or when-not-to-use guidance. However, from sibling context, it is implied that this tool is for extracting new concern candidates while others analyze existing concerns. Missing explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_find_referencesCRead-onlyIdempotent
コード参照検索
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds no further behavioral details (e.g., how results are returned or limitations). With annotations covering the safety profile, the description's lack of additional context is adequate but not excellent.
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 description is extremely concise (a single phrase). While it is front-loaded and has no unnecessary words, it is almost too terse, sacrificing informativeness for brevity. A slightly longer description could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, one required, and an output schema, along with a large set of sibling tools, the description is insufficient. It does not explain what 'references' means, the scope of search, or how results are structured. The output schema exists but its content is not provided; the description should compensate but doesn't.
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?
The input schema has descriptions for all three parameters ('Search type', 'Search query', 'Search scope'), so schema coverage is effectively 100% despite context indicating 0%. The tool description does not add any extra meaning beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'コード参照検索' (code reference search) indicates the tool finds references but doesn't specify what kind (e.g., method, model, constant). It is not a tautology and provides a general purpose, but lacks specificity to distinguish it from sibling tools like rails_lens_explain_method_resolution or rails_lens_dead_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Sibling tools include many search-like tools (e.g., rails_lens_explain_method_resolution, rails_lens_dead_code), and the description offers no context for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_gem_introspectCRead-onlyIdempotent
モデルに影響を与えているGemのメソッド・コールバック・ルートを返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context that it returns gem-specific influences, which is useful but minimal. No additional behavioral details like error handling or response structure are provided.
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 description is a single concise sentence that front-loads the core purpose. However, it lacks structure for readability (e.g., bullet points) and additional details could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of many siblings, the description is incomplete. It does not explain how to use the optional gem_name parameter or provide examples. The output schema likely covers return values, but invocation guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters or their meanings. The tool has two parameters (model_name required, gem_name optional), but the description offers no guidance on how to use them.
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?
The description clearly states that the tool returns gem methods, callbacks, and routes affecting a model. It uses a specific verb and resource, but does not explicitly differentiate it from sibling tools like rails_lens_introspect_model or rails_lens_trace_callback_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. The description does not mention prerequisites, constraints, or scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_get_routesARead-onlyIdempotent
RailsアプリのルーティングをすべてJSON形式で返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal behavioral context beyond 'returns all routing in JSON'. No additional traits like rate limits or auth needs are 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and contains no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters, annotations, and an output schema, the description is complete. It tells the agent exactly what the tool does and the format of its output.
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% (no parameters), so baseline is 3. The description does not add parameter info because none exist. It adequately covers the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all Rails routing in JSON format, with a specific verb ('returns'), resource ('all routing'), and output format ('JSON'). It distinguishes itself from siblings as the only tool dedicated to routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While there is no explicit when-to-use or when-not-to-use guidance, the tool is straightforward (no parameters, read-only). The context implies it should be used to inspect routing, and the description is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_get_schemaARead-onlyIdempotent
RailsアプリのDBスキーマ情報を取得
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, read-only profile. The description adds no additional behavioral context beyond the verb 'get', which aligns with the annotations. No contradictions; the description is neutral but not informative beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and perfectly sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema (not shown), the description is nearly complete. It could benefit from mentioning that it returns the full schema structure, but the context of the sibling tools and annotations make it sufficiently clear. The output schema likely provides the necessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage via schema description. According to the rubric, when there are 0 parameters, the baseline is 4. The description does not need to elaborate on parameters, and no value is added or lost.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'RailsアプリのDBスキーマ情報を取得' clearly specifies the verb 'get' and the resource 'DB schema information' for a Rails application. It is specific and distinct from the sibling tools, which focus on analysis, dependencies, or code inspection rather than schema retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. With 18 sibling tools, the lack of usage context or prerequisites leaves the agent without decision support. The description merely states what it does without any conditional or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_introspect_modelARead-onlyIdempotent
モデルの全依存関係（associations, callbacks, validations, scopes, concerns, schema等）を返す。 モデルを変更する前に必ずこのツールで影響範囲を確認すること。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds context by detailing what the tool returns (dependencies like associations, callbacks, etc.) and the usage purpose, which goes beyond the annotations. It does not describe any additional behavioral traits, but the annotations already cover safety. Score 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the function, the second gives usage advice. No wasted words, front-loaded with the key action. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (so return values are documented elsewhere) and annotations are present, the description is sufficiently complete. It covers what the tool does, when to use it, and lists the dependency types. It could mention the optional 'sections' parameter briefly, but overall it is adequate for this complexity. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (model_name with example, sections with default). The tool description adds value by listing the types of dependencies (associations, callbacks, etc.), which gives meaning to what 'sections' might include. Despite context signals indicating 0% schema description coverage, the actual schema has descriptions, so the bar is lowered. The tool description enhances understanding beyond the schema, justifying a 4.
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?
The description clearly states that the tool returns all dependencies of a model (associations, callbacks, etc.), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like rails_lens_analyze_impact or rails_lens_dependency_graph, so a score of 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Before changing a model, be sure to check the scope of impact with this tool.' This tells the agent when to use it. It does not mention when not to use it or alternatives, so it scores 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_list_modelsARead-onlyIdempotent
Railsアプリのモデル一覧を取得
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, and not destructive. The description adds no additional behavioral context, such as whether models are fetched live or cached, if the list includes all models (e.g., system vs. application models), or performance implications. Given the annotations, a higher score would require extra value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese that directly states the purpose. It is front-loaded and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple list tool with no parameters and an output schema present. It clearly states what the tool retrieves. However, it could be more complete by clarifying whether the list includes all models or only those in certain namespaces, but the presence of an output schema mitigates this gap.
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?
The tool has no parameters (schema coverage 100%). The description correctly mentions no parameters, so it doesn't need to add meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'list_models' and description 'Railsアプリのモデル一覧を取得' clearly state the tool's purpose: retrieving a list of models in a Rails application. It uses a specific verb (list) and resource (models), and distinguishes from siblings like 'introspect_model' (single model) and 'get_schema' (database schema).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list of all models is needed. While no explicit guidance on when not to use is given, the context of sibling tools (e.g., 'introspect_model' for details) makes the use case clear. No alternatives or exclusions are stated, but the tool's simplicity and uniqueness make this acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_migration_contextBRead-onlyIdempotent
テーブルのスキーマ・インデックス・外部キー・マイグレーション履歴を返し、適切な警告とテンプレートを提供する
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the specific data returned (schema, indexes, foreign keys, migration history) and that it provides warnings and templates, which goes beyond annotation hints.
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 description is a single sentence that concisely captures the tool's purpose. It is front-loaded with the key outputs. Slightly more structure (e.g., listing items) could improve readability, but 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?
The description covers the main outputs but does not explain how the operation parameter influences the returned data. An output schema exists, so return values don't need elaboration, but the role of 'operation' in customization is missing.
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?
The input schema already provides clear descriptions for both parameters (operation and table_name). The description does not add parameter-level meaning beyond what is in the schema. With high schema coverage, a baseline of 3 is appropriate.
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?
The description clearly states it returns table schema, indexes, foreign keys, and migration history, with warnings and templates. It is specific about the resource (table) and the action (returning context). However, it does not explicitly differentiate from sibling tools like rails_lens_get_schema or rails_lens_introspect_model, which may overlap somewhat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention prerequisites, conditions, or when it should be avoided. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_refresh_cacheAIdempotent
キャッシュを手動で無効化する（tool_name省略時は全キャッシュ）
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show idempotentHint=true and destructiveHint=false. The description adds detail that the tool can invalidate either a specific tool's cache or all caches, which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in Japanese, front-loaded with the main action and parameter nuance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is minimally adequate. It covers the essential behavior. Could mention return value briefly, but output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full burden. It explains the single parameter 'tool_name' well: when omitted, the action targets all caches; when specified, it targets that tool's cache. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (manually invalidate cache) and the resource (cache, optionally scoped to a tool). This distinguishes it from all sibling tools, which are analytical in nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (to manually invalidate cache) and provides a conditional usage note (if tool_name is omitted, invalidate all caches). It does not discuss alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_screen_mapBRead-onlyIdempotent
画面とソースコードの双方向マッピングを提供する。
3つのモードがある:
screen_to_source: URL またはコントローラ名から、その画面を構成する全ファイルを返す
source_to_screens: ファイルパスから、そのファイルが使われている全画面を返す
full_inventory: 全画面の台帳を自動生成する （ドキュメントがないプロジェクトの全体把握に有効）
画面を変更する前にこのツールで影響範囲を確認すること。 特にパーシャルやヘルパーの変更は複数画面に影響する可能性がある。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds behavioral context by detailing the three modes and their outputs (e.g., 'returns all files', 'returns all screens'). This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and minimal filler. However, it lacks a structured breakdown of parameters or return formats. It earns its place but could be more organized.
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?
The description covers the main modes and their return types (files, screens, ledger), which is adequate for the primary use cases. But given the 9 parameters and lack of output schema detail, it may not address all edge cases or parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains how to use each mode (e.g., URL/controller for mode1, file path for mode2) but does not describe parameters like 'format', 'locale', 'group_by', 'include_api', or 'method_name' in detail. This is insufficient given the 9 parameters.
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?
The description clearly states the tool provides bidirectional mapping between screens and source code, listing three specific modes. The verb '提供する' and resource '画面とソースコードの双方向マッピング' make purpose unambiguous. However, it does not explicitly distinguish from sibling tools, though the screen-mapping focus is evident from the name.
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?
The second paragraph gives explicit usage guidance: 'Before changing screens, use this tool to check impact range.' This tells when to use. However, there is no when-not-to-use or alternatives mentioned, limiting completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_test_mappingARead-onlyIdempotent
モデルやメソッドに関連するテストファイルを検出し、実行コマンドを返す
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that the tool returns an execution command, providing extra behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the action and output. No extraneous content; every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown here), description does not need to detail return values. It adequately describes the tool's purpose and main behavior, though could mention the Rails-specific context.
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 already provides descriptions for both parameters ('target' and 'include_indirect') with examples. Description does not add further parameter details beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (検出する/detect) and resource (テストファイル/test files), and specifies output (実行コマンドを返す/return execution command). It distinguishes from sibling tools like rails_lens_analyze_concern or rails_lens_dependency_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings. Usage is implied only from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rails_lens_trace_callback_chainCRead-onlyIdempotent
コールバック連鎖トレース
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no behavioral context beyond that, but does not contradict annotations. A score of 3 is appropriate as minimal value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), but it sacrifices informativeness for brevity. It is not front-loaded with key details; it merely restates the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of tracing callback chains and the presence of an output schema, the description should explain what the trace reveals (e.g., order, dependencies). It lacks completeness for a tool with two required parameters and no parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for model_name or lifecycle_event. The description does not clarify these parameters (e.g., what 'lifecycle_event' values are valid), failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'コールバック連鎖トレース' (Callback chain trace) is essentially a translation of the tool name, providing no specific verb or resource. It fails to distinguish from sibling tools like rails_lens_data_flow or rails_lens_dependency_graph, which could also involve tracing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3.2/5.0
Disambiguation4/5
Most tools have distinct purposes like analyzing concerns, dead code, or screen mappings. However, a few tools like analyze_impact, introspect_model, and dependency_graph may overlap in scope, though descriptions help differentiate them.
Naming Consistency4/5
All tools follow the consistent prefix 'rails_lens_' and use snake_case. The naming pattern mixes verb-object (analyze_impact, extract_concern_candidate) with noun phrases (dead_code, dependency_graph), but the overall style is predictable.
Tool Count3/5
With 19 tools, the count is in the borderline range (16-25). For a comprehensive Rails analysis server, the breadth is justified, but some tools could potentially be merged without losing clarity.
Completeness5/5
The tool set covers a wide range of Rails analysis needs: models, schema, routes, migrations, callbacks, dependencies, dead code, test mapping, screen mapping, and more. There are no obvious gaps for the intended purpose of understanding and refactoring Rails applications.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI agents structured code understanding and precise code intelligence via local indexing of AST, call graphs, and semantic search.764Apache 2.0
- AlicenseNot gradedqualityDmaintenanceUniversal MCP server that analyzes any codebase and provides structured context to AI assistants. Dynamic, accurate, and token-efficient.14MIT
- AlicenseNot gradedqualityAmaintenanceA local-first MCP server that gives AI coding agents durable project memory, dependency graphs, and impact analysis to answer team knowledge and cross-file change questions before editing.361Unlicense - libtelnet variant
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/ei-nakamura/rails-lens'
If you have feedback or need assistance with the MCP directory API, please join our Discord server