Zuar Portal Blocks MCP Server

Server Quality Checklist

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

Latest release: v4.3.0
Disambiguation4/5
The tools target distinct aspects of portal management (blocks, queries, datasources, config, version control), and descriptions clarify boundaries. Overlap exists between create_block and create_resource, but descriptions explain the specialization.
Naming Consistency4/5
The naming convention is predominantly verb_noun in snake_case (e.g., create_block, delete_resource). Minor deviations include 'naming' (noun) and 'migration_preflight' (noun_verb), but overall pattern is consistent.
Tool Count2/5
With 38 tools, the set is large compared to the typical 3-15 range. While the domain is broad, the number feels excessive and may overwhelm agents, reducing coherence.
Completeness5/5
The tool set covers the full lifecycle of portal management: CRUD for all resources, blocks, queries, datasources, themes, version control, validation, migration, access control, and configuration. No obvious gaps are present.
Average 4.4/5 across 38 of 38 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 71 commits in the last 12 weeks
- Last stable release on July 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: 'rotates the credential the current session signs in with' and 'Passwords are never logged or echoed back.' This goes beyond annotations, but could mention immediate effect on the session.
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 waste. Every sentence adds necessary 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?
No output schema, but description hints at no logging. For a mutation tool, typical return is success. It covers prerequisites and safety. Minor gap: does not specify what the response includes (e.g., success message).
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 descriptions for each parameter. The description adds context about 'confirm=true' being required and password sensitivity, but this mostly reinforces 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?
The description clearly states 'Change the authenticated user's password', specifying it affects the current user. This is distinct from sibling tools like describe_resource or execute_query, which serve different purposes. The title reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires 'admin writes enabled (PORTAL_ALLOW_ADMIN_WRITES=1) and confirm=true', providing clear conditions for use. It does not offer alternatives or explicitly state when not to use, but the conditions are 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 provide readOnlyHint and openWorldHint. The description does not add any behavioral details beyond what annotations convey. 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?
Single sentence immediately stating the tool's purpose. Front-loaded with the key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, annotations for safety, and no output schema, the description fully informs the agent of what the tool does. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to provide additional semantics. Schema coverage is 100% and the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'portal's configuration document'. It is specific and distinguishes from sibling tools like 'update_config' and 'reload_config'.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., get_resource, describe_resource). The read-only nature is implied but not contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds beyond this by stating it returns two types of data (groups and permissions) in a single call, which is valuable behavioral context not in 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?
Two concise sentences with no wasted words. The first sentence clearly states the purpose and the second provides distinguishing context. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description adequately explains what is returned and how it compares to a sibling. Could mention error handling or return format, but not critical.
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 'User UUID' description. The tool description does not add further meaning to the user_id parameter beyond what the schema already provides. Baseline of 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?
The description clearly states it returns groups and permissions in one call, using specific verbs ('Return') and resource types ('groups', 'permissions'). It also distinguishes itself from get_resource tool by contrasting what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'in one call' and references get_resource as an alternative for getting the user record itself, providing context when to use this tool. However, it does not explicitly state when not to use it or cover other scenarios.
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 declare readOnlyHint as true, and the description reinforces this by calling it a 'pure function', implying no side effects. It adds behavioral detail about how display names omit kind words for certain resource types, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but packs substantial detail. It is front-loaded with the naming convention and action dispatch. While slightly long, each part earns its place.
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?
The description covers input semantics well but lacks detail on the output format (e.g., slug, tags, grade) and error conditions. Given the lack of an output schema, the description could be more complete about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although parameter schema coverage is 100%, the description adds significant meaning by explaining scope codes (e.g., HC=healthcare), kind values, and the source facet. It clarifies how parameters interact (e.g., 'omit the kind word for certain resources'), which is 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 defines the tool as a pure function for a naming convention with two specific actions: suggest (generates names) and parse (decomposes names). It distinguishes itself from sibling tools by being a dedicated naming utility, not a general-purpose tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use each action (suggest vs. parse) and advises preferring suggest over hand-naming. However, it does not provide explicit exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: explains that scratch records are excluded, and with version control, it compares against baseline. Also clarifies the idempotent nature (score same data yields same scores) and that update_baseline=true saves state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses clear, direct language. It is somewhat lengthy but each sentence adds value. Minor wordiness in the loop discipline statement but overall well-structured.
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?
Covers the main points: scoring criteria, exclusion of scratch records, and baseline delta. However, with no output schema, it could hint at the return format (e.g., list of scores) to better aid invocation. Adequate but not 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 description coverage is 100%, so baseline is 3. The description repeats the schema descriptions verbatim, adding no extra meaning beyond what's already in the input 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 scores blocks and pages 0-100 on mechanically checkable aspects, and distinguishes itself by clarifying what 100 means (not 'well designed'). It also mentions the baseline delta feature, setting it apart from siblings like snapshot_portal and validate_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (scoring with version control) and what is excluded (scratch-marked records, handled by cleanup_scratch). Provides a workflow: score, improve, re-score, and only update_baseline after verified improvement. This gives clear guidance on tool usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds significant detail: it enumerates specific checks (malformed records, dangling references, unscoped SQL, datasource hygiene) and explicitly states 'Fixes nothing'. This elaborates on the read-only nature beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the action and listing categories. It is somewhat long but each sentence adds value. Minor redundancy: 'report anything that would break or render wrong' then lists specifics. Still, efficient for the detail provided.
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 complexity of the tool (many checks) and no output schema, the description does not specify the output format (e.g., structure of issues, counts, severity). The agent may need to infer how results are returned. Somewhat incomplete for a comprehensive validation 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?
The input schema has one optional parameter 'limit' with a description that explains it caps issues returned. The tool description does not add any further parameter semantics. Since schema coverage is 100%, 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 explicitly states it sweeps all portal components to report structural issues, dangling references, mass-write SQL, and datasource hygiene. The title 'Validate portal integrity (read-only)' reinforces the purpose. It clearly distinguishes from siblings like 'validate_block' which likely validates a single block.
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 says 'run it after bulk changes or on a schedule to catch latent breakage before users do', providing clear context. It also states 'Fixes nothing', which helps set expectations. However, it does not explicitly mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description adds critical details: no snapshot/rollback, best-effort classifier for unscoped writes that fails closed, and parameter dependencies. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph but front-loaded with purpose. Every sentence adds value, though it could be more structured (e.g., bullet points). Not overly verbose.
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 complex tool with 7 params, no output schema, the description covers safety, parameter usage, and special conditions comprehensively. Leaves little ambiguity.
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 meaning: explains how to pass params/params_list, the role of confirm, allow_unfiltered, and ignore_sql_errors. Provides usage context beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a saved db_modification (INSERT/UPDATE/DELETE) by name, which is specific. It doesn't explicitly differentiate from siblings like execute_query, but the context implies this is for writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidelines: requires data writes enabled, confirm=true, and explains safeguards for unscoped mass writes. Warns about no snapshot/rollback. Doesn't explicitly state when not to use, but context is adequate.
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?
Adds significant context beyond annotations: describes coverage verification, reporting of failed exports, and the requirement PORTAL_VC_DIR. This helps the agent understand the tool's thoroughness and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action and each sentence adds value, though slightly verbose. Could be slightly more concise without losing 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 purpose, usage, behavior, and requirements well. Lacks explicit output format, but mentions reporting of staged counts and failures, providing adequate context for a tool without an output schema.
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 coverage and a single optional parameter, the description adds minimal value beyond restating the default value. 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 it exports all content resources and datasources to git and commits. It specifies the scope ('every content resource') and the action, distinguishing it from sibling version control tools like vc_diff or vc_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance ('Run once to seed history, or anytime to capture a checkpoint'), but does not explicitly mention when not to use or list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Detailed explanation of pagination envelope, byte-capping, projection auto-fallback, and null total on first pages. Goes far beyond the readOnlyHint and openWorldHint 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?
Front-loaded with purpose, but middle section is dense and somewhat run-on. Still efficient given the complexity.
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 notable behaviors: pagination, byte cap, projection, performance hints, and fallback behavior. Adequately complete for a complex list 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%, so baseline 3. Description adds usage context for only_names vs fields and explains when to use each, improving over 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 states 'List records of a resource' with specific examples (block, datasource) and a use case (find UUID before authoring). It clearly distinguishes from siblings like find_resource.
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?
Mentions 'use this for discovery' but does not explicitly list when not to use or compare with alternative siblings like find_resource or get_resource.
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 provide readOnlyHint and openWorldHint. Description adds transparency about sampling defaults, caps on rows, and output structure. 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 and key details. No redundant information. 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?
With no output schema, description compensates by listing both statistical outputs and raw rows. Covers enough for typical profiling tasks. Could mention performance considerations but not mandatory.
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%, so parameter descriptions are already complete. Description adds value by explaining defaults and the effect of sample_rows=0, compensating beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool samples a datasource and returns per-column statistics plus sample rows. Uses specific verbs and lists outputs, distinguishing it from sibling tools like describe_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is for designing filters, choosing chart dimensions, etc., giving clear usage context. Lacks explicit exclusions or alternatives, but the use case is well-targeted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the readOnlyHint annotation by stating validation without writing. It adds valuable behavioral details such as the return shape {valid, errors, warnings} and the grandfathered error splitting with against_block_id, which go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information in two sentences. It front-loads the purpose and proceeds to list behaviors. While clear, it could be slightly more structured for scanning.
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 (8 parameters, no output schema, nested objects), the description thoroughly covers the tool's behavior, return format, special cases (grandfathered errors), and references to sibling tools. It is complete and self-contained.
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 each parameter is documented in the schema. The description adds context for against_block_id (grandfathered errors) but does not need to repeat schema details. Baseline score 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 validates a block using the same rules as create_block/update_block without writing. It lists specific footguns it flags, distinguishing it from its write counterparts.
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 using it to iterate on block payloads during development. It does not explicitly state when not to use, but the context of siblings (create_block, update_block) provides implicit guidance. The grandfathered error mechanism is explained.
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?
Adds extensive behavioral context beyond annotations: dry-run default, matching criteria, deletion safety checks, and permanent vs restorable deletes. Contradicts nothing in 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?
Three well-organized paragraphs, each serving a purpose. No redundancy, all sentences add value. Could be slightly more concise but acceptable given depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers dry-run report contents and deletion behavior comprehensively. Covers standard use cases. Missing pagination or performance notes, but adequate for tool complexity.
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%, so baseline is 3. Description adds extra meaning: explanations of default values, behavior of confirm, and conditions for deletion. Compensates with richer context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as scanning for disposable records by specific naming/tag conventions. It explicitly states the verb 'sweep' and the resource 'scratch leftovers', distinguishing it from siblings (no other sweep 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?
Provides clear when-to-use guidance: for cleaning up temporary records from loops. Mentions dry-run default, confirm=true for actual deletion, and safety checks. Implicitly contrasts with delete_resource by referencing 'same gated delete path'. Lacks explicit when-not-to-use, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds beyond annotations: case-insensitive substring match, exact-id match, default kinds (non-admin), optional tag filter, and pagination (limit, offset). 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 3-4 sentences, front-loads the purpose, and includes all necessary details without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema, annotations, and 100% schema coverage, the description is remarkably complete. It covers search behavior, defaults, optional filters, and pagination, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining default kinds (non-admin), substring/exact-id behavior, default limit of 50, and tag as optional filter. This provides useful context not inferable from 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?
Description clearly states it searches records across resource kinds by name, with a specific use case (finding a query without listing all collections). It distinguishes from siblings like list_resource and get_resource by specifying substring/exact-id matching and default kinds.
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 (search by name/tag without listing collections) and how to narrow results (kinds, tag, limit, offset). However, it does not explicitly state when not to use or mention alternatives, which would make it 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?
Annotations already declare readOnlyHint=true, so no risk of misinterpretation. The description adds value by detailing the contents of the response (severities and conventions text), enhancing transparency beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The first sentence states the core functionality, and the second provides usage context. Perfectly front-loaded and efficient.
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 a simple read operation with no parameters and no output schema, the description fully covers what the tool returns and its purpose. No gaps are evident.
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 0 parameters with 100% schema description coverage, so no parameter description is needed. The baseline for 0 params is 4, and the description adds no redundant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and the resource 'active block-authoring rules', and explicitly states what is returned (severities and conventions text). It also distinguishes from sibling tools by noting the relationship to create_block/update_block enforcement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool: 'Read this to see what create_block/update_block will enforce.' It provides clear context but does not explicitly mention when not to use or list alternatives, which is acceptable for a simple read tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; description reinforces with 'Read-only' label and adds critical context about row limit (1,000 default) and truncation behavior, plus warning about context budget and unlimited usage (limit:0). 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?
Concise, front-loaded with main action, each sentence adds essential information. 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?
Despite no output schema, description covers key behaviors: return results, truncation note, parameter usage. For a simple read-only tool with 3 parameters, it is adequately 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 coverage is 100%, baseline 3. Description adds value by explaining the purpose of each parameter beyond schema: params as a map, limit meaning (default, cap, unlimited), and query_id identification. Goes beyond 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?
Description explicitly states 'Run a saved query by id and return its results' with specific verb and resource. It clearly distinguishes from sibling tools like run_db_modification (write) and list_resource (listing resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use, how to pass parameters via a name-value map, and how to control row limits with default cap and unlimited option. Lacks explicit mention of alternatives but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context about what fields are shown (path, write fields, etc.) and the effect of omitting the resource parameter. No contradictions, but some behavioral details like error cases or response format are absent.
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; each sentence adds value and is front-loaded with the tool's purpose.
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 tool with one optional parameter and no output schema, the description fully covers its operation and use case, including the behavioral nuance of omitting the resource parameter.
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%, and the description adds valuable context that omitting the resource parameter lists all resources, which exceeds the schema's documentation.
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 shows a resource's path, write fields, required-to-create fields, supported verbs, and risk domain, and distinguishes it from siblings like list_resource by mentioning the ability to list all resources when omitting the parameter.
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 recommends calling this before create_resource/update_resource, providing clear when-to-use guidance and implying it should not be used for other purposes.
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?
Descriptions add context about gating version-specific endpoints beyond annotations, which already mark it as read-only and open-world. 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, no waste, front-loaded with key purpose.
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?
Fully sufficient for a no-parameter tool with good annotations. Explains use case and provides alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema covers everything. Description doesn't need to add param details, baseline 4 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?
Clearly states 'Fetch the portal version and about info' with a specific verb and resource. Distinguishes from sibling check_connection by noting its different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to gate version-specific endpoints) and provides an alternative (check_connection).
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:

[![zuar-portal-mcp MCP server](https://glama.ai/mcp/servers/patrickdeanfox/zuar-portal-mcp/badges/card.svg)](https://glama.ai/mcp/servers/patrickdeanfox/zuar-portal-mcp)

Score Badge

Copy to your README.md:

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

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