ultrabrain-mcp

Server Quality Checklist

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

Latest release: v1.0.6
Disambiguation5/5
All tools have clearly distinct purposes: analyze, export, merge, review, templates, think, and validate cover different aspects of reasoning session management without overlap.
Naming Consistency5/5
All tool names follow a consistent 'ultrabrain_<verb>' pattern in snake_case, making naming predictable and easy to understand.
Tool Count5/5
7 tools is well-scoped for the domain of reasoning session management, covering key operations without being excessive or too sparse.
Completeness4/5
The tool set covers analysis, review, validation, export, templates, and reasoning guidance. Minor gap might be direct editing or deletion, but core workflows are well supported.
Average 3.5/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
- 101 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

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 context about rendering formats but does not disclose other behavioral aspects such as whether the session must exist, the size of returned data, or the effect of the 'limit' parameter. With annotations covering safety, the description provides some additional value but not rich behavioral context.
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 of 15 words, front-loading the key verb 'Render'. It is efficient and avoids redundancy. However, given the number of siblings and parameters, slightly more detail could be included without sacrificing 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?
The tool has 3 parameters, no output schema, and many siblings. The description does not clarify the return type of the rendering (e.g., string, JSON object), nor does it explain the 'limit' parameter or that a session must exist. This leaves significant gaps for an agent to correctly invoke the 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 low (33%, only session_id has a description). The description only implies the 'format' parameter by listing output types, but it omits 'mermaid' from the list despite being in the enum. The 'limit' parameter is not explained, and 'session_id' is already described in the schema. The description adds minimal meaning beyond the schema for a low-coverage scenario.
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 verb 'Render' and the resource 'reasoning session', and lists possible output formats. However, it does not distinguish this tool from siblings like ultrabrain_export or ultrabrain_status, which could also render or output data. The specificity is good but sibling differentiation is absent.
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 such as ultrabrain_export (for exporting) or ultrabrain_history (for history). There is no mention of prerequisites (e.g., a session must exist) or typical use cases. The score reflects the lack of any usage direction.
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?
Annotations indicate no read-only, open-world, idempotent, or destructive hints, so the tool is expected to mutate state. However, the description adds no behavioral details beyond 'create or continue'—e.g., what happens if the branch already exists, or what side effects occur. Annotations are unhelpful (all false), and the description fails to fill the gap.
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 a single sentence that is too terse given the tool's complexity (33 parameters, 8 siblings, nested objects). While it front-loads the purpose, it lacks necessary details to guide agent usage, making it under-specified rather than concise.
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 high complexity (33 parameters, no output schema), the description is incomplete. It does not explain return values, side effects, or how branching relates to the main reasoning chain. Many parameter descriptions in the schema are sparse, and the tool description offers no synthesized guidance.
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%, so baseline is 3. However, many parameter descriptions are minimal (e.g., 'Reasoning mode.' for 'mode', 'Optional tags.' for 'tags'), adding little beyond the parameter name. Some, like 'next_thought_needed', are more informative. The tool description itself adds no parameter-level 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?
The description clearly states the tool's action ('Create or continue') and resource ('Ultrabrain branch from a prior thought'). It effectively distinguishes from siblings like ultrabrain_start (start new) and ultrabrain_merge (merge branches), which are named in the sibling list.
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 branching from a prior thought, but does not explicitly state when to use this tool versus alternatives like ultrabrain_start or ultrabrain_think. No comparative guidance is provided, leaving the agent to infer context from the tool name alone.
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?
Annotations are all false, providing no behavioral hints. The description only states the action (create, seed) without disclosing side effects, required permissions, or session lifecycle details. This is minimal transparency.
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?
Single sentence that efficiently communicates the core purpose. Could be slightly more structured or detailed, but it is well front-loaded.
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 8 parameters and no output schema, the description is too sparse. It does not explain 'branded LCV', session behavior, or what the tool returns. Incomplete for an agent to use reliably.
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 description coverage is 88%, so most parameters have basic descriptions. The tool description adds no additional meaning beyond the schema. Baseline 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 creates a reasoning session and optionally seeds a first thought. It uses a specific verb and resource, and distinguishes itself from sibling tools like ultrabrain_think (which operates within a session).
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 that this should be called before other ultrabrain tools, nor does it provide any context about prerequisites or use cases.
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?
Annotations already indicate the tool is read-only and idempotent. The description adds value by detailing the kinds of analysis performed, but does not disclose additional behaviors such as reliance on a session_id or potential side effects. It is consistent with annotations, hence no contradiction.
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 of 13 words, efficiently listing key analysis aspects. It is well-structured and front-loaded, though slightly sparse.
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 no output schema, the description would benefit from describing the return format. It lists analysis items but does not specify structure (e.g., JSON fields). With two optional parameters and good annotations, completeness is adequate but not thorough.
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?
Input schema coverage is 100%, with descriptions for both parameters. The description does not elaborate on parameter usage beyond the schema, so it meets the baseline without adding extra meaning.
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 specifies a clear verb ('Analyze') and lists specific aspects (quality, confidence, bias counts, etc.), making the tool's purpose apparent. However, it does not differentiate from siblings like ultrabrain_metrics or ultrabrain_review, which may have overlapping functionality.
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 other siblings, nor does it mention prerequisites or context. It simply states what it does, leaving the agent without decision criteria.
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?
The description mentions 'update' which aligns with the destructiveHint annotation. However, it does not elaborate on side effects, permissions, or whether updates are reversible. The annotation already indicates destructiveness, so the description adds minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence efficiently communicates the core action. However, it could be slightly more structured (e.g., listing key fields) without adding length.
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 high parameter count and presence of nested objects, the description is too brief. It does not mention required thought_number, optional session_id, or response_format, leaving agents without sufficient context for correct invocation.
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 coverage is low (21%) and the description only mentions a subset of parameters (evidence, confidence, risks, actions, quality metrics). It does not explain format, constraints, or purpose of omitted parameters like tags, assumptions, or alternatives. The quality_metrics object is described in schema but not in the description.
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 indicates the tool updates an existing thought, listing specific fields like evidence, confidence, risks, actions, or quality metrics. This distinguishes it from sibling tools like ultrabrain_think (for generating thoughts) and ultrabrain_validate (for validation).
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 guidance on when to use this tool vs alternatives. It does not specify prerequisites (e.g., thought must exist) or when to prefer ultrabrain_update over ultrabrain_validate or ultrabrain_analyze.
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?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true, and openWorldHint false, covering key behavioral traits. The description adds a list of what is checked but does not disclose additional traits such as permissions or side effects. With annotations present, the description adds modest context.
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?
One sentence, front-loaded with the action 'Check', no extraneous words. Could be slightly more structured (e.g., using a list) but is efficient and clear.
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 13 sibling tools and no output schema, the description lacks details about return format or scoring. It doesn't explain the effect of the 'strict' parameter or what the output looks like, leaving the agent uncertain about the tool's complete behavior.
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 of the three parameters (session_id, strict, response_format). Input schema has 67% coverage (descriptions for session_id and response_format), but the description adds no extra meaning or constraints 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 uses a specific verb 'Check' and identifies the resource 'reasoning session' with five clear aspects (evidence, alternatives, verification, bias, closure gaps), distinguishing it from sibling tools like ultrabrain_analyze or ultrabrain_review.
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 like ultrabrain_analyze or ultrabrain_review. It does not mention when-not scenarios or prerequisites.
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?
Annotations (readOnlyHint=false) indicate the tool is not read-only, which aligns with 'merge' likely being mutating. However, the description does not disclose whether original branches are affected, if the operation is reversible, or any side effects. It provides minimal behavioral insight beyond the action itself.
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?
A single sentence that is concise, front-loaded with the verb and resource, and contains no unnecessary words. Every part of the description contributes to understanding the tool's primary action.
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 5 parameters and no output schema, the description is extremely brief. It does not explain the merge process, the structure of the output, or how parameters like session_id or response_format affect behavior. The tool's complexity is not matched by the description's completeness.
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 description coverage is 60% (3 of 5 params have descriptions). The description mentions 'synthesis, best-evidence path, or decision note' which aligns with the strategy enum, adding some meaning. However, the critical 'branch_ids' and 'strategy' parameters lack schema descriptions, and the tool description does not compensate with additional detail.
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 verb 'Merge' and the resource 'branch insights' into specific outputs: 'synthesis, best-evidence path, or decision note.' It effectively distinguishes itself from sibling tools like ultrabrain_branch, which likely creates branches, and ultrabrain_analyze, which may perform 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 this tool versus siblings. The description does not specify prerequisites, when not to use, or provide alternatives. Given the presence of multiple related tools (e.g., ultrabrain_think, ultrabrain_review), explicit usage context is missing.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety characteristics are clear. The description adds that records are 'normalized' and 'recent', but does not elaborate on ordering, filtering, or pagination 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 a single, concise sentence that front-loads the key action and resource. No extraneous words.
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?
No output schema exists, and parameters are poorly documented. The description covers the basic purpose but lacks enough detail for an agent to confidently invoke the tool without additional schema inspection.
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 50% (only session_id has a description). The description does not mention parameters at all, failing to compensate for the lack of schema documentation on the 'limit' parameter. An agent would not know what 'limit' means from the description.
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 uses a specific verb ('return') and clearly names the resource ('recent normalized thought records') and context ('for a session'). It distinguishes itself from sibling tools like ultrabrain_start or ultrabrain_status by focusing on history.
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 provides no explicit guidance on when to use this tool versus alternatives. It is implied that it's for retrieving past records, but no conditions or exclusions are stated.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds specific return fields (thought count, branches, quality score) which aids transparency but does not disclose additional behavioral details.
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 with the purpose and lists key return elements efficiently.
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 no output schema, the description adequately covers the key return fields. It is sufficient for a status retrieval tool, though it could mention the format (e.g., that it returns a JSON object).
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 description coverage is 100% for the single parameter, and the description does not add extra meaning beyond what the schema already provides. The parameter is clearly optional with a default.
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 that the tool returns session status, thought count, branches, and quality score. It uses a specific verb ('Return') and distinguishes from sibling tools like ultrabrain_start or ultrabrain_think which are for starting or thinking.
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 guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest alternative tools for different scenarios.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond what annotations provide. For a read-only export tool, the description could mention that it does not modify the session, but that is already covered by 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 sentence with no wasted words. It front-loads the verb 'Export' and clearly states the resource and output formats.
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?
Given the simple tool with 2 parameters (both optional), 100% schema coverage, and comprehensive annotations, the description fully covers the necessary context. No output schema is needed as the return format is implied by the format parameter.
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%, so baseline is 3. The description mentions 'markdown, text, or JSON' which matches the format enum, but adds no additional meaning. The session_id parameter is described in the schema but not in the description, so the description does not improve parameter understanding.
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 action (export) and resource (a session) with specific output formats (markdown, text, JSON). This distinguishes it from sibling tools like ultrabrain_start which starts a session.
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 you need session data in a specific format, but it does not explicitly state when to use it vs alternatives or provide any when-not scenarios. Among siblings, no guidance on alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context by specifying exactly what runtime information is included (e.g., data directory, active limits), which goes beyond the annotation traits. No contradictions are present.
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, well-structured sentence that front-loads the action ('Return runtime information') and lists the key content areas without unnecessary words. Every phrase adds value.
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 info tool with one optional parameter and no output schema, the description provides a clear scope of returned data. It could be slightly more complete by explaining how response_format affects the output, but the schema already covers that, making this adequate overall.
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 schema provides 100% coverage for the single optional parameter 'response_format', including an enum and description. The tool description itself does not add further parameter semantics, but the schema fully compensates, meeting the baseline expectation for high schema coverage.
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 uses the specific verb 'Return' and clearly identifies the resource as runtime information for the local Ultrabrain MCP server, enumerating the exact content (version, release date, capabilities, tool surface, data directory, active limits). This distinguishes it from sibling tools like status or metrics by detailing a comprehensive server introspection scope.
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 such as ultrabrain_status or ultrabrain_metrics. There is no mention of exclusions, prerequisites, or scenarios where this tool is preferred, leaving the agent without comparative direction.
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?
Annotations already indicate readOnlyHint and idempotentHint; description adds minimal context that it lists templates, but lacks details on pagination, filtering, or meaning of 'LCV'.
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 with action verb and key qualifiers; no redundant words, front-loaded with purpose.
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 no parameters or output schema, description is adequate for a list operation, though could clarify what constitutes a 'template' or return structure.
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?
No parameters exist; description correctly omits param details, and baseline for 0-param tools is 4. No additional meaning needed.
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 uses specific verb 'List' and resource 'LCV Ultrabrain prompt templates' with context 'for common engineering reasoning workflows', clearly distinguishing it from sibling tools like ultrabrain_analyze or ultrabrain_start.
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 list templates vs using them; siblings provide alternative operations but no explicit comparison or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the types of metrics aggregated, enhancing transparency without contradicting 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?
A single, succinct sentence efficiently conveys the tool's purpose without extraneous content, demonstrating excellent conciseness.
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 metrics retrieval tool with one optional parameter and comprehensive annotations, the description adequately covers what the tool returns. Sibling tools are distinct, and no output schema is needed as the return is described. Minor gap: could mention typical use cases post-session.
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 description coverage is 100% and the schema provides complete documentation for the single optional session_id parameter. The description adds no additional parameter insights beyond what the schema supplies.
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 aggregate metrics across multiple categories (session, thought, branch, etc.), distinguishing it from sibling tools that perform actions like start, think, or validate.
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 does not provide explicit guidance on when to use this tool versus alternatives, but the context of sibling tools implies it is for retrieving metrics after operations; lacks clear when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-read-only. The description adds the key behavioral detail that resetting can affect one or all sessions based on the boolean flag, which goes 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, dense sentence that conveys the core action and parameter implication without any wasted words. It is front-loaded with the verb and resource.
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 moderate complexity, lack of output schema, and annotations covering destructiveness, the description is largely complete. It could mention side effects (e.g., loss of session state) but is sufficient for an agent to understand the tool's purpose.
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?
Schema coverage is 50% (session_id described, all_sessions not). The description directly adds meaning to 'all_sessions' by explaining its effect. For session_id, the schema already provides default and optionality, so no further value is added.
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 uses the specific verb 'reset' and resource 'Ultrabrain session', clearly distinguishing it from siblings like 'start' or 'think' which serve different purposes. The scope (one or all sessions) is explicitly stated.
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 use when resetting sessions but provides no explicit guidance on when to use vs alternatives (e.g., 'ultrabrain_start' or 'ultrabrain_update'). No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: it is a reasoning gate, supports branching/revision, requires verification before concluding, and includes meta-checkpoints. Annotations only indicate non-readOnly and non-destructive, so the description adds critical transparency about how the tool modifies reasoning state.
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, dense paragraph that front-loads purpose and immediately follows with actionable protocol. Every sentence earns its place, covering when to branch, revise, set next_thought_needed, and even ends with a meta-question. No redundancy or filler.
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 (33 parameters, no output schema), the description provides a coherent protocol that guides usage across diverse reasoning scenarios. It covers branching, revision, quality metrics, and verification, but could mention the return value or side effects more explicitly.
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?
While schema coverage is 100%, the description adds semantic context by prescribing how parameters should be used (e.g., attach evidence for claims, set step_type honestly, adjust total_thoughts). This goes beyond per-parameter descriptions, providing a usage narrative that enhances parameter understanding.
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 it is a 'Canonical LCV reasoning gate for code work, branching, revisions, quality metrics, bias checks, confidence, and meta checkpoints.' This clearly identifies the tool as the primary reasoning step tool, distinguishing it from sibling tools like ultrabrain_analyze or ultrabrain_review by covering all aspects of reasoning.
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 a detailed protocol: state evidence and assumptions before conclusions, set step_type honestly, attach evidence for factual claims, branch and revise appropriately, adjust total_thoughts, and only set next_thought_needed to false after verification. It explains when to use these features but does not explicitly exclude scenarios or compare to siblings.
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:

[![ultrabrain-mcp MCP server](https://glama.ai/mcp/servers/LCV-Ideas-Software/ultrabrain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LCV-Ideas-Software/ultrabrain-mcp)

Score Badge

Copy to your README.md:

[![ultrabrain-mcp MCP server](https://glama.ai/mcp/servers/LCV-Ideas-Software/ultrabrain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LCV-Ideas-Software/ultrabrain-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/LCV-Ideas-Software/ultrabrain-mcp'

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