Read-only portfolio MCP: buzzword glossary (DE/EN), projects, career timeline, contact, docs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 13 of 13 tools scored.
Each tool targets a distinct resource and action (e.g., get vs list vs search for buzzwords, distinct tools for projects, YouTube playlists, etc.), with no overlapping purposes.
All tools follow a consistent verb_noun pattern with lowercase and underscores (e.g., list_buzzwords, get_project), and the verbs are limited to 'get', 'list', and 'search'.
13 tools is well within the ideal range for a portfolio server, covering all major content sections without unnecessary bloat.
The tools provide read access to all major sections of the portfolio (buzzwords, projects, docs, YouTube, contact, timeline, etc.), with list, get, and search operations where appropriate. No obvious gaps for a read-only portfolio.
get_buzzwordAInspectGet the full glossary entry (plain text) for one buzzword by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Buzzword id/slug, e.g. angular, typescript, git. | |
| lang | No | Language (default en). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions returning 'full glossary entry (plain text)'. This is adequate for a simple read operation, but lacks any mention of error cases, permissions, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the action and resource. Every word contributes to clarity; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool returning plain text, the description covers the main purpose. Could be more explicit about what 'full glossary entry' includes (e.g., definition, examples), but the output schema is absent and not required. Adequate for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds context by specifying 'plain text' and giving example IDs ('angular, typescript, git'), but this is marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'full glossary entry', and the method 'by its id'. It distinguishes from sibling tools like list_buzzwords (which returns multiple) and search_buzzwords (which searches by term).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have a specific buzzword ID, but does not provide explicit guidance on when to use alternative tools (e.g., list_buzzwords or search_buzzwords) or any prerequisites. No exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contactAInspectGet public contact details / vCard (name, email, phone, url, avatar, QR code).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits beyond the listed fields, such as whether it requires authentication, rate limits, or side effects. It only mentions 'public' details, implying no auth, but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff, clearly conveys the purpose. Every word is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return format. It lists fields but not structure or whether it returns a vCard file or object. Mention of vCard is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 parameters), so parameter semantics are trivially covered. Baseline for 0 params is 4, and the description adds no extra parameter info beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'public contact details / vCard', and lists specific fields (name, email, phone, etc.). It distinguishes itself from sibling tools like get_buzzword or get_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to alternatives or when not to use it. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_docsAInspectGet the LLM-friendly code documentation (Compodoc llm-md export) for one project of the monorepo. Can be large.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Which documentation set: index (overview), ui, website, change-me or shared. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Get' indicating a read operation and adds 'Can be large' as a size warning. This adequately discloses the non-destructive, potentially large nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely convey purpose and a caveat ('Can be large'), with no superfluous content. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at output format via 'LLM-friendly code documentation (Compodoc llm-md export)', implying Markdown. It lacks explicit output structure but is adequate for a simple retrieval tool with a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers all parameters (100%). The description adds meaningful context: 'LLM-friendly code documentation (Compodoc llm-md export)' and 'for one project of the monorepo', enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'LLM-friendly code documentation (Compodoc llm-md export) for one project of the monorepo'. It distinguishes from sibling tools like list_docs (lists documentation sets) and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving documentation for a specific project but does not explicitly state when to use it versus alternatives or provide exclusions. With multiple sibling get tools, some guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eposAInspectGet "The Chronicle of the Three Realms" — the epic retelling of the moja.work git history — as an ordered list of sections {anker, headline, url, text}. Optional anker returns a single section (e.g. intro, prologue, canto-01, epilogue).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language (default en). | |
| anker | No | Optional section anchor to fetch one part (e.g. intro, prologue, canto-01, epilogue). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description explains the return format (list of sections with fields) and optional filtering, providing sufficient behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the purpose, no unnecessary words. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough for a simple read tool with 2 parameters and 100% schema coverage. Could mention error cases, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining that anker returns a single section with examples, exceeding the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'The Chronicle of the Three Realms' as an ordered list of sections, distinguishing it from sibling tools like get_buzzword or get_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage: to get the epic retelling. It mentions optional anker for a single section, but does not explicitly state when to use this over siblings; however, the resource is unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectAInspectGet a project intro (plain text) plus its images by project id. Every image carries a full-size url and a thumb. imageMode is "gallery" for an ordinary series of photos, or "tiles" when the thumbnails are the pieces of one large picture — such a project returns the same full-size url for every tile on purpose.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project id, e.g. carrier, speedy, etrax, skull, sideboard, workbench. | |
| lang | No | Language (default en). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output structure (plain-text intro, images with full-size and thumb URLs) and the key semantic of imageMode (tiles purposefully repeat the same full-size URL). This adds meaningful beyond-schema context, though it doesn't mention permissions or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences that front-load the main purpose, then add necessary behavioral details. No word is wasted; the imageMode explanation earns its place by disclosing a non-obvious behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential input (project id), output (intro and image structure), and the special case (tile mode). It lacks a mention of language behavior or error handling, but those are minor gaps; the overall description is complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters (id and lang) with descriptions and examples. The description reinforces the role of id but adds no extra parameter-level information; lang is not mentioned at all. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and a precise resource ('project intro plus its images') keyed by project id, clearly distinguishing it from sibling tools like get_docs or get_epos. It also adds unique return-value characteristics (image URLs, thumbnails, imageMode) that make the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a project id and need intro/images, but it does not explicitly reference alternatives such as list_projects for discovering ids, nor does it state use cases to avoid. The guidance is clear but implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_referencesAInspectGet external design references (Behance projects) as {id, name, url, fields, cover}.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only mentions the return format without disclosing behavioral traits like authentication needs, rate limits, or side effects. 'Get' implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the verb and resource, with no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies the return fields but lacks broader context such as when references are used in the workflow, how they relate to other tools, or whether any prerequisites exist. Adequate for a simple tool but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. Baseline is 4 per rubric; no additional explanation needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'gets external design references (Behance projects)' and specifies the output fields, making the purpose unambiguous and distinct from sibling tools which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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; no context about prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timelineAInspectGet the professional career timeline / CV of Markus Lungwitz: the introduction of the timeline page as plain text, plus the stations with descriptions and keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language (default en). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does disclose that the introduction is 'plain text' and that stations include descriptions and keywords, which is useful. However, it does not explicitly state side effects, permissions, or response format beyond that. For a simple get operation the missing depth is moderate, but it could be more explicit about being 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then adds a brief breakdown of what is included. Every phrase earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description explains what the response cover (introduction, stations) and the format of the introduction. It could mention that the language parameter affects the content, but that is already clear from the schema. Overall it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'lang' with an enum and default, so technical meaning is covered. The description adds no additional context about the parameter (e.g., how language affects the output). Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('professional career timeline / CV of Markus Lungwitz'), clearly distinguishing this from sibling tools like get_project or get_references. It also describes the content returned (introduction, stations with descriptions and keywords), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: you call this to get the CV timeline. However, it provides no explicit comparison to alternatives or exclusions, such as 'use list_projects for projects' or 'for other people use ...'. Since the purpose itself is clear, it sits at 'implied usage' rather than 'no guidance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_youtube_playlistAInspectGet one YouTube playlist of the moja.work channel by id, including its videos with full descriptions {id, title, description, thumbnail, publishedAt, position}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Playlist id (starts with PL), e.g. from list_youtube_playlists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes returned data structure but lacks details on permissions, error conditions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the tool's simple functionality and output structure, though could mention limits or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter fully (id, starts with PL). Description adds minimal extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a single YouTube playlist by ID, including its videos with specific fields. Distinguishes from sibling list_youtube_playlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when retrieving a specific playlist by ID, but no explicit guidance on when not to use or alternative tools like list_youtube_playlists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_buzzwordsAInspectList all tech/tool buzzwords in the moja.work glossary as {id, label, category}. Optional category filter (e.g. framework, language, tooling, design, os).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output fields but does not mention rate limits, authentication, pagination, or ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, action verb first, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is mostly complete. It states purpose, filter, and output fields. No output schema exists, but description compensates by listing fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for category. The description adds value by providing example categories (framework, language, tooling, design, os) beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all tech/tool buzzwords' and specifies output format as {id, label, category}. This distinguishes it from sibling tools like get_buzzword (single item) and search_buzzwords (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage via an optional category filter with examples. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_buzzword for a single buzzword, search_buzzwords for full-text search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_docsAInspectList the auto-generated code documentation sets (Compodoc) for the moja-work monorepo, with their URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the action as listing (read-only) but does not explicitly state safety, permissions, or side effects. The behavior is implied but not fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no wasted words. Every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the key purpose and resource. Missing details like output format or pagination, but acceptable for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4; the description adds no further parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists auto-generated code documentation sets (Compodoc) for the specific moja-work monorepo, including URLs. This distinguishes it from sibling tools like get_docs (which retrieves a single doc) and list_buzzwords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all documentation sets but does not explicitly state when to use it versus alternatives like get_docs for specific docs. No when-not or alternative names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsAInspectList the DIY / design projects showcased on moja.work as {id, headline, intro}. Includes each project intro so no per-project follow-up call is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language (default en). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a read operation, but does not explicitly state side effects, authorization needs, or destructive behavior. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose and adds a value proposition. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is complete: it specifies returned fields and eliminates follow-up calls. Lacks pagination/ordering details, but those are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning to the lang parameter beyond the schema's enum and description. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists DIY/design projects, specifies returned fields (id, headline, intro), and highlights that the intro eliminates follow-up calls. It distinguishes from sibling tools like get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all projects with a benefit over get_project, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are named, though siblings are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_youtube_playlistsAInspectList the public YouTube playlists of the moja.work channel as {id, title, description, thumbnail, itemCount, publishedAt}.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description indicates it is a read operation (listing public playlists). However, it does not disclose any behavioral traits beyond that (e.g., rate limits, auth requirements, or empty list behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers what the tool does and what it returns. The output fields are explicitly listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline of 4. Schema coverage is 100% (empty schema fully described). Description adds no parameter info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists the public YouTube playlists of the moja.work channel and specifies the exact fields returned. Distinguishes from sibling 'get_youtube_playlist' by using 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_youtube_playlist'. Implies listing all playlists but does not explicitly recommend it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_buzzwordsAInspectFull-text search across the buzzword glossary; returns matching entries with a snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language (default en). | |
| query | Yes | Search term. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions 'returns matching entries with a snippet', but lacks details on case sensitivity, fuzzy search, pagination, or read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose and output. Front-loaded with key info; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should specify return structure more precisely. Vague on result details (e.g., pagination, max results, ordering). Incomplete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. Description adds context about full-text search and snippet but does not enhance parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Full-text search', resource 'buzzword glossary', and output 'returns matching entries with a snippet'. Distinguishes from siblings like list_buzzwords and get_buzzword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for searching glossary, but no explicit when-not-to-use or alternative tools mentioned. Sibling tools like list_buzzwords could be alternatives for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!