senegal-mohebs-tlm-server

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool has a clearly distinct purpose. For example, set_context and get_context handle context, get_curriculum and get_generation_context are different in scope, and create_upload_url, create_download_url, get_document_text, record_document_content, log_generation each cover distinct steps in document management. No two tools appear to do the same thing.
Naming Consistency4/5
Most tool names follow a verb_noun pattern (e.g., get_prompt, list_units, create_upload_url). The main exception is 'terminology_sections', which uses noun_verb. Overall, the naming is mostly consistent with minor deviations.
Tool Count4/5
17 tools is slightly above the typical ideal range of 3-15, but each tool serves a specific function in a multi-step generation workflow. The count is justified by the complexity of the domain and does not feel excessive.
Completeness4/5
The tool surface covers the full lifecycle: context setting, curriculum access, terminology, prompt retrieval, domain rotation, document management (upload, download, read, record, log), and reconciliation. Minor gaps exist, such as no explicit tool to list deliverables or delete documents, but these are manageable.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 182 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only cryptically mentions 'canonical entry' and 'known content'. It does not clarify if the tool is read-only, requires authentication, or any other traits.
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 concise (one sentence) but lacks structure and clarity. It is not front-loaded with key information, making it less useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to adequately explain the return value or behavior. Terms like 'canonical entry' and 'known content' are ambiguous, leaving the agent uncertain.
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 no parameters (0 parameters, 100% coverage). The description adds no parameter information, but its minimal nature does not detract from parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: 'Current history: one canonical entry per document, with its known content' does not clearly state that the tool lists tracked documents. The title provides some clarity, but the description fails to explicitly state the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_document_text' or 'record_document_content'. Context and exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions what is loaded but omits details on side effects, permissions, rate limits, or idempotency. Behavioral traits are insufficiently disclosed.
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 a single dense sentence that packs examples and clarifications. It is somewhat concise but could be split for readability. Some redundancy exists with parentheticals.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided. The description only gives vague return content (curriculum, context) with maths-specific examples. It fails to describe the full structure or behavior for other subjects, leaving significant gaps.
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?
With 0% schema description coverage, the description adds valuable meaning: it explains 'unit' as scope (e.g., chapter number) and 'deliverable' as key (e.g., 'manual' or 'lessons' for maths). This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads curriculum and subject-specific context for generation. It uses specific verbs and resources, and the examples help distinguish from siblings like get_curriculum or suggest_fresh_domain.
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 implies usage 'before generating' but does not explicitly state when to use this tool versus alternatives like get_curriculum or get_context. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full burden. It discloses that numbering may skip, but lacks important behavioral details such as idempotency, error states (e.g., no active subject), or return format beyond a brief example.
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?
Extremely concise: two sentences cover the core purpose and a key behavioral note (numbering may skip). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple zero-parameter list tool, but missing context such as error handling, return structure, or relationship to other curriculum tools. Lacks completeness without an output schema.
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 defined, so baseline score is 4. The description adds no parameter info because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists top-level curriculum units for the active subject, with a concrete example (maths chapters) showing the returned fields. However, it does not explicitly differentiate from sibling tools like 'get_curriculum' or 'list_documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of context like requiring an active subject.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'maths-specific' and 'example-domain rotation' but does not disclose whether the operation is read-only, side effects, authorization needs, or rate limits. Minimal behavioral context beyond the core function.
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 the purpose. Every word earns its place. No redundancy.
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 parameterless query tool with no output schema, the description sufficiently conveys what the tool returns and its scope. Could be slightly more specific about the data coverage (e.g., all users vs. current), but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% trivially. The description adds value by explaining the output context (domains used and chapters, maths-specific), which is meaningful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reports which example domains have been used and in which chapters, with a specific maths scope. However, it does not explicitly differentiate from siblings like get_curriculum or suggest_fresh_domain, though context signals partially compensate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool versus alternatives. The description implies it is for querying domain usage, but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes output categories but does not indicate whether the tool is read-only, modifies state, or has side effects. The term 'reconcile' may imply actions beyond listing, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys significant detail, but it is somewhat dense and could benefit from structuring as a list for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description provides moderate completeness by listing output categories. However, it lacks details on return format, error handling, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds meaning by explaining the output categories, which is valuable beyond the empty 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 lists documents in Firebase Storage and diffs against history, enumerating specific output categories: tracked docs, untracked docs needing ingestion, dropped entries, and duplicate resolutions. This distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reconciliation tasks but does not explicitly state when to use this tool over alternatives, nor does it provide context for prerequisites or exclusion conditions.
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 provided, so description carries full burden. It mentions returning an unused or least-recently-used domain, indicating a read-like operation. However, it doesn't disclose any side effects, permissions, or response format, leaving some gaps.
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, concise and to the point. However, the second sentence is a bit cryptic; could be structured more clearly. No wasted words, but front-loading could be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides adequate context for its simple purpose. It explains the domain rotation context (Maths-specific) and the selection criterion (unused or least-recently-used), which is sufficient.
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, so schema coverage is 100%. The description adds meaning by specifying 'unused or least-recently-used' and 'Maths-specific rotation', which clarifies what the tool returns beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'suggest' and resource 'fresh domain', with clear purpose of rotating object families for chapters. It differentiates from siblings like 'domain_usage' by specifying 'Maths-specific (example-domain rotation)', but the phrasing could be less ambiguous.
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?
Implied usage is for getting a domain for chapter rotation, but no explicit when-not or alternatives. Sibling 'domain_usage' might serve a different purpose, but the description doesn't clarify when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the structure of the returned data for maths but does not mention side effects, permissions, or global behavior. The agent is informed of what the tool returns but not of any potential restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. 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?
Given one required integer parameter and no output schema, the description provides sufficient context about what the tool returns for maths. However, it could be more general or mention behavior for other subjects if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'unit' is explained: it's the unit's scope value (maths chapter number). This adds meaning beyond the schema, which only specifies integer type. Schema description coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the curriculum slice for one unit, specifying the content for maths (ordered lessons, components, tasks, bilan lesson, cross-unit progression). It distinguishes from sibling tools like get_context or get_terminology, but could be more explicit about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when needing curriculum details for a specific unit, but it does not explicitly state when not to use it or provide alternatives. No exclusions or context for other subjects are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the return value (prompt) without addressing error cases, authentication needs, or whether the operation is read-only. This is minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second explains the parameter. No redundant information, front-loaded with key action.
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 one parameter and no output schema, the description covers the main functionality but omits the return format (e.g., string vs object) and assumes context like 'active subject' without explanation. Adequate but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage and no description for the 'deliverable' parameter. The description adds value by explaining it is a deliverable key and providing examples for maths. However, it only covers one subject, leaving other cases ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the generation prompt for a deliverable, with specific examples for maths ('manual' or 'lessons'). This distinguishes it from sibling tools like get_generation_context or get_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the deliverable parameter and giving examples, but it does not explicitly state when to use this tool versus alternatives, nor mention prerequisites like having an active subject.
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 stand alone. The term 'list' implies a read-only operation, but no additional behavioral traits (e.g., scope, performance, caching) are disclosed. This is adequate for a simple tool with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without any wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is largely complete. It could optionally mention ordering or pagination, but for a simple listing tool, this is sufficient. The lack of annotations does not create a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description does not need to add parameter details. However, it clarifies that the tool returns a full list of sections with counts, adding meaning beyond the empty schema. Baseline for 0 parameters with high coverage is 4.
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: to list terminology sections along with entry counts. The verb 'list' and the resource 'terminology sections' are specific, and the inclusion of 'entry counts' further clarifies the output. This distinguishes it from siblings like 'get_terminology'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_terminology' or 'list_units'. There is no mention of prerequisites, contexts, or situations where other tools would be preferred.
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 the tool is a search that returns an empty array on no match, implying read-only and safe behavior. However, it does not confirm lack of side effects or authorization needs, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. It is front-loaded with the core purpose and immediately useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema), the description covers the use case and return behavior. However, it lacks parameter semantics, which is a gap that affects completeness.
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 has 2 parameters (query, limit) with 0% description coverage. The description does not mention any parameters, forcing the agent to rely solely on the schema for meaning. This is insufficient for correct parameter usage.
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 searches the MOHEBS French/Wolof terminology, specifying it is a fallback when the knowledge graph lacks a term. This distinguishes it from primary term searching tools and aligns with its name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: as a fallback when the KG lacks term wording. It also instructs the agent to say the wording is missing if the result is empty, preventing hallucination. This is clear usage guidance.
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 clearly indicates a read-only operation (extract plain text) and adds a behavioral nuance about reading the entire document for characters. No destructive behavior or contradictions are present, though it lacks detail on authentication or rate limits.
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 with no unnecessary words. The first sentence states the primary purpose and context, and the second provides a critical behavioral guideline. 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?
Given no output schema and no annotations, the description covers the main aspects: what it does, when to use it, and a behavioral nuance. It does not explicitly state the output format (likely plain text), but that is reasonably inferred from 'extract plain text'.
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 0%, so the description must compensate. It adds the qualifier 'documents-relative path' for the relPath parameter, which provides some context beyond the schema. However, it does not specify the expected format (e.g., leading slash, file extension) or give an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (extract/read) and resource (document text) and specifies the context (UNTRACKED document). It distinguishes from siblings like record_document_content by implying this is the read step before recording. The additional detail about reading the whole document for character identification further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: read an untracked document and then record its content. It also gives a specific guideline about reading the whole document for character identification. However, it does not explicitly mention when not to use this tool or list alternative tools.
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 reveals key behaviors: selecting which local sources load and which Firebase namespace documents/history live under. It also notes the ordering constraint. Could be improved by mentioning if previous context is overwritten or if any loading occurs immediately, but still strong.
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?
Three sentences, each adding distinct value: purpose, importance, and fallback. 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 and no annotations, the description covers the core aspects: what it sets, why it's necessary, and how to handle uncertainty. It lacks explicit details on parameter formats and exact side effects, but overall sufficient for a configuration tool.
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 0%, so description must compensate. It provides examples ('ci' for grade, 'maths' for subject) and directs users to 'get_context' for valid options. However, it does not specify allowed values or format, leaving some 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 that the tool sets the grade and subject context. It uses specific verb 'choose' and resource 'grade and subject'. It distinguishes from sibling tool 'get_context' by directing users to call it for available options.
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 'MUST be set before any other tool', providing critical ordering guidance. Also advises to use 'get_context' and ask the user when uncertain, giving clear context-aware instruction.
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, but description discloses behavior: returns current selection (null if none) and all options. Good transparency for a simple getter, though could explicitly state no 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, front-loaded with purpose, no wasted 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?
Explains return value (current selection and options) but lacks detail on output format (e.g., data structure). Enough for a simple getter given good complementary siblings.
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%), baseline is 4. Description adds no parameter info, but none needed; the tool takes no input.
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 'Return the currently selected grade/subject and every installed grade/subject option.' It specifies verb 'return' and resource 'grade/subject options', and distinguishes from sibling 'set_context' by naming it.
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 says 'Use this to discover what's available, then set_context.' Provides clear when-to-use guidance and implies alternatives (avoid if context already known).
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 transparency burden. It reveals that the tool reads the object's hash from storage, records data, and requires a confirmation step (without confirm:true it returns a notice). It could mention more about side effects or errors, but it's quite transparent for a logging 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 front-loaded with the core purpose and workflow. It is concise but includes necessary details like the confirmation flow and character logging requirements. Slightly dense, but 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?
Given the tool's complexity (5 params, nested objects, confirmation flow), the description covers the workflow, parameter semantics, and behavioral notes. It explains the confirmation behavior and character requirements. It doesn't describe the return format, but the purpose is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that unit is a chapter number, deliverable is a key like 'manual', and characters must include every character found anywhere in the document with details like {name, type}. This compensates well for the schema's lack of 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?
The description clearly states it logs a generated document after upload, reads a hash from storage, and records the output for future consistency. It distinguishes this tool by specifying the post-upload context and the required parameters like unit, deliverable, and content details.
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?
It explicitly states when to use (after uploading via create_upload_url), provides a two-step confirmation flow, and explains the meaning of unit and deliverable with examples. This gives clear invocation guidance and disambiguates from other tools.
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 provided, the description carries the full burden. It discloses the confirmation requirement, the precondition that the object must be in the bucket, and the irreversible nature of writing to history ('never re-parsed'). It does not discuss idempotency or error handling, but covers key behavioral traits adequately.
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 concise at about 120 words, with clear sentence structure. It front-loads the purpose and then provides necessary details. Every sentence adds value, and there is no redundancy.
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?
The tool has 5 parameters (4 required, nested objects) and no output schema. The description explains the confirmation workflow, the bucket precondition, and the expected content structure. It does not describe return values or error states, but given the complexity and absence of output schema, it is mostly 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?
Given 0% schema description coverage, the description compensates by explaining the 'unit' (scope value, e.g., chapter number), 'deliverable' (e.g., 'manual' or 'lessons'), and the 'content' object's subfields (characters with required fields, exampleDomains, etc.). However, it does not explain 'relPath' or 'confirm' in detail, leaving some 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 tool's purpose: 'store the structured content you extracted into history so it is never re-parsed.' It specifies the verb 'store' and the resource 'structured content,' distinguishing it from read-only or logging tools. The inclusion of 'After reading an UNTRACKED document's text' provides context for when this tool should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: 'The object must already be in the bucket,' explains the 'unit' and 'deliverable' parameters with examples (maths), and details the confirmation workflow ('REQUIRES CONFIRMATION: called without confirm:true it only returns a needsConfirmation notice'). It also instructs on character inclusion: 'include every one found ANYWHERE in the document.' This is comprehensive and helps the agent use the tool correctly.
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 discloses behavioral traits: the URL is short-lived, signed, requires no auth header, works only for existing .docx, and returns a specific object with fields url, objectKey, expiresAt, exists. It also clarifies that exists is false when the object is missing.
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 four sentences, each serving a distinct purpose: function, path explanation, usage context, and return value. No redundant information, tightly packed with valuable details.
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 tool has one parameter, no output schema, and no annotations, the description covers all aspects: parameter semantics, return value structure, usage scenario, and even the path convention. It is complete and leaves no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description extensively explains the sole parameter relPath: 'documents-relative, like 'chapitre_05/Manuel - Chapitre 5.docx' — the same path used by create_upload_url and get_document_text'. This provides format, examples, and cross-reference, fully compensating for the missing 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 function: 'Get a short-lived signed URL to download an EXISTING .docx from the bucket with an HTTP GET'. It specifies the resource (existing .docx), action (download URL), and distinguishes from siblings like create_upload_url (upload) and get_document_text (text extraction).
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: 'Use this to fetch the original binary file ... so you can edit it and re-upload via create_upload_url'. It relates to siblings and gives context. However, it does not explicitly state when NOT to use it (e.g., for text extraction), though the sibling set and context imply it.
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?
Discloses key behaviors: short-lived URL, upload method, relPath example, two-step confirmation process. No annotations provided, but description compensates fully without 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?
Single paragraph, front-loaded with purpose, then usage instructions, then confirmation details. No waste. Efficient and clear.
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?
Covers all key aspects: purpose, parameters with examples, return values (notice or URL), follow-up step, upload method. No output schema needed as return is described. Complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains both parameters: relPath given with example, confirm effect explained (returns notice vs URL). Adds meaning beyond 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?
Specific verb 'get' and resource 'short-lived signed URL to upload a generated .docx' clearly stated. Distinguishes from siblings like create_download_url and log_generation by specifying upload context and follow-up step.
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?
Explicit when to use (after generating .docx) and follow-up (call log_generation). Provides upload instructions (HTTP PUT, Content-Type). Describes confirmation flow clearly. No explicit when-not-to-use but context is sufficient.
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:

[![tlm-authoring-mcp MCP server](https://glama.ai/mcp/servers/IDinsight/tlm-authoring-mcp/badges/card.svg)](https://glama.ai/mcp/servers/IDinsight/tlm-authoring-mcp)

Score Badge

Copy to your README.md:

[![tlm-authoring-mcp MCP server](https://glama.ai/mcp/servers/IDinsight/tlm-authoring-mcp/badges/score.svg)](https://glama.ai/mcp/servers/IDinsight/tlm-authoring-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IDinsight/tlm-authoring-mcp'

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