Sensei MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity, as each targets a specific aspect of Dojo development (e.g., introduction, configuration, logic, models, testing, tokens, and a main prompt). The descriptions clearly differentiate their scopes, such as dojo_101 for beginners versus dojo_logic for expert guidance, ensuring agents can easily select the right tool.
Naming Consistency5/5
All tool names follow a consistent 'dojo_' prefix pattern with descriptive suffixes (e.g., dojo_config, dojo_logic, dojo_model), using snake_case uniformly. This predictable naming scheme makes it easy for agents to understand the domain and purpose at a glance, with no deviations in style or convention.
Tool Count5/5
With 7 tools, the count is well-scoped for the server's purpose of Dojo development guidance, covering key areas like setup, logic, models, testing, and tokens without being overwhelming. Each tool earns its place by addressing a distinct need, making the set comprehensive yet manageable for agents.
Completeness4/5
The tool surface is nearly complete for Dojo development, covering essential aspects from beginner introduction to advanced logic, models, testing, and token standards. A minor gap exists in deployment or integration tools, but core workflows are well-covered, allowing agents to work around any missing operations effectively.
Average 3.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions 'guidance' and configuration activities but doesn't clarify whether this tool performs actions, provides information, modifies files, or requires specific permissions. It fails to disclose key behavioral traits like whether it's read-only, destructive, or has side effects, which is a significant gap for a configuration tool with zero annotation coverage.
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 two sentences: the first states the purpose, and the second provides usage guidelines. It's reasonably concise but could be more front-loaded with a clearer action verb. The phrase 'Essential guidance' is somewhat vague, and the list of configuration activities feels like it's trying to cover too much ground without clarifying the tool's core function. It's adequately structured but not optimally efficient.
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 configuration tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool actually does (e.g., returns configuration templates, validates settings, applies changes) or what users can expect as a result. For a tool with no structured data to rely on, the description should provide more complete context about behavior and outcomes.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline of 4 for tools with no parameters, as there's no gap to compensate for.
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 states the tool provides 'essential guidance for configuring Dojo projects' which gives a general purpose, but it's vague about what specific action the tool performs. It lists several configuration activities (setting up Scarb.toml, creating profile files, etc.) but doesn't specify whether this tool performs these actions, helps with them, or provides information about them. The purpose is clear enough to understand the domain but lacks specificity about the tool's actual function.
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 explicitly states 'Use this when' followed by a list of configuration scenarios, providing clear context for when to invoke this tool. However, it doesn't mention when NOT to use it or how it differs from sibling tools like dojo_101, dojo_logic, or dojo_model, which might also relate to Dojo project configuration. The guidance is helpful but lacks sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions providing 'comprehensive guidance' but doesn't describe how it behaves—e.g., whether it generates interactive prompts, returns static text, handles follow-ups, or has any limitations like response length or rate. This leaves significant gaps in understanding its operational traits.
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 concise and front-loaded, stating the main purpose in the first sentence and adding usage context in the second. Both sentences earn their place by clarifying the tool's role and when to use it, with no wasted words. However, it could be slightly more structured by explicitly listing key aspects of 'comprehensive guidance'.
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 has no parameters, no annotations, and no output schema, the description provides basic purpose and usage guidelines, which is adequate for a simple prompt tool. However, it lacks details on behavioral aspects (e.g., output format, interaction model) and doesn't differentiate from siblings, making it incomplete for optimal agent use in a context with multiple similar tools.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist, and the description doesn't incorrectly reference any.
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 states the tool is 'the main system prompt for Dojo development' and provides 'comprehensive guidance across all aspects of Dojo development', which gives a general purpose. However, it's somewhat vague about what specific actions it performs (e.g., generating code, answering questions, providing tutorials) and doesn't clearly distinguish it from sibling tools like 'dojo_101' or 'dojo_logic' that might also offer guidance.
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 explicitly states when to use this tool: 'when starting a conversation about Dojo or Cairo development, or when you need comprehensive guidance across all aspects of Dojo development'. This provides clear context for usage, but it doesn't specify when NOT to use it or mention alternatives among the sibling tools, such as using 'dojo_101' for basics or 'dojo_config' for configuration-specific help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool provides 'guidance,' it doesn't clarify whether this is informational (read-only), interactive, or involves any side effects like creating/modifying files. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
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 efficiently structured in two sentences: the first states the core purpose, and the second provides specific usage examples. Every word contributes to understanding the tool's function, with no wasted text or redundancy.
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 has no parameters (schema coverage 100%) and no output schema, the description adequately covers the 'what' and 'when' aspects. However, as a tool with no annotations, it lacks details about behavioral traits (e.g., whether it's read-only, has side effects, or requires specific permissions), making it incomplete for full agent understanding.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without attempting to describe nonexistent parameters, earning a high baseline score for not adding unnecessary information.
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's purpose as providing 'specialized guidance for creating and working with Dojo models' and lists specific activities like defining data structures, creating model schemas, implementing model traits, and understanding relationships/constraints. This gives a comprehensive view of what the tool does, though it doesn't explicitly differentiate from sibling tools like dojo_config or dojo_logic.
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 clear context for when to use the tool ('Use this when you need to define data structures, create model schemas, implement model traits, or understand model relationships and constraints'), which gives practical guidance. However, it doesn't mention when NOT to use it or explicitly name alternatives among the sibling tools, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a 'guide,' implying it's informational and likely read-only, but does not disclose behavioral traits such as whether it modifies data, requires authentication, has rate limits, or what the output format is. This leaves significant gaps for a tool with zero annotation coverage.
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, front-loaded with the core purpose and followed by usage guidelines. Every sentence adds value without redundancy, making it efficient and well-structured.
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 (likely informational with no parameters) and lack of annotations/output schema, the description is moderately complete. It explains purpose and usage but lacks details on behavior and output, which are important for a guide tool. It's adequate but has clear gaps in transparency.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline is 4 for 0 parameters, as it avoids unnecessary information.
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's purpose as a 'Comprehensive guide for writing tests for Dojo applications,' specifying the verb 'guide' and resource 'tests for Dojo applications.' It distinguishes from siblings by focusing on testing rather than configuration, logic, models, etc., though it doesn't explicitly name alternatives.
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 clear context for when to use the tool: 'when creating unit tests, integration tests, setting up test environments, or verifying the correctness of your Dojo systems and models.' This gives explicit scenarios but does not mention when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states it provides 'guidance' but doesn't clarify what that means operationally - is it documentation retrieval, code generation, validation, or something else? It doesn't mention whether this tool performs any actions (like generating files), requires specific permissions, has side effects, or what format the guidance comes in. For a tool with zero annotation coverage, this is insufficient behavioral transparency.
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 perfectly concise with two sentences that each earn their place. The first sentence establishes the core purpose ('Detailed guidance on implementing token standards in Dojo'), and the second sentence provides specific usage contexts. There's zero waste or redundancy, and the information is front-loaded with the most important details first.
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 has no parameters (empty schema), no annotations, and no output schema, the description provides adequate basic context about what the tool is for. However, it doesn't explain what form the 'guidance' takes or what the user can expect as a result. For a tool that presumably provides some kind of output (even if just informational), more detail about the nature of that output would improve completeness. The description is minimally viable but has clear gaps in explaining the tool's behavior.
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 tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters since there are none. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully documents the lack of parameters. The description focuses appropriately on what the tool does rather than parameter details.
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 'Detailed guidance on implementing token standards in Dojo' and lists specific use cases (ERC20, ERC721, ERC1155 tokens, implementing token functionality, integrating tokens with games). It distinguishes itself from siblings by focusing specifically on token implementation rather than general Dojo topics like configuration, logic, or testing. However, it doesn't specify the exact form of guidance (documentation, code generation, validation, etc.), keeping it at a 4 rather than a 5.
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 explicitly states 'Use this when creating ERC20, ERC721, or ERC1155 tokens, implementing token functionality, or integrating tokens with your Dojo game.' This provides clear context about when to use this tool. However, it doesn't mention when NOT to use it or explicitly name alternatives among the sibling tools (like dojo_config or dojo_logic), which would be needed for a perfect score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'expert guidance' but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what form the guidance takes (e.g., code examples, explanations). This leaves significant gaps for a tool that likely provides advisory 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?
The description is two concise sentences that are front-loaded with the purpose and followed by specific usage contexts. Every phrase adds value without redundancy, making it efficiently structured.
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 complexity of providing 'expert guidance' on Dojo systems, the description lacks details on output format, depth of guidance, or examples. With no annotations and no output schema, it's incomplete for understanding what the tool actually returns, though it adequately covers when to use it.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 'expert guidance on implementing Dojo systems and game logic,' which is a specific purpose. It distinguishes from siblings by focusing on implementation guidance rather than configuration, modeling, or other aspects. However, it doesn't explicitly contrast with each sibling tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Use this when writing contract functions, implementing game mechanics, handling state changes, or working with the World contract to read/write models.' This gives clear contexts for when to invoke the tool, though it doesn't specify when NOT to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as an 'introduction' and 'overview', which suggests it's informational and non-destructive. However, it doesn't specify behavioral traits like whether it's interactive, returns structured data, or has any side effects. The description adds context about its beginner-friendly nature but lacks details on execution behavior.
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 front-loaded with the core purpose ('Beginner-friendly introduction to Dojo development') and follows with specific usage scenarios in a single, efficient sentence. Every part adds value without redundancy, making it appropriately sized and well-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 the tool's complexity (introductory, 0 parameters) and lack of annotations/output schema, the description is reasonably complete. It explains the purpose, usage, and scope. However, it could be more complete by hinting at what the output might contain (e.g., tutorial steps, explanations) since there's no output schema, but it's adequate for this simple tool.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it appropriately doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary parameter discussion.
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's purpose: 'Beginner-friendly introduction to Dojo development' with specific verbs like 'starting a new Dojo project', 'understanding the basic workflow', and 'high-level overview of the Dojo development process and architecture'. It distinguishes itself from siblings like dojo_config, dojo_logic, etc., which likely handle specific technical aspects rather than introductory guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this when starting a new Dojo project, understanding the basic workflow, or when you need a high-level overview'. It implies alternatives by distinguishing itself from sibling tools that likely serve more advanced or specific purposes, though it doesn't explicitly name them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sensei-mcp MCP server](https://glama.ai/mcp/servers/dojoengine/sensei-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dojoengine/sensei-mcp)

Score Badge

Copy to your README.md:

[![sensei-mcp MCP server](https://glama.ai/mcp/servers/dojoengine/sensei-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dojoengine/sensei-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dojoengine/sensei-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server