Mevzuat MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The tools are organized by document type (e.g., Presidential Decisions, Circulars, Laws) and action (search vs. get_content vs. search_within), making it easy for an agent to select the correct one. For example, search_cbbaskankarar finds decisions, get_cbbaskankarar_content retrieves their full text, and there are no overlapping functions between different document types.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout. All tools use snake_case with clear prefixes indicating the document type (e.g., search_cbbaskankarar, get_cbgenelge_content, search_within_kanun). The naming is predictable: search_* for finding documents, get_*_content for retrieving full text, and search_within_* for searching within specific documents.
Tool Count5/5
With 18 tools, the count is well-scoped for the server's purpose of accessing Turkish legislation. Each tool earns its place by covering different document types (e.g., laws, decrees, regulations) and necessary operations (search, retrieve content, search within). This provides comprehensive coverage without being overwhelming, typical for a domain-specific legal database.
Completeness5/5
The tool surface is complete for the domain of Turkish legislation access. It covers CRUD-like operations: search (discovery), get_content (retrieval), and search_within (detailed querying) for all major document types. There are no obvious gaps; agents can find, retrieve, and analyze content across the full lifecycle of legal documents without dead ends.
Average 4.4/5 across 18 of 18 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 4 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on October 10, 2025
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses search is keyword-based and returns specific fields, but does not explicitly state it is a read-only operation, any limitations, authentication needs, or rate limits. Behavioral transparency is inadequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with key purpose, followed by important notes, query syntax, examples, and return info. Every sentence adds value. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no required, 100% schema coverage, and output schema, the description covers purpose, usage, query syntax, and return fields. Does not explain pagination details or error conditions, but is reasonably complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining overall purpose and providing example queries, but parameter details are already well-covered in the schema. Does not significantly enhance parameter 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 identifies the tool's purpose: searching for Turkish Presidential Circulars (CB Genelgesi) by keyword in titles and content. It distinguishes itself from siblings by explicitly naming the document type and contrasting with 'search_cbgenelge' for full text retrieval.
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 usage guidelines: search is keyword-based, not by circular number; recommends using 'get_cbgenelge_content' for full PDF; explains query syntax and suggests leaving empty to list all circulars. Could explicitly mention when not to use this tool versus 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 mode behavior, operator support, case sensitivity, max results limit, and environment variable dependency. No annotations provided, so description compensates well. Could mention authentication or rate limits, but overall transparent.
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-paragraph structure with clear separation of modes, examples, and parameters. No unnecessary 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 sibling richness and presence of output schema, description is nearly complete. Could briefly state that it returns matching articles from the specified KHK, but context is sufficient for 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?
Schema has 100% description coverage, but description adds value by explaining modes with examples, clarifying that case_sensitive only applies to keyword mode, and providing defaults and ranges. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches within a specific KHK's articles using keyword or semantic search. However, it does not explicitly differentiate from the sibling tool 'search_khk', which likely searches across multiple KHKs. The description implies but does not contrast.
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?
Describes two modes and their requirements (e.g., OPENROUTER_API_KEY for semantic), but does not explicitly state when to use this tool vs. alternatives like 'search_khk' or other 'search_within_*' tools. Usage is implied but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns Markdown content and is ready for analysis, implying read-only behavior, but does not explicitly mention no side effects or any authentication/rate limits. A simple fetch tool, but could be more explicit.
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 example) and front-loaded with the purpose. Every sentence adds value, and the example usage clarifies the workflow. No unnecessary 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?
The tool has an output schema (though not detailed), so the description need not explain return format. It mentions Markdown and readiness for analysis. Given the simple retrieval nature and sibling context, it is fairly complete, though error handling or availability info is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description's parameter guidance ('The communiqué number from search results (e.g., '42331')') mirrors the schema descriptions exactly, adding no new semantic value beyond what the schema already 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 clearly states the tool retrieves full content of a Turkish communiqué in Markdown format, with a specific verb ('Retrieve') and resource ('Turkish communiqué (Tebliğ)'). It distinguishes itself from sibling tools that handle other document types (e.g., get_cbgenelge_content, get_mevzuat_content) or search functions.
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 advises to use 'search_teblig' first to find the communiqué number and series, providing a clear usage workflow (search then get content). It does not list exclusions or when not to use, but the context is clear given 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?
No annotations exist, so the description carries full burden. It explains the tool is keyword-based (not by number), details query syntax, and lists return fields. Though it omits potential limits like query length or character restrictions, it is transparent about core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and key notes. It is logically structured but slightly verbose with query syntax examples that extend beyond essential guidance.
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 (7 parameters, many siblings, output schema present), the description covers regulation type, search behavior, syntax, and return data. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptive parameter descriptions. The description adds example queries but does not provide significant new meaning beyond the schema, so 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 for Turkish Presidential Regulations (Cumhurbaşkanlığı Yönetmeliği) in both titles and content. It distinguishes from sibling tools by specifying that institutional regulations should use 'search_kurum_yonetmelik' instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context (regulations issued by Presidency) and an alternative for institutional regulations. It includes query syntax and examples, but lacks explicit exclusions beyond the one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains search behavior (keyword-based, exact phrase option) and return fields, but omits details on pagination limits, result ordering, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, important note, syntax, examples, returns. Examples are helpful but add length; still concise and front-loaded with critical 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?
Given output schema exists, description appropriately states return fields. All parameters are documented. Missing details on potential errors or data volume, but sufficient for a search tool with clear purpose and good annotation coverage.
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 descriptions already cover all 7 parameters (100% coverage). Description adds value by explaining the query syntax and providing examples, which go beyond the schema's parameter 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?
Description clearly states the tool searches for Turkish communiqués (Tebliğ) in titles and content on mevzuat.gov.tr, with specific verb 'search' and resource 'Tebliğ'. It distinguishes from sibling tools like search_kanun or search_khk by targeting a specific 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that search is keyword-based, not by number, guiding users to use descriptive Turkish terms. Provides query syntax and examples, but does not explicitly mention alternative tools like get_teblig_content for number-based lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavioral traits such as the two search modes, requirement for OPENROUTER_API_KEY in semantic mode, uppercase Boolean operators, case sensitivity only in keyword mode, and result limits (1-50). Minor omission: no mention of error behavior if API key is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two opening sentences define purpose, followed by a clear bullet-style listing of modes with examples. Every sentence adds value, and the structure is front-loaded with essential 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?
Given the tool's moderate complexity (6 params, output schema), the description covers the core functionality well. It explains modes and parameter usage, but does not address error scenarios (e.g., invalid mevzuat_no, missing API key) or specify that output schema details exist. Minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying that Boolean operators must be uppercase, providing concrete examples for both modes, and specifying that case_sensitive only applies in keyword mode. This enhances the 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's purpose: search within a specific Presidential Regulation's articles using keyword or semantic search. It specifies the resource (Presidential Regulation articles) and distinguishes from siblings like search_within_cbgenelge or search_within_kanun by naming the regulation 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 explains when to use keyword vs semantic modes, but does not explicitly guide when to choose this tool over sibling tools for different regulation types. It assumes the agent knows that this tool is for 'cbyonetmelik'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that semantic mode requires an API key, keyword mode supports Boolean operators, and gives examples. However, it lacks details on error handling, rate limits, or limitations (e.g., what if mevzuat_no not found). The output schema exists but description doesn't mention return structure.
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 bullet points for modes and examples. It front-loads the main purpose and avoids 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 that an output schema exists, the description need not explain return values. It covers mode selection, parameters, and examples adequately for a search tool. However, it could be slightly more complete by stating that it returns a list of matching articles, though not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds meaningful value by explaining modes, providing usage examples, and clarifying the semantic parameter's requirement. It goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches within a specific Institutional Regulation's articles using keyword or semantic search. The verb 'search' and resource 'Institutional Regulation' (kurum yonetmelik) are specific and distinguish from siblings.
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 two modes with examples and requirements for semantic mode, but does not explicitly differentiate when to use this tool versus other search_within_* siblings or search_kurum_yonetmelik. No exclusion or when-not-to-use guidance 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?
No annotations are provided, so the description carries full burden. It discloses that the tool 'fetches the PDF document and converts it to Markdown' and notes that decisions are only available as PDF. This adds useful behavioral context beyond the schema, though it omits potential error conditions or conversion limitations.
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, well-structured with a purpose sentence, follow-up details, bullet points for returns, and an explicit example. Every sentence contributes 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 the presence of an output schema, the description adequately covers the return format (Markdown), prerequisite workflow (search first), and provides a usage example. No significant gaps for this straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description repeats the parameter purposes from the schema ('number from search results', 'series from search results') without adding new semantic value. No additional formatting or constraints are described.
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 resource ('full content of a Turkish Presidential Decision') and specifies the output format (Markdown). It distinguishes itself from sibling search tools like search_cbbaskankarar and other content tools via the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use search_cbbaskankarar first to find the decision number and series', providing a clear prerequisite. It implicitly defines the tool's role as a retrieval step after search, but does not list when to avoid using it or compare to other content 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?
No annotations, so description carries full burden. It explains search modes, date range formatting, pagination, and Solr syntax. Lacks auth/rate limit info but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long and detailed with structured sections, but some parts like Solr syntax examples are verbose. Could be more concise while retaining clarity.
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 all major aspects: search modes, date filtering, workflow. Mentions mevzuatId in results hinting at output. Given complexity, it is adequately 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 description coverage is 100%. Description adds significant context beyond schema, including Solr syntax examples, date usage, and operator explanations for each 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 it searches/browses Turkish legislation on a specific site, lists 12 legislation types, and distinguishes from sibling tools by being a general search across all 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?
Provides explicit workflow: use this tool first, then use specific tools with mevzuatId. Recommends search modes but does not explicitly exclude use when sibling tools are more appropriate for specific types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It describes what is returned (decree number, title, publication date, Official Gazette info) and mentions pagination. It does not disclose potential rate limits, permissions, or side effects, but as a search tool, it is reasonably transparent. The description adds value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (explanation, important note, query syntax, example queries, returns). It is front-loaded with purpose. While it is longer than minimal, each section contributes useful information. A slightly more condensed version could achieve a 5, but it remains effective.
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 (mentioned in context signals), the description does not need to detail return values. It covers all essential aspects: purpose, query syntax, scope (title/content/both), pagination, and date filtering. It is complete for a search tool with good parameter coverage and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing query syntax examples and clarifying the keyword-based nature, which enhances understanding of the 'aranacak_ifade' parameter. It also explains the 'aranacak_yer' options more clearly. Thus, it goes beyond simple schema repetition.
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 for Turkish Presidential Decrees (Cumhurbaşkanlığı Kararnamesi) in both titles and content. It explains the resource and action, and the return fields specify what is output. Sibling tools like search_cbbaskankarar and search_within_cbk suggest different scopes, and the description implicitly differentiates by focusing on keyword search.
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 states the tool is keyword-based and NOT by decree number, which guides usage. It provides query syntax and example queries. However, it does not explicitly state when to use this tool over siblings (e.g., search_cbbaskankarar for other decree types) or give exclusion criteria, which would elevate to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the search scope (title/content), query syntax, return fields (statute number, title, dates, Official Gazette info), and the ability to list all statutes with dates. This adequately covers behavior for a read-only search tool.
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 uses clear formatting (IMPORTANT note, example queries, returns list) and front-loads the key point about keyword-based search. 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?
The description explains the tool's purpose, input syntax, and output shape (aided by output schema existence). It lacks mention of sibling search_within_tuzuk for in-document searching, but overall it provides sufficient context for an agent to select and use the tool 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?
Schema coverage is 100% and schema descriptions are detailed, but the description adds value by explaining query syntax and providing examples that clarify how Boolean operators and exact phrases work. This reduces ambiguity beyond the schema alone.
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 for Turkish Statutes/Regulations (Tüzük) in titles and content. It specifies that search is keyword-based, not by statute number, and provides examples. This distinctly identifies the resource and action, differentiating it from siblings that search other regulation 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 tells the agent when not to use this tool (not for statute number searches) and gives query syntax and examples. However, it does not mention alternative tools like search_kanun or search_within_tuzuk for related but different searches, leaving the agent to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions chunk-based splitting (no article structure), Boolean operator requirements, and provides examples. Missing details on pagination or error handling, but sufficient for behavioral understanding.
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 with sections for modes and examples. Every sentence adds value, no 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 an output schema exists, description needn't explain return values. It covers search behavior, modes, and query syntax. Could mention result ordering or limitations like max results cap, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by explaining semantic mode, Boolean operators, and providing example queries for both modes, going beyond the schema alone.
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 searches within a specific Presidential Decision's content using keyword or semantic search, distinguishing it from siblings like search_cbbaskankarar (cross-decision) and get_cbbaskankarar_content (retrieval).
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 the two modes (keyword vs semantic) with examples and notes when to use each, including the requirement for OPENROUTER_API_KEY in semantic mode. However, it does not explicitly state when not to use this tool vs alternatives for cross-decision search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly describes two search modes, Boolean operator usage, and the API key dependency. It could mention rate limits or result handling, but the core behaviors are transparent.
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, well-structured with a clear overview, mode breakdown, and examples. Every sentence adds value, and the formatting improves 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 tool's complexity (two search modes, 6 parameters), the description covers modes, constraints, and examples. An output schema exists (not shown), so return values need not be explained. Minor missing details like error handling are acceptable.
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 has 100% coverage, but the description adds value by explaining mode-specific behavior (e.g., case_sensitive only in keyword mode, semantic mode requiring API key) and providing examples. This goes beyond the 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 searches within a specific Presidential Decree's articles using keyword or semantic search. It includes specific verbs ('search within') and explicitly distinguishes from sibling tools by focusing on a single decree vs. broad search.
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 two modes with examples and notes the OPENROUTER_API_KEY requirement for semantic mode. However, it does not explicitly state when to prefer this tool over siblings like 'search_cbk', though the naming and context imply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses fallback behavior (article-based then chunk-based), mode differences, and API key requirement. Lacks mention of cost or rate limits for semantic mode, but overall transparent.
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 with clear sections (purpose, fallback, modes, examples). No redundant sentences; every part contributes useful 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?
Given the tool's complexity (two modes, fallback, 6 params), the description covers key aspects. Output schema exists, so return values are not needed. Could mention pagination but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value with examples, mode explanations, and fallback details. Goes beyond the schema to clarify usage patterns.
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 within a specific Tebliğ communiqué using keyword or semantic search. The verb 'search within' and resource 'teblig' are unambiguous, and the description distinguishes from sibling tools that search other 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?
Explicitly explains two modes (keyword vs. semantic) with examples and the requirement of OPENROUTER_API_KEY for semantic mode. Provides fallback logic but does not explicitly differentiate from sibling tools like search_teblig, though the name indicates scope.
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?
Without annotations, the description discloses the data source (bedesten.adalet.gov.tr), the content structure, and the condition that not all laws have a gerekçe. However, it does not mention network dependency, authentication needs, or read-only nature. Still, the provided information is useful and honest.
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 clear action line, bullet points for content, and two lines for constraints. It front-loads the core purpose and uses efficient formatting without waste.
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 single parameter and the presence of an output schema, the description covers all necessary context: what the tool does, what content it returns, prerequisite conditions, and the workflow. It is fully adequate 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with a detailed description for gerekce_id. The tool description reiterates the prerequisite but does not add new semantic information beyond what the schema provides, 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 the tool retrieves law rationale (gerekçe) and lists specific content types (purpose, committee reports, article justifications). It distinguishes from siblings by limiting to KANUN type legislation and referencing search_mevzuat as a prerequisite.
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 the tool is only for KANUN laws with published rationale, advises checking gerekceId in search_mevzuat results, and provides a clear workflow: search → check → call. This gives excellent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes return fields (decision number, title, publication date, Official Gazette info), PDF format, and search behavior. It lacks details on rate limits or authentication but is transparent about results.
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-structured with sections for important notes, query syntax, examples, and returns. 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 multiple sibling search tools, this description fully covers how to use the tool, what it returns, and how it differs from others. Output schema exists but is supplemented by clear return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing example queries and syntax, reinforcing parameter usage beyond schema definitions.
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 for Turkish Presidential Decisions in titles and content, differentiating from other sibling tools like search_cbgenelge and explicitly contrasting with Presidential Decrees and BKKs.
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 crucial guidelines: keyword-based search (not by decision number), use of descriptive Turkish terms, clarification of decision types, and query syntax examples. While it doesn't explicitly list when to avoid this tool, the context of sibling tools makes it 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?
With no annotations, the description discloses important behavioral traits: KHKs were abolished after 2017 but remain in force, and returns include KHK number, title, dates, and Official Gazette info. It does not cover pagination or error handling, but the core behavior is transparent.
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-structured with a brief intro, important notes, query syntax, examples, and return info. Every sentence serves a purpose; no 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 lack of output schema, the description mentions return fields. Parameter descriptions in schema cover pagination. The description could elaborate more on pagination behavior, but it is adequate for a search 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?
All 7 parameters have descriptions in the schema (100% coverage). The description adds value by providing query syntax examples, explaining the tam_cumle and aranacak_yer parameters, and showing how to use date range parameters with 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 clearly states it searches Turkish Decree Laws (KHK) in titles and content, distinguishing it from sibling tools for other legal documents. It specifies keyword-based search and provides context on KHK abolition.
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 'Search is keyword-based, NOT by KHK number' and advises using descriptive Turkish terms. It includes example queries and mentions leaving the query empty to list all KHKs, but does not explicitly state when to avoid 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?
No annotations provided, so description carries full burden. Describes two search modes and their behavior, including Boolean operators and semantic embeddings. Lacks details on potential side effects, auth needs beyond API key, or rate limits, but adds value beyond schema.
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?
Structured into clear sections (modes, examples) with no redundant text. Every sentence adds value: two sentences covering core purpose, then bulleted lists for modes and examples.
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 both search modes, required parameters, optional parameters with defaults, and output schema exists. The description is complete given the tool's complexity and richness of schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with good descriptions. The description adds context by explaining modes and providing examples, which enhances understanding beyond the schema. However, the schema already handles parameter semantics adequately.
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 within a specific law's articles using keyword or semantic search. Distinguishes from sibling tools like 'search_within_kanun' vs general 'search_kanun' by specifying 'within a specific law' and providing two distinct search modes.
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 usage guidance for both keyword and semantic modes, including examples and noting the OPENROUTER_API_KEY requirement for semantic search. However, does not explicitly state when to choose this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the behavioral disclosure burden. It explains the search behavior (keyword-based), query syntax, and what is returned. While it covers most aspects well, it could mention pagination or result limits more explicitly.
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 sections and bullet points, front-loading the purpose. While somewhat lengthy, every sentence contributes value. Minor redundancy in query syntax examples could be tightened, but overall good.
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 (though not shown), the description adequately covers all necessary aspects: purpose, usage, parameters, query syntax, and return fields. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value beyond schema definitions by explaining search philosophy, providing usage examples, and clarifying parameter meanings (e.g., aranacak_yer values). This goes beyond simply restating 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 it searches for Turkish laws (Kanun) in titles and content on mevzuat.gov.tr, with a specific verb and resource. It distinguishes from sibling tools like search_within_kanun, which is used to search within a specific law after finding its number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance that search is keyword-based, not by law number, with examples of correct and incorrect queries. Directs users to use search_within_kanun after obtaining the law number, clearly differentiating when to use this tool vs 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?
No annotations provided, so the description carries full burden. It discloses the PDF-to-Markdown conversion and that circulars are only available as PDF. However, it does not mention potential errors if PDF is inaccessible or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and an example, but slightly verbose. Every sentence contributes meaning 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's complexity, the description fully explains the workflow, parameter sources, and output format. The presence of an output schema lowers the burden, and the description covers all necessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value by explaining how to derive parameters from search results, with an example and explicit format requirements for the date 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 retrieves full content of a Turkish Presidential Circular in Markdown format from PDF. It distinguishes from sibling tools by specifying it's for circulars and directing to use search_cbgenelge first.
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 instructs to use 'search_cbgenelge' first to obtain the circular number and Official Gazette date, and provides a complete example workflow. The importance of the date parameter is emphasized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses return format (plain text, stripped HTML), warns about large documents, and outlines correct ID usage. Could mention network dependency but is overall transparent.
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?
Every sentence earns its place: purpose, format, warning, workflow, and instructions. Well-structured 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?
Covers all key aspects: input, output format, warnings, workflow, and alternative tool usage. Complete for a tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value by specifying ID format, giving an example, and clarifying it is not a law number. Exceeds baseline for high 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 retrieves full content of Turkish legislation, specifies source and output format, and distinguishes from siblings by referencing mevzuatId from search_mevzuat and warning about large documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow, warns when to use search_within_mevzuat instead for large documents, and clarifies that mevzuatId comes from search_mevzuat, not law numbers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that search is keyword-based, explains query syntax with Boolean operators and examples, and states return fields. It does not mention whether it is read-only or any rate limits, but the read-only nature is implied by the search operation. Overall, it provides sufficient behavioral context.
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-structured with a clear first sentence, an 'IMPORTANT' callout, query syntax, examples, and return values. Every sentence is informative and earns its place. It is concise yet comprehensive, with 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 tool's complexity (7 parameters, no required fields, no output schema details), the description covers all essential aspects: the type of regulations, how to query, date range, location, pagination, and what is returned. It provides enough context for an agent to use the tool effectively without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond schema by explaining query syntax with practical examples, clarifying the 'tam_cumle' parameter, and showing how to use date filters and search location. This extra guidance helps the agent form correct queries.
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 searches for institutional regulations ('Kurum ve Kuruluş Yönetmeliği') in titles and content. It specifies the dataset size (8686+ regulations) and gives concrete examples like Gümrük Yönetmeliği, İthalat/İhracat Yönetmeliği, distinguishing it from siblings that search other regulation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says search is keyword-based, not by regulation number, and recommends descriptive Turkish terms. It provides a clear usage context: 'Use for: Gümrük Yönetmeliği, İthalat/İhracat Yönetmeliği, and similar institutional regulations.' The 'IMPORTANT' alert further guides correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: two search modes, Boolean operators, case sensitivity, max results, API key requirement. Examples clarify usage.
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, front-loaded, uses headings for modes. Every sentence adds value. Examples are 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?
Covers all aspects: required inputs, mode selection, parameter details, examples. With 6 parameters and no annotations, description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all parameters (100% coverage). Description adds value with usage examples, operator uppercase requirement, and API key condition for semantic mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches within a specific statute's articles using keyword or semantic search. Distinguishes from siblings by specifying 'Tüzük' and requiring a statute number.
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?
Explains two modes and gives examples. Implicitly requires statute number (mevzuat_no). Does not explicitly compare to other tools like search_tuzuk, but provides context on mode 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?
No annotations provided, but description fully explains the hierarchical return structure and mentions the source domain. It does not disclose any potential side effects or rate limits, but for a read operation with no destructive actions, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a clear workflow. Every sentence adds value—no fluff. It is front-loaded with the main purpose and efficiently conveys all necessary 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 complexity of Turkish legislation and the number of sibling tools, this description is complete. It explains the return structure (with output schema present), provides compatibility notes, and offers a workflow. No gaps remain for an AI agent to understand how and when to use this 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 mevzuat_id is fully documented in the input schema, and the description adds critical workflow context: that it must come from search_mevzuat results, is a string ID not a law number, and provides an example. This goes 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 clearly states the tool retrieves the article tree (table of contents) of Turkish legislation from a specific source. It distinguishes itself from siblings by listing compatible legislation types and noting tools that return empty, providing clear differentiation.
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?
Explicit guidance on when to use (with specific legislation types like KANUN, CB_KARARNAME) and when not to (CB_KARAR, CB_GENELGE, TEBLIGLER). Provides a workflow: search_mevzuat → get mevzuatId → use this tool, and suggests it as a precursor to other tools like search_within_mevzuat or get_mevzuat_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden: it discloses the two search modes, API key requirement for semantic mode, boolean operator usage, and chunk-based splitting. No destructive or side effects are implied, and the behavior is clear.
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 well-structured with sections, examples, and important notes front-loaded. It is slightly verbose but every sentence adds meaning; no wasted words. It could be more succinct, but the clarity justifies the 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?
Given 7 parameters, an output schema, and no annotations, the description covers all essential aspects: search modes, prerequisites, parameter constraints, and mode-specific behavior. It is complete for an agent to correctly invoke the tool without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing examples for keyword and semantic queries, explaining the case sensitivity relevance, and clarifying that 'resmi_gazete_tarihi' is required from prior search results, which goes beyond bare 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 searches within a specific Presidential Circular using keyword or semantic search, differentiating it from sibling tools like 'search_cbgenelge' which finds circulars themselves. It also specifies the chunk-based document structure, making the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that 'resmi_gazete_tarihi' is required and should come from 'search_cbgenelge' results, providing a clear prerequisite. It also explains the two modes (keyword vs semantic) and gives examples, leaving no ambiguity about when to use each.
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?
Despite no annotations, the description details the internal process: fetches full document, splits into articles, applies Boolean keyword search, sorts by relevance, and specifies result fields. It does not mention rate limits or potential large data usage, but it is sufficiently transparent.
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 and concise: opens with purpose, then usage context, behavioral details, result format, workflow, and example. No extraneous information; 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 tool's complexity (4 parameters, existing output schema) and good annotations, the description covers all necessary aspects: input requirements, processing logic, output structure, and usage workflow. It is fully complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the schema: explains how to obtain mevzuat_id, provides detailed Boolean operator syntax with examples for keyword, and clarifies defaults and constraints for case_sensitive and max_results. With 100% schema coverage, the description still enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search within a specific legislation's articles'. It distinguishes from siblings like get_mevzuat_content by noting it is ideal for large legislation, and from other search_within_* tools by specifying the source domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Ideal for large legislation where get_mevzuat_content would return too much text.' Provides a step-by-step workflow and a concrete example, guiding the agent on correct invocation.
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:

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

Score Badge

Copy to your README.md:

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

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