sugestim

by woladi

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: about introduces, build_metaphor constructs metaphors, influence_audit audits influence, meta_model_challenge challenges vague language, milton_analyze detects patterns, milton_generate generates them, pacing_leading handles pacing/leading, trance_signals deals with trance cues, and utilize reframes obstacles. No overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun or noun_verb pattern in snake_case (e.g., build_metaphor, meta_model_challenge, milton_analyze). The only slight outlier is 'about', but it's a standard convention for introductory tools.
Tool Count5/5
With 9 tools, the server is well-scoped for its domain of epistemic hygiene. It covers introduction, offense, defense, and combined tools without being too sparse or bloated.
Completeness5/5
The tool set covers the full lifecycle: overview, metaphor, audit, challenge, analysis, generation, pacing, trance signals, and reframe. It addresses both offensive and defensive aspects comprehensively, with no obvious gaps.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the output structure (checklist, lens, policy, output_contract) and rules (provenance, threshold). However, it does not clarify if the tool has side effects, requires authentication, or has rate limits. The behavior is partially transparent but missing safety implications.
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 verbose and dense, with many technical details and a long list of output fields. It is not front-loaded effectively; the most important sentence ('FLAGSHIP DEFENSE...') is first, but the rest is a wall of text that could be more concise.
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 tool has 6 parameters, no output schema, and no annotations. The description covers the purpose and detailed output structure, but still lacks clarity on return format (e.g., how the output fields are organized) and safety. It is reasonably complete but has gaps.
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%, meaning all parameters have descriptions. The tool description adds context for usage (e.g., provenance rule) but does not significantly enhance meaning for individual parameters beyond what is in the schema. Baseline 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's function: it audits incoming text for covert influence, returning structured outputs including a checklist, meta-model lens, provenance policy, and output contract. It distinguishes itself from sibling tools like meta_model_challenge or milton_analyze by being a defense gate rather than just analysis.
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 guidance on when to use the tool: for any incoming text (user request, marketing, negotiation). It includes a provenance rule that auto-escalates severity for third_party_data, and a threshold for when to slow down. However, it does not directly compare to alternatives or state when not to use it.
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?
With no annotations, the description fully carries the burden. It discloses that the tool returns frames, templates, a ratio, connectives, and an audit signal, along with constraints ('NOT but') and a conditional guardrail. The inclusion of both offense and defense modes adds transparency. However, the stray 'direction:'both'' at the end is slightly confusing but does not contradict other information.
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 front-loaded but verbose, containing extraneous details like the inline defense script and the orphaned 'direction:'both''. While each sentence provides information, it could be more concise by avoiding repetition and focusing on key behavioral traits. The bold formatting helps structure but does not improve 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 tool with 5 parameters, no output schema, and no annotations, the description is fairly complete. It covers input expectations, output components (frames, templates, ratio, connectives, defense signal), and constraints (guardrail, connectives). The lack of an explicit return format is partially mitigated by describing the output structure, but a brief example or schema would strengthen completeness.
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 100%, so baseline is 3. The description adds value beyond the schema by explaining the pacing:leading ratio (~3–4:1), the significance of connectives ('and/as/while' not 'but'), and the guardrail's dependence on setting. It also contextualizes how parameters like ratio and lang are used within the tool's logic.
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: given current reality, desired direction, and setting, it returns pacing/leading frames with bilingual templates, a recommended ratio, permitted connectives, and a defense signal. The 'BOTH. OFFENSE: ... DEFENSE: ...' structure provides a specific verb and resource, distinguishing it from sibling tools like influence_audit or meta_model_challenge.
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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions a guardrail conditional on setting and direction but lacks when-not scenarios or comparisons to sibling tools (e.g., milton_generate, trance_signals). Usage context is implied by the technique name alone.
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?
With no annotations, the description carries full burden. It details the output components (frames, isomorphism map, loop_stack, output_contract) and includes a cautionary note about defensive reading. No mention of side effects or permissions, but sufficient for a generative tool.
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 information-dense but front-loaded with the core action. Each sentence adds value, though the list of frames could be more structured. Appropriately sized for the tool's complexity.
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 absence of an output schema, the description adequately explains the return values and includes a defensive note. It covers the tool's complexity, though some terms like 'output_contract' could be expanded.
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?
All parameters have schema descriptions (100% coverage), and the description repeats the parameter names but adds no extra meaning or usage guidance beyond the schema. Baseline score applies.
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: given a problem structure, it returns a metaphor scaffold with specific components. It distinguishes from sibling tools by focusing on metaphor construction.
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 includes a 'DEFENSIVE READ' warning about when to question the metaphor's applicability, but does not explicitly state when to use this tool over siblings like 'analyze' or 'generate'. Usage context is somewhat implied.
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?
Since no annotations are provided, the description carries the full burden. It clearly describes the output (MECE set of violations with recovery questions and output_contract) and the intended domain (hostile agent-relevant examples). It does not mention side effects, but the tool appears to be a pure analysis function with no mutation.
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 long but dense with necessary information. It starts with the core purpose, lists all violation categories, and explains the output structure. Some redundancy exists (e.g., the list of categories could be abbreviated), but it remains well-structured and informative.
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 complex tool with no output schema, the description is quite complete: it details the output structure, categories, and the purpose of each part. It lacks an explicit example of the output JSON but compensates with descriptive text. The domain guidance adds 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 coverage is 100%, so baseline is 3. The description adds context for the 'statement' parameter (vague/pressuring) and the use domain (hostile examples), but does not elaborate on 'context' or 'lang' beyond the schema. Overall, marginal improvement over 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 clearly states the tool's purpose: analyzing vague/pressuring statements using the Meta-Model to produce a categorized list of violations with recovery questions. It distinguishes itself from siblings by emphasizing 'defense' and anti-manipulation, contrasting with Milton pattern tools.
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 context on when to use the tool (for manipulative statements like refund emails, marketing CTAs) and notes it is not for therapy. It implicitly differentiates from sibling tools by calling it 'defense'. However, it does not explicitly state when not to use or compare directly with alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses that it returns a taxonomy index, enforces an invariant, and describes the offensive/defensive duality. It adds significant behavioral context beyond the input schema.
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 front-loaded with the main purpose and is mostly efficient, though it is dense and could be slightly more streamlined. Every sentence adds value.
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 no output schema, the description thoroughly explains what is returned (purpose, framing, ethics, taxonomy index) and provides necessary context for an introductory tool. It is complete for its role.
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% for the single parameter (lang). The description does not add new meaning beyond the schema's enum and default. 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 that the tool returns the server's purpose, framing, and ethics, and is designed to be called first. It distinguishes itself from sibling tools by being a meta-level introduction.
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 before anything else ('so the host knows WHAT this server is for before calling anything else'). It doesn't explicitly state when not to use it or provide alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It thoroughly explains what the tool returns: the full Milton-Model lens, output contract, detected patterns, presuppositions, gaps, vagueness, counter-questions, and covers all sub-types and edge cases. It does not mention runtime behavior or dependencies but comprehensively describes the output behavior.
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 dense yet efficient, front-loading with 'DEFENSE (recognition)' and the core purpose. Every sentence adds specific detail about capabilities and constraints, though the length may be slightly verbose for quick scanning. Still, it earns its length with valuable information.
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?
Despite no output schema, the description fully specifies the return value structure, including the output contract, pattern details, presuppositions, gaps, counter-questions, and edge cases (NO_PATTERNS_DETECTED, INSUFFICIENT_INPUT). It also mentions coverage of all ambiguity sub-types and text-channel markers, making the tool's behavior completely clear.
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 100%, so the schema itself already documents both parameters. The description adds value by specifying that the text is analyzed for 'Milton-Model patterns' and that the response language can be 'pl', 'en', or 'both'. This enriches the parameter meaning beyond the schema definitions.
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 starts with 'DEFENSE (recognition)' and clearly states the tool takes a block of text and returns the canonical Milton-Model lens with patterns, explicitly differentiating from the sibling tool 'milton_generate' by referencing its key set. The verb 'analyze' and specific resource 'Milton-Model patterns' make the purpose unambiguous.
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 this is for 'defense' (recognition), implying it is used to detect patterns rather than generate them. It specifies return statuses for edge cases (no patterns, empty input). However, it does not explicitly state when not to use this tool or provide direct comparisons with siblings like 'milton_generate', leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It openly labels the tool a 'live footgun' and warns about its manipulative potential. It details the defensive counterpart and explains the behavioral traits: returns sub-techniques with from→to reframe and mechanism.
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 front-loaded with 'BOTH. OFFENSE/REFRAME' and every sentence adds value. It is somewhat lengthy but necessary for completeness. Minor repetition could be trimmed, but overall efficient.
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?
No output schema exists, but the description explains the return value (sub-techniques with from→to reframe and mechanism). It also covers the defensive read. Sibling tools are listed, and the context of persuasion techniques is clear.
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%, so the schema already documents parameters. The description adds context (e.g., 'obstacle' as resistance/objection/emotion/manipulation) but does not significantly deepen understanding 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 is for OFFENSE/REFRAME: given an obstacle, it returns utilization sub-techniques. It lists specific techniques (accept_and_utilize, context_reframe, etc.) and distinguishes itself from siblings by covering both offensive and defensive uses.
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 explains the defensive twin and warns against using the coercive aspect on oneself. It provides guidance on when to use it (for obstacles) and how to apply the defensive read. However, it lacks explicit when-not-to-use scenarios or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it returns a scaffold, not a finished induction; each pattern has a defensive block; guardrail applies unless specific settings; ethics are stated. It is comprehensive and honest about the tool's purpose and limitations.
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 dense paragraph, but it is front-loaded with the core purpose. It contains some redundant phrasing, but every sentence adds value. Could benefit from bullet points for the pattern structure, but overall it is reasonably concise given the complexity.
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?
Despite no output schema, the description details the return structure (canonical key, family, templates, examples, defensive block). It covers ethics and guardrail conditions. Given the tool's complexity and the absence of output schema, the description is remarkably complete.
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 100%, so baseline is 3. The description adds meaning by explaining the role of 'setting' in gating the guardrail, 'patterns' as optional filter, and 'family' as two-tier filter. It goes beyond the schema by tying parameters to the tool's overall 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 it returns a structured scaffold of Milton-Model patterns. It specifies the verb 'generate' and the resource (Milton-Model patterns). It distinguishes from sibling 'milton_analyze' by mentioning the shared 'join key', and the defensive block differentiates it from other tools.
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 guidance on settings that gate the guardrail (education and self_defense_demo allow recognition-oriented use). It implicitly suggests when to use (when wanting offensive patterns with a shield) and when not to (covert use on non-consenting party is a failure mode). However, it lacks explicit alternatives or when-not-to-use scenarios compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and fully discloses behavioral traits: that both modes always return the defensive read, what the return values include for each mode, and the recommended action. It is thorough and transparent.
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 detailed but well-structured, starting with a clear summary ('BOTH') followed by mode-specific details. It is not overly verbose, but could be slightly more concise by breaking into separate paragraphs for readability.
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?
Despite lacking an output schema, the description comprehensively covers what is returned for each mode, including the absorption verdict. Given the tool's dual-mode complexity, it provides sufficient information for an agent to use it correctly.
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 100%, so the baseline is 3. The description adds value by elaborating on what each mode returns and the significance of the 'lang' parameter. While the schema already describes parameters, the description provides context on usage and expected output.
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 dual purpose: detecting absorption signals (defense) and providing induction frames (offense). It specifies the required input (observation and mode) and the output (signal taxonomy or induction frames). This distinguishes it from sibling tools like 'milton_analyze' or 'meta_model_challenge'.
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 explains when to use each mode ('detect' for defense, 'induce' for offense) and provides a recommended action ('re-engage uptime'). However, it does not explicitly mention when NOT to use this tool or cite alternatives among 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:

[![sugestim MCP server](https://glama.ai/mcp/servers/woladi/sugestim/badges/card.svg)](https://glama.ai/mcp/servers/woladi/sugestim)

Score Badge

Copy to your README.md:

[![sugestim MCP server](https://glama.ai/mcp/servers/woladi/sugestim/badges/score.svg)](https://glama.ai/mcp/servers/woladi/sugestim)

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/woladi/sugestim'

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