Yargı MCP

by saidsurucu

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: v1.0.0
Disambiguation4/5
Most tools target distinct legal sources with clear search/get pairs. However, the Bedesten source has duplicate tools (search/fetch for Deep Research vs. search_bedesten_unified/get_bedesten_document_markdown for regular use) which could cause confusion despite explicit descriptions.
Naming Consistency2/5
Tool names mix patterns: some use 'unified', others 'decisions', 'ozelge', 'detailed_decisions', or 'issue'. The base tools 'search' and 'fetch' break the pattern, and 'check_government_servers_health' stands alone. Overall inconsistent naming.
Tool Count3/5
At 26 tools, the count is slightly above the typical 'heavy' range (16-25). The breadth of legal databases justifies many tools, but the duplication of Bedesten tools for Deep Research vs. regular use adds unnecessary bloat.
Completeness4/5
The tool set covers a wide range of Turkish legal databases with search and document retrieval for each. Minor gaps exist (e.g., no unified document retrieval across sources), but the core workflows are well-supported.
Average 4/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 11 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description doesn't contradict these but adds minimal behavioral context—it specifies the domain (Turkish competition law) but doesn't detail aspects like pagination behavior (implied by the 'page' parameter), rate limits, or authentication needs. With annotations providing core safety info, the description adds some value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficient, though it could be slightly more informative by including key usage details without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, search functionality) and rich annotations/output schema, the description is minimally adequate. It identifies the domain but lacks details on result format, pagination, or how it integrates with sibling tools. With annotations and schema covering safety and parameters, the description meets a basic threshold but leaves room for improvement in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions in the schema (e.g., 'Search in decision title', date formats, enum values). The tool description adds no parameter-specific information beyond what's already in the schema, so it doesn't enhance understanding of parameters. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches 'Turkish competition law and antitrust decisions (Rekabet Kurumu)', which provides a clear verb ('search') and resource domain. However, it doesn't specify what aspect of decisions it searches (e.g., metadata, full text) or how it differs from the sibling tool 'get_rekabet_kurumu_document', making it somewhat vague about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says 'Use this when searching Turkish competition law and antitrust decisions', which gives a general context but no explicit guidance on when to choose this tool over alternatives like 'search' (generic) or 'get_rekabet_kurumu_document' (specific document retrieval). There's no mention of prerequisites, exclusions, or comparative use cases.
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 idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds value by specifying the output format ('clean Markdown format'), which isn't covered by annotations. However, it doesn't provide additional behavioral context like rate limits, authentication needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that are front-loaded and waste-free. Every word contributes essential information about purpose and output format without any redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety (readOnlyHint, idempotentHint), 100% schema coverage, and an output schema exists, the description provides adequate context. It specifies the court type and output format, which complements the structured data well. However, it could be more complete by mentioning it's specifically for documents from search results (as hinted in the schema) to better integrate with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'document_url' well-described in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieving') and resource ('full text of an Uyuşmazlık Mahkemesi decision'), and specifies the output format ('clean Markdown format'). It distinguishes from some siblings by focusing on this specific court, but doesn't explicitly differentiate from other document retrieval tools like 'get_anayasa_document_unified' or 'get_bddk_document_markdown' beyond the court name.
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 provides some usage context with 'Use this when retrieving full text of an Uyuşmazlık Mahkemesi decision,' which implies this tool is for decisions from that specific court. However, it doesn't explicitly state when NOT to use it or mention alternatives among the many sibling search and retrieval tools, leaving some ambiguity about tool selection.
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 provide readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds context about the specific domain (Turkish public procurement) and decision types supported, which is useful behavioral information beyond the annotations. However, it doesn't mention rate limits, authentication requirements, or other operational constraints that might be relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence that efficiently communicates the tool's purpose and scope. Every word earns its place with no wasted text. It's appropriately sized for a search tool with good schema documentation.
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 the tool has comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint), 100% schema description coverage, and an output schema exists, the description provides adequate context. It clearly states the domain and decision types, which complements the structured data well. The main gap is lack of explicit differentiation from sibling tools, but otherwise it's reasonably complete for this complexity level.
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?
With 100% schema description coverage, all 7 parameters are well-documented in the input schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for 'Turkish public procurement disputes (KİK)' and specifies the three decision types it supports. This provides a specific verb ('search') and resource ('Turkish public procurement disputes'), though it doesn't explicitly differentiate from sibling search tools like 'search_uyusmazlik_decisions' or 'search_bddk_decisions' which might cover similar domains.
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 begins with 'Use this when searching Turkish public procurement disputes (KİK)', which provides basic context for when to use the tool. However, it doesn't offer explicit guidance on when to choose this tool over sibling alternatives like 'search_uyusmazlik_decisions' or 'search_bddk_decisions', nor does it mention any exclusions or prerequisites. The guidance is implied rather than comprehensive.
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 idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds value by specifying the return format ('clean Markdown format'), which isn't covered by annotations. However, it doesn't provide additional behavioral context like rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and output format. Every word earns its place, and it's front-loaded with the primary use case, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only/idempotent annotations, output schema exists), the description is reasonably complete. It covers the core purpose and output format, and the output schema will handle return value details. However, it could benefit from more explicit differentiation from sibling search tools to fully guide usage.
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 one parameter 'id' with 0% description coverage, so the schema provides no semantic information. The description doesn't explicitly mention parameters, but it implies the 'id' is needed to retrieve a specific document. Since there's only one parameter and its purpose is reasonably inferred from context, this compensates adequately for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving full text of an Emsal precedent decision and returning it in clean Markdown format. It specifies both the action ('retrieving') and resource ('Emsal precedent decision'), but doesn't explicitly differentiate from sibling tools like 'search_emsal_detailed_decisions' or other document retrieval 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 provides some usage guidance with 'Use this when retrieving full text of an Emsal precedent decision,' which implies this is for full document retrieval rather than search. However, it doesn't explicitly state when NOT to use it or mention alternatives like the search tools among siblings, leaving some ambiguity about tool selection.
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 valuable behavioral context beyond annotations: it specifies the return format ('clean Markdown format'), which isn't covered by annotations. Annotations already indicate read-only, non-open world, and idempotent operations, so the bar is lower, and the description complements this with output details 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 highly concise and front-loaded: two sentences that directly state the tool's purpose and output format with zero wasted words. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with 2 required parameters), rich annotations (readOnlyHint, openWorldHint, idempotentHint), and the presence of an output schema (implied by context signals), the description is mostly complete. It covers purpose and output format, though it could better integrate with sibling tools for clearer usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter documentation (decision_id and decision_type with descriptions and enum). The description doesn't add extra parameter semantics beyond what the schema already states, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'retrieving full text of a Sayıştay audit decision' with a specific resource (audit decision) and verb (retrieving). It distinguishes from siblings by specifying the exact document type (Sayıştay audit decisions), though it doesn't explicitly contrast with similar document retrieval tools like get_anayasa_document_unified.
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 provides some usage guidance with 'Use this when retrieving full text of a Sayıştay audit decision,' which implies context. However, it doesn't specify when to use alternatives (e.g., search_sayistay_unified for finding decisions vs. this for retrieving text) or mention prerequisites like needing a decision_id from search results, which is only hinted at in the schema.
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?
The annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds useful context about the specific regulatory domain (BDDK decisions) and use cases, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or what constitutes a 'decision' in this context. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the primary purpose. Every word earns its place by specifying the regulatory body, domain, and use cases without any redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with pagination), rich annotations (readOnly, openWorld, idempotent), 100% schema coverage, and existence of an output schema, the description is reasonably complete. It clearly defines the search domain and use cases, though it could benefit from mentioning the Turkish language requirement for keywords or distinguishing from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('keywords' and 'page') well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples for keywords or pagination behavior. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching Turkish banking regulation (BDDK) decisions, specifying the domain (banking licenses, fintech, payment services). It uses a specific verb ('searching') and resource ('BDDK decisions'), but doesn't explicitly differentiate from sibling tools like 'search_kik_v2_decisions' or 'search_rekabet_kurumu_decisions' that search different regulatory domains.
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 ('when searching Turkish banking regulation (BDDK) decisions') and mentions specific use cases (banking licenses, fintech, payment services). However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling search tools for different regulatory bodies.
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 valuable behavioral context beyond annotations: it specifies the return format ('Markdown format') and pagination behavior ('Returns paginated'). Annotations already cover read-only, closed-world, and idempotent characteristics, so the description appropriately focuses on output characteristics not captured in structured fields.
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 perfectly concise - two sentences that each earn their place. The first establishes when to use the tool, the second specifies key behavioral characteristics (format and pagination). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, comprehensive annotations, complete schema coverage, and the presence of an output schema, the description provides exactly what's needed. It covers purpose, format, and pagination behavior without needing to explain parameters or return values that are already documented elsewhere.
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?
With 100% schema description coverage, the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic context about how parameters interact or affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieving full text') and resource ('BDDK banking regulation decision'), distinguishing it from generic fetch/search tools. However, it doesn't explicitly differentiate from its closest sibling 'get_bedesten_document_markdown' which appears to serve a similar function for a different document type.
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 provides basic context ('when retrieving full text of a BDDK banking regulation decision') but doesn't specify when NOT to use this tool or mention alternatives like 'search_bddk_decisions' for finding documents before retrieving them. Usage is implied rather than explicitly guided.
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 idempotentHint, indicating safe re-execution. The description adds valuable behavioral context: the output is paginated in 5000-char chunks and includes specific metadata (title, reference number, date, law).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the purpose, parameters, output format, and key constraints without any redundant text.
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 simple schema, rich annotations, and existence of an output schema, the description covers the main behavioral aspects (pagination, metadata). It does not mention error handling or prerequisites like requiring an ID from search, but the overall context is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The tool description does not add additional semantics beyond confirming the ID is numeric and pagination is 1-indexed, which is already in 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 retrieves the full text of a GİB özelge by numeric ID and returns paginated Markdown with metadata. It uses a specific verb ('Retrieve'), identifies the resource, and distinguishes it from sibling tools like get_bddk_document_markdown.
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 the tool should be used after obtaining an ID from search results (as stated in the parameter description for ozelge_id), but it does not explicitly mention when to use this tool versus alternatives like search_gib_ozelge or other document retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent. Description adds key behaviors: returns paginated Markdown (not raw PDF), and scope of available issues (1-64, 2010-2025). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Each clause serves a clear function.
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, scope, output format, and pagination. Output schema exists, so return value details are not needed. Could mention page number behavior (default 1) but schema covers that. Missing minor guidance on iteration for full content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. The description adds minimal extra meaning (e.g., 'by number', 'paginated'), but baseline is 3 due to 100% 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?
The description clearly states the verb 'Retrieve' and the resource 'full PDF content of a Sigorta Tahkim Komisyonu Hakem Karar Dergisi issue by number'. It distinguishes from sibling tools like 'search_within_sigorta_tahkim_issue' by focusing on retrieving an entire issue.
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?
Implicitly indicates use to retrieve full issue content, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools. No mention of alternatives like search tools.
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 (readOnlyHint, openWorldHint, idempotentHint) already cover safety and idempotency. The description adds minor context (norm control filters include reviewed norm metadata) but does not expand on behavioral implications beyond what annotations provide. 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 extremely concise: two sentences, no wasted words. The key instruction ('Use this when...') is front-loaded, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not explain return values. It covers the search domain (Turkish Constitutional Court decisions), decision types, and pagination. Minor gap: could mention that results are a list of documents, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds minimal additional meaning (e.g., 'norm control filters include reviewed norm metadata'), but this is vague and not necessary. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Turkish Constitutional Court decision records, specifying the two decision types (norm control and individual applications). The name and description differentiate it from sibling search tools targeting other courts/agencies.
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 says 'Use this when searching Turkish Constitutional Court decision records', providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list implies other tools for other domains.
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, openWorldHint, and idempotentHint, which sufficiently inform the agent about safety. The description adds the source-specific behavioral context (searching full text or case/decision numbers) but does not extend 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?
The description consists of two concise sentences that front-load the purpose and key behavioral trait. Every word earns its place with no redundancy or fluff.
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 simple search nature, full schema documentation, and presence of an output schema, the description is complete for the tool's function. It could briefly mention that results are a list of decisions, but the output schema likely covers that.
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?
All four parameters have descriptions in the schema (100% coverage). The description mentions matching case/decision numbers based on search_scope, but this is already detailed in the schema. The description adds no new semantic 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 searches Uyuşmazlık Mahkemesi decisions, which resolves conflicts between civil and administrative courts. This specific verb+resource combination distinguishes it from sibling tools targeting different document types.
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 says 'Use this when searching jurisdictional dispute court decisions,' providing clear context. However, it does not offer explicit alternatives or conditions for when not to use it, though sibling names imply other search tools for different sources.
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, idempotentHint, openWorldHint. The description adds useful context: it searches from Hakem Karar Dergisi journals (64 issues, 2010-2025) and covers specific insurance dispute types. No contradictory behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous information. First sentence clearly states the tool's purpose; second adds coverage details and examples. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, full schema coverage, output schema exists, and rich annotations, the description adequately covers the tool's scope and usage. It could optionally mention pagination or result format, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The description adds value by providing keyword examples in Turkish and specifying the domain (insurance disputes), which goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches Sigorta Tahkim Komisyonu decisions from a specific journal, covering insurance disputes with years and issues. This distinguishes it from sibling search tools targeting other databases (e.g., search_bddk_decisions, search_kvkk_decisions) and from search_within_sigorta_tahkim_issue which narrows to a single issue.
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 insurance arbitration decisions and provides example keywords, but does not explicitly state when to use this tool over alternatives like search_within_sigorta_tahkim_issue or other search tools. No exclusions or when-not-to-use guidance is given.
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?
Description adds significant behavioral context beyond annotations: rate limit sharing with search and retry guidance. Annotations already declare readOnlyHint and idempotentHint, which are consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. 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?
For a simple retrieval tool with one parameter, high schema coverage, and an output schema, the description covers purpose, usage, and rate limit behavior fully. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for documentId. The description mentions 'by documentId' but adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves full text of a Bedesten search result by documentId. It uses specific verb and resource, and sibling tool names for other document types help distinguish this 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?
Description explicitly says when to use ('when retrieving full text of a Bedesten search result') and provides rate limit handling guidance. It does not explicitly mention when not to use or alternatives, but context from sibling names is sufficient.
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 idempotentHint=true, indicating safe, repeatable read operations. The description adds value by specifying the return format ('Markdown format') and the source context ('KİK procurement decision'), but does not provide additional behavioral details like rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and key details (use case, resource, output format) with zero wasted words, making it highly concise and well-structured.
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 low complexity (single required parameter), high schema coverage, presence of annotations, and an output schema (implied by 'Has output schema: true'), the description is complete enough. It covers the essential context without needing to explain return values or parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter gundemMaddesiId fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline for high 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?
The description clearly states the specific action ('retrieving full text'), resource ('a KİK procurement decision'), and output format ('Markdown format'). It distinguishes from sibling tools like search_kik_v2_decisions by focusing on full document retrieval rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this when retrieving full text of a KİK procurement decision,' providing clear context for when to use this tool. It also references the sibling tool search_kik_v2_decisions in the parameter description, implying an alternative for initial searches.
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 valuable behavioral context beyond annotations by specifying the output format ('paginated Markdown format') and the pagination mechanism. While annotations already declare readOnlyHint=true and idempotentHint=true, the description usefully clarifies the document conversion process ('converted from PDF') and pagination behavior.
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 perfectly concise with two sentences that each earn their place: the first establishes purpose and context, the second specifies output format. No wasted words, and the most important information is front-loaded.
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 moderate complexity, comprehensive annotations (readOnlyHint, idempotentHint), complete schema documentation, and the presence of an output schema, the description provides exactly what's needed: clear purpose, usage context, and key behavioral details about format and pagination.
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?
With 100% schema description coverage, the schema already fully documents both parameters. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation without exceeding it.
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 specific action ('retrieving full text'), resource ('Competition Authority decision'), and output format ('paginated Markdown format'), distinguishing it from sibling search tools like 'search_rekabet_kurumu_decisions' which likely return metadata rather than full document content.
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 about when to use this tool ('when retrieving full text of a Competition Authority decision'), but doesn't explicitly mention when not to use it or name specific alternatives among the many sibling tools, though the distinction from search tools is implied.
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, idempotentHint, openWorldHint. Description adds crucial behavioral detail: does not fetch document bodies during search to respect rate limits, and guides to use fetch separately. 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?
Two sentences front-loaded with purpose and audience, followed by behavioral constraint and guidance. No wasted words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool (1 param, output schema exists), description covers purpose, audience, sibling guidance, and output format. Could add minor details like query format expectations, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'query' described as 'Turkish search query'. Description adds no additional meaning beyond 'Turkish' from schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Searches Bedesten-supported Turkish court databases' with specific verb and resource, and distinguishes from sibling 'search_bedesten_unified' by specifying this is for ChatGPT Deep Research only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Only for ChatGPT Deep Research' and recommends 'For regular MCP use, prefer search_bedesten_unified', providing clear when-to-use and alternatives. Also advises calling fetch for bodies to stay within rate limits.
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 idempotentHint. Description adds context: 'avoids an extra metadata lookup to respect upstream rate limits', explaining its lightweight behavior 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?
Three concise sentences: purpose, alternative, and rationale. No fluff. Front-loaded with key constraint. Each sentence adds distinct 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 the tool's simplicity (one param, output schema exists), the description fully covers purpose, usage context, and behavioral nuance. No gaps.
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?
With 100% schema description coverage, the schema sufficiently documents the 'id' parameter. Description adds no extra semantic details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'retrieves one Turkish legal document by numeric Bedesten ID' — a clear verb+resource. It explicitly distinguishes from sibling tool get_bedesten_document_markdown, making its specialized role obvious.
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?
States 'Only for ChatGPT Deep Research' and directs regular use to get_bedesten_document_markdown. Also mentions rate limit rationale, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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