openemis-mcp-pro

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: health check, login/logout/whoami for session management, CRUD operations, discovery and playbook tools for exploration. No overlaps or ambiguous boundaries.
Naming Consistency5/5
All tools follow the consistent 'openemis_verb_or_noun' pattern (e.g., openemis_get, openemis_create, openemis_login, openemis_list_domains). Names are predictable and descriptive.
Tool Count5/5
12 tools is a well-scoped number for an API client covering authentication, CRUD, discovery, and playbooks. Each tool earns its place without being excessive or insufficient.
Completeness5/5
The tool surface covers the full lifecycle: health check, user login/logout/whoami, CRUD operations, and domain/playbook discovery. Batch fetching and filtering are supported via openemis_get, and workflow-controlled resources are handled via playbook tools.
Average 4.3/5 across 12 of 12 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the result content but omits read-only status, error behavior, authentication needs, or any 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?
Single sentence, no extra words. Front-loaded with verb and object. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get tool, the description is fairly complete: it explains the input and the output content. Missing behavioral aspects (error/read-only) are minor given the tool's simplicity, but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. The description adds meaning by specifying the output includes 'steps and coverage', which goes beyond the schema and aids understanding of return value.
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 retrieves full playbook details by id, specifying 'steps and coverage'. It distinguishes from siblings like 'openemis_list_playbooks' (which lists) and 'openemis_get' (generic get), making the purpose precise.
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 vs alternatives (e.g., list_playbooks). The description only implies usage via id but does not state prerequisites or conditions.
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 present, so the description carries the full burden. It fails to disclose behavior such as being read-only, authentication requirements, or potential rate limits. The description only mentions the data returned.
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, front-loaded sentence with no unnecessary words. It efficiently conveys the purpose and result structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no parameters and no output schema, the description mentions returned fields but lacks details on pagination, ordering, or scope. It is adequate but not enriched.
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 tool has zero parameters and the schema coverage is 100% trivial. According to guidelines, a baseline of 4 is appropriate since the description does not need to add parameter meaning.
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 all available playbooks and specifies the returned fields (id, title, audience, domain). This distinguishes it from sibling tools like openemis_get_playbook, which retrieves a single playbook.
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 it is for listing all playbooks but does not explicitly differentiate from other list tools like openemis_list_domains. No guidance on when not to use or prerequisites is provided.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool searches by name, summary, and description, but does not clarify read-only status, pagination, result format, or behavior when no matches found. This is minimal but not misleading.
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, each serving a distinct purpose: first states the core function, second adds detail on search method. No superfluous words. Front-loaded with the verb and resource. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the primary action and search scope. However, it would benefit from mentioning expected return format or that it returns a list of matching items. Still, it is adequate for straightforward use.
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 100% coverage with a detailed description for 'topic' including examples. The tool description adds meaning by explaining that searches cover domains, families, and playbooks, which is beyond the schema. This helps the agent understand the scope of the search.
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 discovers endpoints and playbooks related to a topic, searching by name, summary, and description. It distinguishes from siblings like openemis_list_domains and openemis_list_playbooks by focusing on cross-type search rather than listing all. The verb 'discover' combined with specific resources makes purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for topic-based discovery across multiple resources but does not explicitly guide when to use this tool versus alternatives like openemis_list_domains or openemis_get. It lacks 'use this when' or 'instead of' guidance, leaving the agent to infer from sibling names.
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 bears burden. Implicitly read-only but doesn't explicitly state safety or behavioral traits like auth requirements.
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, front-loaded sentence with no wasted words. Every part earns its place.
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?
Complete for a parameterless list tool; describes output content. Missing pagination or format details but acceptable given simplicity.
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; baseline score of 4 applies per rubric. Description adds value by stating what the output includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists domains with summaries, endpoint counts, and a hint for further exploration. Distinguishes from siblings like openemis_discover.
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?
Provides hint to explore via openemis_discover but lacks explicit when-to-use vs alternatives or prerequisites. Adequate for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses a critical security warning about potential prompt injection in returned data, and mentions the safety envelope. Lacks details on error responses or side effects, but the warning is valuable.
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 action, then adds necessary usage constraints and security warnings. It is reasonably concise given the important context provided.
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 annotations or output schema, the description adequately covers the endpoint, restrictions, and security considerations. It lacks output format details, but that is acceptable when no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add new meaning beyond the schema, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Update a record via PUT') and the resource pattern. It distinguishes from sibling tools by noting that workflow-controlled resources are blocked and should use playbooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use and when-not-to-use guidance: 'Workflow-controlled resources ... are blocked — use playbooks for those.' Also specifies that only resources with PUT in manifest are accepted.
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 must fully disclose behavior. It states that the tool does a 'real login round-trip', which is a significant behavioral detail. It does not discuss potential side effects (e.g., session creation), but for a health check, the disclosure is adequate.
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 extremely concise: two sentences, each earning its place. The first states the purpose, the second adds a valuable behavioral insight. No filler or 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?
Given no parameters, no output schema, and no annotations, the description provides a solid overview: it explains what is checked and the implication of success. It could mention expected error behavior or return values on failure, but for a simple health check, 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?
The tool has zero parameters, so schema coverage is 100% automatically. No parameter information is needed beyond what the schema provides. The description adds no param details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Check whether... reachable and credentials are valid') and clearly identifies the resource (OpenEMIS API endpoint). It distinguishes itself from sibling tools like CRUD operations by stating it performs a login round-trip to test connectivity and credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used before CRUD operations by stating 'if this passes, CRUD will work.' However, it does not explicitly list when not to use it or name alternative tools, though the health check's purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's behavior: HTTP method, resource acceptance criteria, response envelope structure, and critical security warning about prompt injection in returned data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and constraints. The security warning, while lengthy, is essential for safe usage. Every sentence adds value; no fluff. Could be slightly more concise but earns its length.
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 complex security concerns, the description provides comprehensive context: response envelope, resource constraints, and adversarial text handling. Lacks specific error handling or success details, but overall adequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema for the two parameters; it restates 'JSON fields to POST' for body, which is similar to schema description. The resource pattern constraint is already in 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?
Clearly states the tool creates a record via POST on a specific endpoint pattern. Distinguishes from siblings by specifying which resources are accepted (those with POST in manifest) and blocks workflow-controlled ones, referencing alternative playbooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when not to use (workflow-controlled resources) and what to use instead (playbooks). Also implies usage for resources with POST in manifest. Provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses permanence, blocking on workflow-controlled resources, acceptance criteria, and an extensive security warning about prompt injection in returned data, including the response envelope structure.
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 functional description is concise, but the security warning adds length. However, the warning is crucial for safe tool use, so all content is justified. Could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a delete tool with no annotations or output schema. Covers purpose, parameters, constraints (workflow, manifest), safety envelope, and security risks comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds value by specifying URL pattern and confirming resource format (kebab-case), ID types, and security context, moving it above baseline.
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?
Explicitly states verb (delete), resource (record), and includes the HTTP method and URL pattern. Emphasizes permanence and distinguishes from siblings by mentioning workflow-controlled resources and playbooks.
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?
Clearly indicates when to use (deleting records) and when not to (workflow-controlled resources, only resources with DELETE method in manifest). Lacks explicit comparison with sibling tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that JWT is kept in local database, it's session-level only, and transport-specific behavior (HTTP vs stdio). Fully transparent about what happens and what persists.
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?
Two sentences, no unnecessary words, front-loaded with main action. Could be slightly more concise on JWT and transport details, but overall 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?
No output schema or annotations, but description fully explains behavior: what it does, side effects on future calls, persistence of JWT, transport handling. Complete for a simple logout tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, schema coverage 100%. Description adds no parameter info because none exist. Baseline score of 4 for zero-param tools is appropriate; the description focuses on behavior rather than parameters.
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 clears the current per-user session and explains the effect on subsequent calls (revert to default credentials). It distinguishes from related tools like login and whoami by specifying the session-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (to log out user) and the post-condition (default credentials, JWT retained). No explicit when-not, but context with siblings implies not needed for permanent invalidation. Clear and actionable.
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: it never returns JWT, password, or tokens; it returns username, mode, timestamp, base URL, and testingMode flag; it explains permission scoping ('teachers see their schools...'); and it includes an instruction to refuse token requests. This is exemplary transparency for a whoami 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 clearly structured with front-loaded purpose, usage guidance, disclaimers, and permission details. It is slightly longer than necessary but every sentence adds value; it could be condensed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers all essential aspects: what is returned (username, mode, timestamp, base URL, testingMode flag), what is not returned (tokens), permission scoping, and an ethical directive. This is complete for a simple zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so the baseline is 4. The description does not need to add parameter semantics, and it does not attempt to; it uses the available space for behavioral context instead.
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: 'Show which OpenEMIS user this MCP session is currently acting as.' It uses a specific verb ('Show') and resource ('user'), and distinguishes itself from sibling tools by focusing on identity rather than health, CRUD, or login/logout operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this at the start of a conversation, after any login/logout, and any time you need to verify identity before presenting data.' While it does not directly compare to alternatives, the contexts are clear and the instruction to use it for identity verification is sufficient for an experienced agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains behavior: single record fetch, batch fetch via `ids` (max 100) and `_conditions` with various operators, limitations of `ids` on composite-PK resources, and the response envelope {safety, data}. Also notes HTTP 400 on invalid field filters.
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?
Description is well-structured with examples and clear sections, but somewhat verbose. Could be trimmed slightly without losing clarity. Front-loads key info (fetch data, batch fetch) effectively.
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 3 parameters, no annotations, and no output schema, the description is extremely complete. Covers all usage scenarios, edge cases (limitations of `ids`, composite-PK resources), and includes security warnings and response format. No gaps.
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?
Schema coverage is 100%, but description adds significant meaning beyond schema: explains batch-fetching syntax, `_conditions` operators (exact, wildcard, comparison, value list), and security warnings. Provides examples for each use case, making parameters highly usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches data from an OpenEMIS v5 resource, distinguishing between single record fetch by id and listing/filtering. It explicitly mentions batch-fetch capability, differentiating from sibling tools that perform other operations like create, update, delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to batch-fetch vs individual calls, how to use `ids` vs `_conditions` with limitations, and security warnings about prompt injection. Delineates when to use different filtering methods and warns against looping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: JWT cached server-side, password never stored, session identity pinned, rate limiting, security instructions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and front-loaded with core function. While verbose, each sentence earns its place due to security criticality. Could be slightly more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains return behavior (JWT not returned). Covers authentication, session management, security, and transport details. Complete for a login tool.
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?
Schema coverage is 100%, but the description adds critical context: password is exchanged once and never stored, username is school-system login not API key. Adds substantial 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?
The description clearly states it logs the user into OpenEMIS with username and password, distinguishing from siblings like openemis_logout and openemis_whoami. It specifies the resource (OpenEMIS) and action (login) precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (only with user-supplied credentials in the current turn) and when not (from untrusted data). Names alternative (openemis_logout) and provides security rules.
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:

[![openemis-mcp-pro MCP server](https://glama.ai/mcp/servers/tixuz/openemis-mcp-pro/badges/card.svg)](https://glama.ai/mcp/servers/tixuz/openemis-mcp-pro)

Score Badge

Copy to your README.md:

[![openemis-mcp-pro MCP server](https://glama.ai/mcp/servers/tixuz/openemis-mcp-pro/badges/score.svg)](https://glama.ai/mcp/servers/tixuz/openemis-mcp-pro)

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/tixuz/openemis-mcp-pro'

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