Skip to main content
Glama
harsh-simform

custom-zoho-project-mcp-server

select_portal_and_project

Select and validate a Zoho portal and project to set it as active for data retrieval. Multiple pairs can be selected; use switch_portal to move between them.

Instructions

Validate and select a portal/project, making it the active one. Multiple portal/project pairs can be selected this way without losing earlier ones — use switch_portal to move between already-selected pairs, list_selected_portals to see them all. Requires configure_oauth first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portal_idYes
project_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses that multiple portal/project pairs can be selected without losing earlier ones, that the new pair becomes active, and that OAuth configuration is required. It does not mention error behavior or whether selections persist, but the key stateful 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 three sentences with no filler. It front-loads the primary action, then adds stateful behavior and alternatives, then the prerequisite. Every sentence contributes useful guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter selection tool with an output schema, the description covers purpose, state accumulation, navigation between selections, listing, and the required OAuth prerequisite. Nothing essential for invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate, but it only references 'portal/project' without explaining how to obtain or format portal_id and project_id. The parameter names are self-evident, but the description adds little beyond what the schema already shows.

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 a specific verb and resource: 'Validate and select a portal/project, making it the active one.' It clearly distinguishes this from siblings by explaining that switch_portal is for moving between already-selected pairs and list_selected_portals is for viewing them.

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 gives explicit when-to-use guidance: select new pairs here, use switch_portal to move between existing ones, and use list_selected_portals to see them. It also states the prerequisite, 'Requires configure_oauth first,' so an agent knows the required setup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.