E-Nabız MCP

by UmutKDev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, targeting specific health record types or actions (e.g., listing vs. getting details for lab, radiology, prescriptions). No two tools are ambiguous; even similar tools like enabiz_list_prescriptions and enabiz_list_medications differ in scope (prescriptions vs. individual medication usage).
Naming Consistency5/5
All tools follow a consistent 'enabiz_verb_noun' pattern using snake_case. Verbs like 'list_', 'get_', 'download_', 'login_', and 'session_' are used uniformly. The only slight deviation is 'enabiz_download_document' using 'download' instead of 'get', but this is justified as it downloads a file rather than returning data.
Tool Count4/5
32 tools is on the higher end but appropriate for a comprehensive healthcare portal covering numerous data types (e.g., diagnoses, medications, lab, radiology, allergies, etc.). The count is not overwhelming given the domain's breadth; each tool serves a specific, non-redundant function.
Completeness4/5
The server provides comprehensive read-only access to nearly all health record categories (e.g., diagnoses, medications, lab, radiology, vaccinations, allergies, reports). Minor gaps include no update/create capabilities and no cross-document search, but these are expected for a patient-facing MCP focused on data retrieval.
Average 4.6/5 across 32 of 32 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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 failing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, it describes the returned fields (date, drug name, dose, etc.) and the auth requirement. No contradictions with annotations.
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 concise, with a clear first sentence stating purpose, followed by parameter source, return fields, and auth note. Minimal wasted words.
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's simplicity (one parameter, output schema exists), the description covers all necessary aspects: source of barcode, return fields, and authentication. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for barcode, but the description compensates by indicating it comes from enabiz_list_medications. However, it does not specify format constraints or examples.
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 it returns the usage history of a drug given a barcode, distinguishing it from sibling tools like enabiz_list_medications which list available drugs.
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 mentions the barcode should be obtained from enabiz_list_medications and that an authenticated session is required, providing clear context for usage. However, it does not explicitly state when not to use this 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?
Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral details: requires authentication, returns auth_required error, truncation flag, default year range, and return fields. 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 concise with bullet points for readability. Each sentence adds value, though slightly verbose with code-style formatting. Could be streamlined but effective.
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?
Description covers parameters, defaults, error handling, truncation, return fields, and auth requirement. With output schema present, it is mostly complete. Minor gap: no mention of pagination beyond limit and truncation.
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 0%, so description fully compensates. It explains each parameter: start_year/end_year defaults, query case-insensitive filter, limit max records and default. Adds meaning beyond schema types.
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 discharge summaries (epikrizler) by year range, with a specific verb and resource. It distinguishes from sibling tools by specifying the unique resource type (taburcu özetleri).
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 listing discharge summaries but does not explicitly state when to use this over alternatives like other list tools. It provides context (requires authenticated session) but no exclusions or comparisons.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's behavioral contribution is limited to stating the need for an authenticated session. It does not disclose traits like error handling, invalid IDs, or response format variations. The description adds some value but not rich beyond what annotations provide.
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: first states the purpose, second provides parameter source and auth requirement. No wasted words, front-loaded with the primary action. Excellent conciseness.
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 presence of an output schema and annotations (readOnlyHint, openWorldHint), the description covers purpose, parameter semantics, prerequisite tool, and authentication need. This is sufficient for a simple retrieval tool with two parameters. No 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 compensates by explaining that sys_takip_no and prescription_no are taken from enabiz_list_prescriptions output, adding meaning beyond the parameter names. It does not specify formats or constraints, but the contextual relationship is valuable.
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 drug details of a prescription, specifying the resource (prescription) and the type of details (drug). It also links to the sibling tool enabiz_list_prescriptions for obtaining the required parameters, effectively distinguishing this tool from the list tool.
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 explicitly mentions that the parameters sys_takip_no and prescription_no come from the output of enabiz_list_prescriptions, and requires an authenticated session. This provides clear context for usage, though it does not list exclusions or alternatives beyond the implicit reference to the 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?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the tool returns specific lists (diagnoses, procedures) and requires an authenticated session, resulting in an auth_required error otherwise. This provides useful behavioral context beyond annotations.
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 concise, with a clear first line and additional details in separate sentences. It avoids unnecessary verbosity but could be more structured (e.g., using bullet points). Overall efficient for its content.
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 that an output schema exists (context signal), the description does not need to detail return format but still provides a high-level list of returned fields. It also covers authentication requirements. Adequate for the tool's 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?
Schema description coverage is 0%, so the description must compensate. It explains that detail_ref is an opaque reference from the output of enabiz_list_hospital_visits, providing essential semantic context for the single parameter.
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 details of a hospital visit including diagnoses and procedures, using a specific verb 'döndürür' (returns) and resource 'hastane ziyaretinin detayı'. It distinguishes itself from siblings like enabiz_get_diagnosis_detail by focusing on the full visit context.
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 explicitly notes that the detail_ref comes from enabiz_list_hospital_visits, guiding proper sequencing. It also mentions authentication is required, implying usage context. However, it does not explicitly state when not to use this tool versus alternatives, but the context is clear enough.
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?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that leaflet text may be truncated at LEAFLET_TEXT_LIMIT and requires authenticated session, else returns auth_required error. No contradiction.
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 concise sentences front-loading purpose, followed by parameter source, behavior, and auth requirement. 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 output schema exists, the description covers input source, truncation, and auth. It is sufficiently complete for a leaflet retrieval tool, though could mention language scope.
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 explains that barcode and ilac_name are taken from enabiz_list_medications output fields, adding meaningful context to otherwise bare 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 returns the leaflet text of a drug, specifying the resource and action. It distinguishes itself from siblings like enabiz_get_drug_usage_history by focusing on leaflets.
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 tells when to use the tool and explicitly states that input parameters should come from enabiz_list_medications output. It lacks explicit when-not-to-use but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, and the description adds that each data point includes date, result, unit, and reference value. It also specifies that authentication is required and the error if missing. This goes beyond the annotations.
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 four lines long, concise, and front-loaded with the main purpose. It includes necessary details without excess. Slightly more structured formatting could improve readability.
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 output schema exists (not shown but noted), the description covers return content (date, result, unit, reference value) and authentication needs. It is complete for a straightforward data retrieval tool with sibling context.
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 input schema has one parameter with no description or enums (0% coverage). The description explains that the value should be the trend_code from the output of enabiz_list_lab_tests, distinguishing it from the display name. This adds critical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the trend of a lab test over time ("Bir tahlil testinin zaman içindeki trendini döndürür"), specifying both the resource (lab test trend) and action (retrieve past measurements). It is distinct from sibling tools like enabiz_list_lab_tests which list tests.
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 how to derive the parameter value from another tool's output ("islem_tipi = enabiz_list_lab_tests çıktısındaki bir sonucun trend_code alanı") and warns about the difference between display name and trend_code. It also notes authentication requirements and the error response. However, it does not explicitly state when not to use the 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?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the tool returns plain text and requires an authenticated session, providing useful context beyond the 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 concise with three short sentences. It front-loads the core purpose and provides essential context without any redundant information.
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 tool with one parameter and an output schema, the description adequately covers purpose, parameter source, and authentication. It does not address error conditions or precise return format, but these are minor gaps given the tool's 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?
The input schema provides no description for order_id (0% coverage). The description clarifies that order_id comes from the output of enabiz_list_radiology_studies, adding necessary semantics absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a radiology report as plain text. It distinguishes itself from siblings like enabiz_get_radiology_image_link (returns image link) and enabiz_list_radiology_studies (lists studies).
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 where to obtain the required order_id (from enabiz_list_radiology_studies output) and that authentication is needed. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: partial failure handling (per-field error objects) and authentication requirement. No contradiction with readOnlyHint or openWorldHint.
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 (4 sentences) and well-structured: front-loaded purpose, then listed contents, error behavior, and auth requirement. No wasted words.
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 empty input schema and existence of output schema, the description covers key aspects: aggregated fields, partial failures, auth requirement. It is complete for this composite 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?
With zero parameters, the baseline is 4. The description adds meaning by detailing the output fields, though parameter semantics dimension focuses on 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 it is a read-only health summary that compiles multiple fields (profile, allergies, counts, appointments) in one call, distinguishing it from sibling single-purpose tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for broad overviews and mentions authentication requirement, but does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that sensitive fields (TCKN, email, phone) are excluded and identifies an error case (auth_required). This provides useful behavioral context beyond the 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 three sentences, front-loaded with purpose, and uses bullet-like formatting to list returned/excluded fields. Every sentence provides value with no redundancy.
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 simplicity (no parameters, annotations present, output schema exists), the description completely covers return fields, exclusions, and authentication requirements. It is self-contained for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds no parameter info, but none is needed. The description is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the E-Nabız profile summary (verb+resource), lists included fields (name, blood type, etc.), and explicitly excludes sensitive data. This distinguishes it from sibling tools that focus on specific health records (e.g., diagnoses, prescriptions).
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 specifies that the tool requires an authenticated session and will error otherwise. It implies that it is for profile data only, but it does not explicitly say when not to use it or mention alternatives among the siblings.
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?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by explaining truncation behavior (truncated: true), authentication error, and that results combine three categories. It also mentions the 'limit' parameter's effect (0 = unlimited).
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, front-loaded with purpose, and uses bullet points for parameters. Every sentence adds value without redundancy.
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 that an output schema exists and this is a list tool with few parameters, the description covers return fields (tarih, kategori, etc.), auth requirement, truncation, and parameter behavior 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?
Despite 0% schema description coverage, the description explains both 'category' (if given, returns only that category) and 'limit' (default 50, 0 = unlimited, truncation flag) with sufficient detail beyond raw schema properties.
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 allergy records (E-Nabız alerji kayıtlarını listeler) and specifies it is read-only (salt-okunur). It also explains the three categories combined (ilac, tani, deri), distinguishing it from sibling tools that list other health data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance by noting authentication requirements (kimlikli oturum gerektirir) and behavior when category parameter is provided (yalnız o kategori döner). It does not explicitly exclude other tools, but the specialization to allergies is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds behavioral details: requirement of authenticated session, structure of returned reports (date, number, type, etc.), and the truncated flag. This complements the annotations without contradiction.
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 and well-structured, with a clear first sentence stating the purpose, followed by bullet-point parameter details, return field list, auth note, and limit behavior. Every sentence adds value without 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 the 0% schema description coverage and presence of an output schema, the description is fairly complete: it explains parameters, defaults, error conditions, and response structure. However, it does not mention ordering or pagination beyond limit, so slightly incomplete for full autonomous 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?
The input schema has 0% description coverage, but the description fully explains all four parameters: start_year/end_year (year range with default last 6 years), type_query (case-insensitive filter), limit (max records with default 50, 0=unlimited, and truncated response). This provides complete semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists health reports by year range ('E-Nabız sağlık raporlarını yıl aralığına göre listeler'), specifying the verb (list), resource (health reports), and scope (year range). It distinguishes from sibling list tools like enabiz_list_lab_tests or enabiz_list_prescriptions by its resource focus.
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 on usage: it requires authenticated session (indicated by the auth_required error), and explains default behavior for parameters. However, it does not explicitly state when to prefer this tool over alternatives, though the tool's name and resource specificity imply its appropriate use case.
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?
The description discloses that the tool sends an SMS OTP and returns a status indicating SMS is required. Given annotations (readOnlyHint=false, openWorldHint=true), this adds useful context about the mutation (sending SMS) without contradiction.
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 just two sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words.
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?
For a two-step authentication tool, the description fully covers what the tool does, its side effect (sending SMS), and how to proceed. The output schema is not detailed, but the description adequately explains the expected response.
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 (100% coverage), so the baseline is 4. The description does not need to add parameter details; it correctly mentions the implicit use of .env credentials, which is sufficient.
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 that the tool starts E-Nabız login (step 1/2), validates credentials from .env, and triggers an SMS OTP. It clearly distinguishes from the sibling `enabiz_login_verify` by naming it as the next 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?
The description explains that this is the first step and that if the returned step is 'sms_required', the user should use `enabiz_login_verify`. It implicitly requires .env credentials. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint=true` and `openWorldHint=true`, covering safety. Description adds behavioral context: it performs a lightweight verification request and outlines the next steps if the session is invalid, which is beyond what annotations provide.
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 short sentences, front-loaded with the main purpose. Every sentence is informative and there is no wasted text.
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 zero parameters, an existing output schema, and clear annotations, the description fully covers the tool's purpose, behavior, and usage flow. It is complete for the tool's 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 in the schema (0 params), so baseline is 4. The description adds meaning by explaining the returned `authenticated` field and its implications, compensating for the lack of 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?
Description clearly states the tool returns current e-Nabız session and configuration status. The verb 'returns' and specific resource 'session and configuration status' make it unambiguous. It is distinct from sibling tools which handle data retrieval or login flows.
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?
Description explains when the `authenticated` field indicates the session is valid, and if false, directs to use `enabiz_login_start` followed by `enabiz_login_verify`. This provides clear context for usage but does not explicitly list other sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details auth requirements, default year range, case-insensitive facility filtering, pagination with limit and truncation flag. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points, front-loaded with main purpose, every sentence adds necessary detail without redundancy.
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 4 optional parameters, output schema exists, annotations present, the description covers all behavioral aspects: auth, default ranges, filtering, pagination, and returned fields. Complete.
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 0%, so description fully explains parameters: start_year/end_year default to last 6 years, facility_query is case-insensitive filter, limit default 50 with 0 meaning unlimited and truncated flag. Adds significant 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 the tool lists medical device prescriptions by year range. The name distinguishes it from sibling tools like enabiz_list_prescriptions and enabiz_list_optical_prescriptions.
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 explains parameters and defaults but does not explicitly state when to use this tool versus alternatives. It implies use for device prescriptions but lacks explicit when-not or sibling differentiation.
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?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by explaining the return format (date, subject, description), the case-insensitive query filter on subject, the limit behavior with default, and the truncated flag for open-world indication. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences) with a clear front-loaded structure: purpose, return fields, filter, limit details. Every sentence provides essential information without redundancy.
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 2 parameters and an output schema (not shown), the description covers input semantics, output fields, and the truncated indicator. It is complete for an agent to understand usage and response.
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 description coverage, the description fully explains both parameters: 'limit' (max records, default 50, 0=unlimited, with truncated output) and 'query' (case-insensitive filter on subject). This compensates entirely for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'E-Nabız acil durum notlarını listeler' (lists emergency notes) and 'salt-okunur' (read-only), specifying the verb and resource. The tool name and context with siblings confirm it is a list tool for emergency notes, distinct from other list 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 listing emergency notes but does not provide when-to-use guidance versus sibling list tools. It mentions 'Kimlikli oturum gerektirir' (requires authenticated session) but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: describes return fields, query case-insensitivity, auth requirement with error, limit behavior with truncated flag. Doesn't contradict annotations (readOnlyHint, openWorldHint).
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?
Concise, two paragraphs and a bullet. Front-loaded main purpose. Every sentence adds value; no redundancy.
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 fields returned, filtering, auth error, limit truncation. Output schema exists so return format is documented. Complete for a list 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?
With 0% schema coverage, description fully explains both parameters: limit (max records, default 50, 0=unlimited, truncated indicator) and query (case-insensitive filter on description).
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 insurance records (sigorta kayıtlarını listeler) and explicitly marks as read-only (salt-okunur). Differentiates from sibling tools by domain (insurance).
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?
Implies usage: fetch insurance records when needed. Provides query filtering and auth requirement but no explicit when-not or alternative tool comparisons.
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?
Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description adds behavioral details: explains category combination, limit behavior (default 50, 'truncated: true' if exceeded), and authentication requirement. No contradictions with 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 short (3 paragraphs), front-loaded with purpose, and every sentence provides necessary detail. No redundant or vague statements.
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 presence of an output schema (so return values are documented elsewhere), the description covers all essential aspects: purpose, filtering, parameter behavior, and authentication. It is complete for the tool's complexity.
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 description coverage, the description fully compensates by explaining both parameters: 'limit' (max records, default 50, 0=unlimited, truncated flag) and 'category' (allows filtering from five listed values: diger, vucut, isitme, goz, ozel_yapim). Adds significant meaning beyond the bare 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 medical material/device records (verb 'listeler' + resource 'tıbbi malzeme/cihaz kayıtları'), specifies it combines 5 categories, and filters by category. It distinguishes well from sibling list tools like enabiz_list_allergies or enabiz_list_appointments.
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 for when to use the tool (listing medical devices with category filtering) and mentions requirements (authenticated session). However, it does not explicitly state when not to use it or compare to alternatives, leaving some ambiguity among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication requirement and truncation behavior beyond annotations; adds value without contradicting readOnlyHint.
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?
Well-structured bullet points, concise yet complete, no wasted sentences.
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 year range, filter, limit, authentication, truncation; output schema handles return values.
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?
All 4 parameters fully described with defaults and behavior, compensating for 0% schema coverage.
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 medications by year range, distinguishing it from sibling list tools for other health data.
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?
Specifies when to use (list medications by year range) and how to filter; could improve by explicitly contrasting with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description provides behavioral details beyond annotations: requires auth, returns auth_required error, returns truncated flag, includes sys_no for PDF. Does not contradict annotations (readOnlyHint, openWorldHint).
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?
Concise and well-structured: main purpose first, then bullet-pointed parameter explanations. No unnecessary text.
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?
Description covers all relevant aspects: parameter defaults, filter behavior, output fields, error case, and truncation indicator. With output schema present, return value explanation is sufficient.
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 fully documents each parameter: start_year/end_year default range, query filter behavior, limit default and unlimited option. Adds meaning beyond type.
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?
Purpose is clearly stated: list pathology records by year range. The verb 'list' and resource 'pathology' are specific, and the description distinguishes from siblings like lab tests or medications.
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?
Description explains parameters and defaults but does not explicitly state when to use this tool versus alternatives among many sibling list tools. The name implies the domain, but no direct comparison or exclusion is provided.
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?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral details: default year range (last 6 years), doctor query filtering, limit with truncation, and auth error response. This provides useful context beyond annotations without contradiction.
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 and well-structured: a one-line purpose, clear bullet points for parameters, and a brief note on return values and auth. No redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters and presence of output schema, the description adequately covers default behavior, filtering, pagination (limit/truncated), and error handling. It also links to the related detail tool, making it complete for a list operation.
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 description coverage, the description fully explains each parameter: start_year/end_year defaults, doctor_query case-insensitive filtering, limit default (50) and behavior for 0 (unlimited) and truncated flag. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists E-Nabız prescriptions by year range, with a specific verb and resource. It distinguishes itself from the sibling 'enabiz_get_prescription_detail' by noting that drug details require that tool.
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 when to use (listing prescriptions) and mentions an alternative (enabiz_get_prescription_detail for details). It also notes auth requirements. However, it does not explicitly state when not to use this tool or other conditions.
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?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (dynamic results). The description adds valuable behavioral details: authentication requirement, error message on failure, limit semantics (default 50, 0=unlimited, truncated flag), and the fact that it returns studies displayed on the current page. No contradictions with 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 concise with no wasted words. It starts with the primary purpose, then provides necessary behavioral and parameter details in a structured way. Every sentence earns its place.
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 existence of an output schema (not shown), the description adequately covers usage context: purpose, authentication, parameter, and relation to sibling tool. It mentions key output fields (date, institution, description, order_id) and behavior like pagination via limit and truncated. No gaps are apparent for a list 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?
The single parameter limit has schema coverage 0%, so the description fully compensates. It explains the default value (50), the meaning of 0 (unlimited), and the truncated flag behavior. This is complete and precise, exceeding the schema's minimal definition.
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 radiological examination/image records from E-Nabız. It mentions returned fields (date, institution, description) and distinguishes from sibling tools by specifying that order_id is used for enabiz_get_radiology_report. The verb 'listeler' (lists) combined with the specific resource makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires authenticated session (auth_required error) and explains limit parameter behavior. It implicitly guides when to use this tool versus the report tool by linking order_id. However, it does not explicitly state when not to use it or contrast with other list tools, though the sibling context is clear.
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?
Describes session persistence locally and reuse, and success condition. Annotations (mutating, open world) are complemented, not contradicted.
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 short sentences, front-loaded with purpose, no extraneous information. 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?
Covers purpose, prerequisite, success behavior, and session saving. Missing error handling details, but tool is simple and output schema exists to document return values.
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 has single string parameter with 0% description coverage. Description adds that it is the SMS OTP code sent to phone, providing necessary context.
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 completes E-Nabız login (step 2/2) by sending SMS OTP code, distinguishing it from sibling tools that handle data retrieval or login initiation.
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?
Explicitly states prerequisite: enabiz_login_start must be called first. Does not list when not to use, but context of two-step login is clear.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds that it returns only displayed appointments, details limit behavior with truncated flag, and explicitly states no mutation. No contradiction with 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 concise, front-loading the purpose, then adding parameter details and constraints. Every sentence is informative without 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 the presence of an output schema, the description adequately covers parameter behavior, auth requirements, and the read-only constraint. It could mention error handling beyond auth_required, but overall sufficient.
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 thoroughly explains both parameters: limit's default and behavior, and status_query's case-insensitive filtering. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists E-Nabız appointments, specifies it is read-only, and lists the fields returned. It distinguishes from siblings by focusing on appointments, with a specific verb and resource.
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 it does not take/cancel appointments and requires an authenticated session. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance beyond the read-only nature.
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?
The description discloses read-only behavior (consistent with readOnlyHint), requires authenticated session with an explicit 'auth_required' error, explains limit parameter behavior (default 50, 0=unlimited, truncated flag), and describes case-insensitive filtering on query. This adds significant context beyond 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 concise, with the main purpose front-loaded. Each sentence adds meaningful information without redundancy. It is well-structured for quick comprehension.
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's simplicity (2 optional params), the description covers return fields, auth requirements, limit behavior, filtering, and truncation. With output schema present, no additional return value details are needed. The description is complete for effective 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 description adds meaning to both parameters: limit with default, 0 meaning unlimited, and truncated flag; query with case-insensitive filtering on chronic disease field. Since schema coverage is 0%, the description compensates well. However, there is a minor inconsistency: schema default is null but description states default 50, which could cause confusion.
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 chronic disease follow-up records and is read-only. It specifies the fields returned (follow-up type, chronic disease, dates, status) and explicitly distinguishes it from diagnosis history (Hastaliklarim), making the purpose unambiguous even among 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions this tool is separate from diagnosis history, providing implicit guidance to not confuse with other list tools. However, it does not explicitly name alternative tools or give when-not-to-use scenarios. The differentiation from diagnosis history is useful, but not fully comprehensive.
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?
Annotations already indicate read-only and open-world; description adds auth requirement, default year range, filtering, limit behavior, truncation flag, and return fields.
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?
Well-structured with bullet points and front-loaded purpose, but could be slightly more concise; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given lack of parameter descriptions in schema, the description provides complete context for selecting and invoking the tool, including auth, parameters, and response structure.
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 compensates fully by explaining all four parameters, including defaults and behavior (year range, type_query case-insensitivity, limit values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists optical (glasses/lens) prescriptions filtered by year range, distinguishing from general prescriptions 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes auth requirement and default behavior (year range), but does not explicitly contrast with sibling tools like enabiz_list_prescriptions.
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 important behaviors beyond annotations: PDF is saved to a specific directory with chmod 600, the content is not passed to the LLM, only metadata is returned, and an error is thrown if no authenticated session exists. This fully addresses the readOnlyHint annotation by clarifying that server data is not modified.
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 well-organized with a clear opening sentence followed by a bulleted list of document types and their parameters. Every sentence earns its place; no fluff.
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 necessary aspects: document types, parameter mapping, authentication requirement, output format, and file permissions. Despite having 9 parameters and only 1 required, the description makes usage straightforward. Output schema exists, so return values are handled.
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, the description adds full meaning by mapping each 'kind' value to required and optional parameters (e.g., 'lab' requires card_tarih and kurum_kodu; optional start_year/end_year and dil). This is far beyond what the schema alone provides.
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 states exactly what the tool does: downloads a PDF health document and saves to disk. It lists the supported document types (lab, pathology, discharge, radiology) with their specific parameter requirements, clearly distinguishing this download action from sibling tools that list or retrieve data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: to download a PDF. It references sibling list tools for obtaining required parameter values and mentions authentication prerequisites. While it does not explicitly state when not to use, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the detail HTML is reduced to readable plain text and truncated if long (DETAIL_TEXT_LIMIT). Also states authentication requirement and error on missing auth. Annotations already mark readOnly and openWorld, but description adds specific behaviors.
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?
Short, efficient description with purpose first, then source, then processing details and auth requirement. Every sentence adds value, no redundancy.
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 simple tool with output schema present, description covers purpose, input, processing, and authentication. No gaps for selecting and invoking correctly.
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 has 0% description coverage, but description compensates fully by explaining sys_takip_no is from the list tool's output, giving clear context for the single parameter.
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 returns the detail text of a diagnosis ('detay metnini döndürür') using a specific identifier. Distinguishes from sibling tool enabiz_list_diagnoses by specifying input from that list.
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?
Explicitly says to use with sys_takip_no from enabiz_list_diagnoses output. Mentions required authentication and error response. Does not provide explicit when-not-to-use or alternatives beyond the parent list tool.
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?
Annotations provide readOnlyHint and openWorldHint. The description adds beyond annotations: it returns a URL (not binary), requires authenticated session, and gives the exact error message on auth failure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose. Every sentence adds value: what it returns, how to get input, auth requirement. No wasted words.
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 output schema exists (not shown but present), the description does not need to explain return values. It covers input source, output type, auth requirement, and error condition. Complete for the tool's complexity.
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 has only one parameter (accession_number) with 0% description coverage. The description compensates fully by explaining that the value comes from enabiz_list_radiology_studies and is only filled for studies with images. This adds crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a DICOM viewer link (URL) for a radiological examination, using a specific verb and resource. It distinguishes from siblings like enabiz_get_radiology_report and enabiz_list_radiology_studies by mentioning the output type (URL vs report) and data source.
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 explicitly tells the agent to source the accession_number from enabiz_list_radiology_studies output and notes that it only returns a link for studies with images. It also specifies authentication is required and mentions the error on auth failure. However, it does not explicitly say when not to use this tool versus alternatives, though the context implies 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?
Description adds behavioral details beyond annotations: requires authenticated session (auth_required error), returns truncated flag, default limit 50, case-insensitive query, and summary fields. No contradictions with 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?
Description is concise and well-structured with bullet points. First sentence states purpose, followed by parameter details. No wasted words; appropriate length.
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 coverage for a list tool with 4 optional parameters. Includes auth requirements, default behavior, filter mechanics, limit, and return indicators (truncated flag). Output schema exists but not needed due to comprehensive description.
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?
All 4 parameters are fully explained in the description despite 0% schema coverage. Describes start_year/end_year range defaults, query as case-insensitive filter, and limit with default 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 the tool lists hospital visits (examinations) by year range, using a specific verb and resource. It distinguishes itself from sibling tools that list other entities like appointments or diagnoses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on default year range, optional query filter, and limit parameter. Does not explicitly state when not to use, but context from sibling tools suggests this is the appropriate tool for listing visits.
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?
Beyond readOnlyHint and openWorldHint annotations, description discloses hazards (large response without query), auth requirement, error format, and grouping behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured bullet points, each sentence adds value. No redundancy. Front-loaded with main purpose then parameter 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 complexity (listing, filtering, truncation, auth) and presence of output schema, description covers return grouping, truncated flag, and error handling. Complete for effective 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?
All 4 parameters are fully explained with default behaviors and usage tips (e.g., limit default 50, test_query for filtering). Schema has 0% description coverage, so description adds all necessary 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?
Description clearly states 'list lab test results by year range'. The tool name and description specify lab tests, distinguishing it from siblings like enabiz_list_medications or enabiz_list_vaccinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: default year range, recommendation to use test_query for specific tests to avoid large responses, and explains what to do if truncated. Lacks explicit when-not-to-use but 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?
The description matches annotations (readOnlyHint=true, openWorldHint=true) by stating 'salt-okunur' and explains the truncated flag behavior. It also discloses the auth requirement and error response for missing auth. No contradictions and adds useful context beyond 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 concise (3 sentences plus bullet), every sentence carries value. Front-loaded with purpose and read-only nature, followed by param details in logical order. No wasted words.
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 presence of output schema (not shown), the description covers all essential behavioral details: auth requirement, filtering, pagination behavior, and truncation. It is complete for a list tool with 2 optional parameters.
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 description coverage, the description carries the full burden. It explains query as case-insensitive filter on vaccine name, limit with default 50, 0=unlimited, and the truncated flag. This adds significant meaning beyond the input schema's basic types.
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 the E-Nabız vaccination schedule (aşı takvimi) and explicitly marks it as read-only (salt-okunur). It distinguishes itself from sibling tools that handle different health data like allergies, appointments, etc.
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 specifies prerequisites: requires an authenticated session (Kimlikli oturum gerektirir) and explains behavior for limit and query parameters. However, it does not explicitly state when not to use this tool or compare it to other list tools, though the broader sibling context makes it clear.
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?
Annotations already mark readOnlyHint and openWorldHint, but the description adds significant behavioral context: it describes the query parameter as case-insensitive filtering, explains the limit parameter behavior (default 50, 0 means unlimited, and a truncated flag), and specifies the authentication error message ('auth_required'). This goes well beyond 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 concise and well-structured: a purpose line, then details on output fields, query behavior, authentication, and limit parameter. Every sentence adds value, and the most critical info (what it does) is front-loaded. No wasted words.
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 only 2 parameters and no output schema? Actually context says has output schema true, but description still provides sufficient output structure (date, diagnosis with ICD code+name, clinic, physician, sys_takip_no). It also covers auth, error handling, and limit behavior. Complete for a list tool with this complexity.
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 input schema has 0% coverage (no property descriptions), so the description must fully explain parameters. It does: 'query' for case-insensitive filtering on diagnosis text, and 'limit' for maximum records (default 50, 0=unlimited) with a truncated flag. This adds complete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists E-Nabız diagnosis/disease history and is read-only. It distinguishes itself from sibling tools by mentioning the detail tool enabiz_get_diagnosis_detail. The verb 'listeler' (lists) and resource 'tanı/hastalık geçmişini' (diagnosis/disease history) are specific.
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 guidance on when to use this tool (to list diagnoses) and when to use the alternative enabiz_get_diagnosis_detail for details. It also mentions the authentication requirement and the error response, giving the agent clear context for decision-making.
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:

[![enabiz-mcp MCP server](https://glama.ai/mcp/servers/UmutKDev/enabiz-mcp/badges/card.svg)](https://glama.ai/mcp/servers/UmutKDev/enabiz-mcp)

Score Badge

Copy to your README.md:

[![enabiz-mcp MCP server](https://glama.ai/mcp/servers/UmutKDev/enabiz-mcp/badges/score.svg)](https://glama.ai/mcp/servers/UmutKDev/enabiz-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/UmutKDev/enabiz-mcp'

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