EasyTopic MCP Server

Official

by EB-CON-GmbH

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Tools are clearly separated into topic management and documentation project management groups, with each tool having a distinct purpose (list vs get vs add vs write vs transition vs create). No overlapping functionalities.
Naming Consistency5/5
All tools follow the 'easytopic_verb_noun' pattern with consistent verbs (list, get, add, write, transition, create). The only outlier is 'whoami', which is a standard authentication term and fits the pattern.
Tool Count5/5
With 11 tools covering two main domains (topic management and documentation projects), the number is well-scoped. Each tool serves a necessary role without redundancy.
Completeness3/5
Significant gaps exist: no create_topic or delete_topic for topic management, and no delete_doc_page for documentation. Updates to custom fields beyond the plan field are missing. However, core workflows (list, get, update status, add comments, and documentation CRUD for creation/reading/updating) are covered.
Average 4.4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: admin check before creation, specific error response ('notProjectAdmin'), and that parentTopicId null means top-level. No annotations provided, so the description carries full burden and does it well.
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 two sentences, front-loaded with purpose. No wasted words, but the first sentence is somewhat long. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description explains permission flow and parent parameter well, but fails to describe other parameters (topicTypeId, descriptionHtml) and the return value. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only for 'parentTopicId' (null = top-level), but does not explain 'title', 'projectId', 'topicTypeId', or 'descriptionHtml'. Leaves significant gaps.
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 action (creates), the resource (Documentation page/Topic), and the context (under given parent, in a Documentation Project). It distinguishes from sibling tools like list_topics or get_topic by specifying creation.
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 (to create a page), the admin prerequisite, and the error handling ('Ask the human to promote the bot'). It implies when not to use if not admin, but lacks explicit comparison to alternatives.
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 must disclose behavior. It states it's a read operation ('Lists') and specifies ordering and filtering, but omits details on pagination, empty results, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, purpose front-loaded, efficient structure.
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, but the description does not explain the return structure (e.g., fields of each topic). For a simple list tool, this is a moderate gap that could leave the agent uncertain about the output format.
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 0%, so the description adds essential meaning: 'statusKeys' are the filter criteria and should be obtained from 'easytopic_whoami'. This clarifies the parameter's purpose and provides actionable guidance.
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 identifies the verb 'lists' and resource 'Topics', specifies the filter by status keys and ordering by oldest-updated first, and distinguishes from siblings like 'easytopic_get_topic' (single topic) and 'easytopic_transition_status' (state change).
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?
It tells the agent to use status key values from 'easytopic_whoami', which provides context for parameter values, but does not explicitly state when to use this tool versus alternatives or 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 discloses the core behavior (adds a comment, notifies human). It does not address potential side effects or reversibility, but for a simple write tool this is reasonable. The description adds meaningful context beyond the bare schema.
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 immediately states the primary action, followed by essential context. No unnecessary words; every part adds value.
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?
For a simple tool with two required parameters and no output schema, the description covers the action and its primary effect (notification) but omits parameter guidance and any constraints. It is minimally viable but incomplete for an agent to use correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the two parameters ('topicId' and 'body'). While the purpose sentence implies their roles ('posts a comment on a Topic'), it lacks explicit details like format, length constraints, or examples. The description should compensate more given no schema descriptions.
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?
Clearly states the action ('posts a comment'), the resource ('Topic'), and explicitly frames it as the exclusive communication channel with the human, differentiating it from sibling tools like 'easytopic_transition_status' or 'easytopic_write_plan'.
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?
Describes the tool as 'the only channel to communicate with the human' and lists specific use cases (questions, progress notes, completion summaries), providing strong context for when to use it. The automatic notification detail reinforces its role. No explicit exclusions are needed given its exclusive framing.
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 exist, so the description carries the full burden. It details the output (title, HTML description, parentTopicId, isPublic, metaDescription, child pages). It does not mention side effects, but for a fetch operation this is acceptable. It could explicitly state it's read-only.
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, concise and front-loaded. The first sentence explains the action and output; the second advises on obtaining parameters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields. Parameter guidance covers obtaining inputs. It lacks information on error handling, pagination, or permissions, but for a simple get tool this is adequate.
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 0% (no descriptions on parameters). The description compensates by indicating where to get parameter values (from other tools), but it does not explain what the parameters represent (e.g., topicId is the page ID). This adds some value but still leaves ambiguity.
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 fetches one Documentation page (Topic) in full, listing the specific fields returned. The title reinforces the action. It distinguishes from siblings like easytopic_list_doc_tree (which lists tree structure) and easytopic_get_topic (likely a different concept).
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 how to obtain the required parameters (projectId from easytopic_list_doc_projects and topicId from easytopic_list_doc_tree). However, it does not explicitly state when not to use this tool or compare it to alternatives like easytopic_get_topic.
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 reveals versioning and history recording, which are important behavioral traits. It does not mention idempotency or side effects, but for a simple write operation it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Critical information is front-loaded, covering action, target, versioning, usage sequence, and distinction from sibling.
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 and no annotations, the description covers purpose, usage, and behavioral traits adequately. However, it lacks parameter descriptions, making it slightly incomplete for a 2-param 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 coverage is 0% and the description does not explain the two parameters (topicId, planHtml). It implies planHtml is the plan content but does not clarify format or that topicId identifies the topic. This is a significant gap.
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 action (writes implementation plan), the target (Topic's plan custom field), and key traits (versioned, recorded in Topic History). It distinguishes from sibling tools like easytopic_transition_status by naming the specific resource and action.
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?
Explicitly tells when to use ('before transitioning a Topic out of the todo status') and provides a sequence instruction ('write the plan first, then transition'). This clearly differentiates from easytopic_transition_status and gives direct usage context.
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?
Discloses partial update behavior ('Only fields you pass'), versioning for title/descriptionHtml, and that metaDescription is not versioned. Mentions auth requirement but no rate limits or idempotency. With no annotations, this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and scope. No redundant phrases. Every sentence 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?
Covers main behavior, versioning, and precondition. Missing return value information (no output schema, and description does not mention what is returned). Otherwise complete given complexity.
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?
Despite 0% schema description coverage, the description explains the three optional params (title, descriptionHtml, metaDescription) with versioning context. Required params (projectId, topicId) are not detailed but are self-explanatory.
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?
Clearly states verb 'Updates' and resource 'Documentation page', specifying which fields (title, descriptionHtml, metaDescription). Distinguishes from sibling 'easytopic_create_doc_page' as an update operation.
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?
Provides precondition (bot must be project participant) and references sibling for checking participation. Implies use case via 'Updates', but lacks explicit when-not or alternatives.
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?
Despite no annotations, the description fully discloses what the tool returns (title, description, custom fields, status, transitions, comments, awaitingHumanReply) and provides important behavioral guidance: 'do not re-ask, wait for a reply' when awaitingHumanReply is true.
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 main action and enumerates the returned fields concisely. No redundant 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?
Given the simple input schema (1 parameter) and no output schema, the description provides a thorough enumeration of return fields and behavioral context, making it complete for an agent to understand and use the tool effectively.
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 has 0% description coverage, and the description does not explicitly elaborate on the 'topicId' parameter. However, the parameter name and tool purpose make it obvious that this is the topic identifier, so the lack of additional detail is acceptable but not exceptional.
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 fetches one Topic in full, listing the specific fields (title, description, etc.). This distinguishes it from siblings like easytopic_list_topics which presumably lists multiple topics.
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 this is for retrieving detailed information on a single topic ('Fetches one Topic in full'), but does not explicitly indicate when to use it over siblings or provide exclusions. Still, the purpose is clear enough for an agent.
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 carries full burden. It discloses that the tool runs the same beforeChecks as the human UI (e.g., requiredFieldsFilled), lists possible error types (WorkflowCheckId, notProjectAdmin, etc.), and explains the status lifecycle convention.
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 well-structured, starting with the action, then error vocabulary, then lifecycle rules. It is detailed but not overly verbose; every sentence 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?
Comprehensive for a transition tool: explains constraints, error vocabulary, and status conventions. However, it does not describe the return value (e.g., success message or updated topic), which is a minor gap given no output schema.
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 0%, and the description adds meaning for topicId and toStatusKey (the topic and target status) but does not describe the optional 'comment' parameter. This leaves some semantic gap.
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 moves a Topic to a new status via a Workflow transition, explicitly distinguishing it from sibling tools like easytopic_list_topics or easytopic_add_comment. It specifies the action, resource, and business logic.
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?
Provides explicit when-to-use and when-not-to-use guidance, including when the agent may set planning/planned/in_progress/done statuses, and strict prohibitions on setting approved (without human approval) and closed (never). This helps avoid misuse.
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 provided, so description carries full burden. Discloses Firestore rules requiring participancy and admin requirements for further operations. Lacks output format details but is otherwise transparent.
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 paragraph, front-loaded with core purpose, each sentence adds essential information without redundancy. Matches the input schema's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: filter condition, participancy, admin requirements. No output schema, so return structure is implied but not explicit. Adequate for a simple list 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?
Input schema has no parameters (100% coverage). Description adds value by explaining the implicit filter (isDocumentationProject true) and participancy condition 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 clearly defines the tool's purpose: listing Documentation Projects where Project.isDocumentationProject === true that the bot participates in. It distinguishes from sibling tools like easytopic_list_doc_tree and easytopic_get_doc_page.
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?
Explicitly states when to use (list projects) and when not (bot must be added as participant, not just employee). Also provides guidance for related actions requiring admin role, referencing CLAUDE.md.
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?
Describes authentication and return of settings; implies idempotent health check. No mention of side effects or rate limits, but sufficient for 0-param tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then critical usage directive. No waste.
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?
Complete for a 0-param auth tool: explains what it does, when to use, and error handling. No output schema needed.
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; schema coverage 100%. Description adds no parameter info but none needed; baseline 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?
Clearly states authenticates and returns identity plus configuration settings. Distinct from siblings which are data operations.
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?
Explicitly instructs 'Call this first in every run' and specifies error handling: stop immediately if it errors, no workarounds.
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 provided; description discloses flattening, ordering, returned fields, and that only visible pages are included. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First covers purpose and output, second provides prerequisite guidance.
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, description adequately explains output fields and ordering. Sufficient for agent to use 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?
Single parameter projectId: schema has 0% coverage, but description explains how to obtain it from another tool, adding context beyond parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists every page in a documentation project, flattened and ordered. It distinguishes from sibling tools like easytopic_get_doc_page (content retrieval) and easytopic_list_doc_projects (project list).
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?
Explicitly tells when to use this vs easytopic_get_doc_page for content, and how to get projectId from easytopic_list_doc_projects. Also explains tree reconstruction using parentTopicId.
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:

[![easytopic-mcp-server MCP server](https://glama.ai/mcp/servers/EB-CON-GmbH/easytopic-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/EB-CON-GmbH/easytopic-mcp-server)

Score Badge

Copy to your README.md:

[![easytopic-mcp-server MCP server](https://glama.ai/mcp/servers/EB-CON-GmbH/easytopic-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/EB-CON-GmbH/easytopic-mcp-server)

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/EB-CON-GmbH/easytopic-mcp-server'

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