Provides tools to manage Palo Alto Networks Strata Cloud Manager (SCM) objects such as addresses, address groups, services, tags, security rules, and incidents through the SCM REST API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scm-mcp-server list my security rules"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Palo Alto Networks Strata Cloud Manager (SCM) 的 MCP server，通过 stdio 将 SCM REST API 暴露给 Claude、Cursor 等 AI 助手。
当前版本：Batch 1 MVP，共 111 个 MCP tool，覆盖对象管理、安全规则、安全配置文件、运维操作、IAM 五个域。
Python 3.11+
SCM 租户凭据：Client ID、Client Secret、TSG ID （SCM 控制台 → Identity → Service Accounts 创建）
Related MCP server: scm-mcp
git clone <this-repo>
cd scm-mcp-server
pip install -e ".[dev]"cp .env.example .env
# 编辑 .env，填入真实凭据.env 内容：
SCM_CLIENT_ID=your-client-id
SCM_CLIENT_SECRET=your-client-secret
SCM_TSG_ID=your-tsg-id
SCM_BASE_URL=https://api.strata.paloaltonetworks.com # 可选，此为默认值配置凭据后先跑自检，验证 token 获取和 SCM API 可达：
python -m scm_mcp_server.check预期输出：
[check] OK token obtained (first 8 chars: eyJ0eXAi...)
[check] OK GET /config/operations/v1/jobs → HTTP 200
[check] All checks passed.# 直接运行（stdio 模式，供 MCP 客户端连接）
python -m scm_mcp_server
# 用 MCP Inspector 调试
mcp dev scm_mcp_server/server.py编辑 ~/Library/Application Support/Claude/claude_desktop_config.json：
{
"mcpServers": {
"scm": {
"command": "python",
"args": ["-m", "scm_mcp_server"],
"cwd": "/absolute/path/to/scm-mcp-server",
"env": {
"SCM_CLIENT_ID": "your-client-id",
"SCM_CLIENT_SECRET": "your-client-secret",
"SCM_TSG_ID": "your-tsg-id"
}
}
}
}重启 Claude Desktop，在对话中询问 "列出可用工具" 确认 list_addresses 等工具已加载。
创建或编辑 .cursor/mcp.json：
{
"mcpServers": {
"scm": {
"command": "python",
"args": ["-m", "scm_mcp_server"],
"cwd": "/absolute/path/to/scm-mcp-server",
"env": {
"SCM_CLIENT_ID": "your-client-id",
"SCM_CLIENT_SECRET": "your-client-secret",
"SCM_TSG_ID": "your-tsg-id"
}
}
}
}重启 Cursor，在 Composer 中输入 @scm 确认工具可用。
标注 ⚠️ 的 tool 为写操作，立即生效，不可通过本工具回滚。
操作 | 资源 |
list / get | addresses, address_groups, services, service_groups, tags, application_groups, external_dynamic_lists |
⚠️ create / update / delete | 同上 7 类资源 |
操作 | 资源 |
list / get | security_rules, decryption_rules, app_override_rules, dos_protection_rules |
⚠️ create / update / delete | 同上 4 类规则 |
⚠️ move | security_rules, decryption_rules, app_override_rules（调整规则顺序） |
list / get 操作，涵盖：
anti_spyware_profiles, anti_spyware_signatures, data_filtering_profiles, data_objects, decryption_exclusions, decryption_profiles, dns_security_profiles, dos_protection_profiles, file_blocking_profiles, http_header_profiles, profile_groups, url_access_profiles, url_categories, url_filtering_categories（仅 list）, vulnerability_protection_profiles, vulnerability_protection_signatures, wildfire_anti_virus_profiles
操作 | 工具 |
只读 | list_jobs, get_job, list_config_versions, get_config_version, get_running_config_version |
⚠️ 写 | load_config_version（加载版本）, push_candidate_config（高风险：下发到真实设备）, delete_candidate_config |
操作 | 资源 |
list / get | service_accounts, roles, access_policies |
⚠️ create / update / delete | service_accounts |
⚠️ create / delete | access_policies |
⚠️ reset | reset_service_account_secret（重置 secret） |
完整入参/出参映射见 DESIGN.md。
# 运行全部单元测试
pytest -v
# 语法自检（AST parse 全部 .py）
python scripts/syntax_check.py
# 路由完整性验证（路由表 key == descriptor 名称集合）
python scripts/route_integrity.py
# stdio 冒烟（需配置 .env 凭据）
python scripts/smoke_stdio.pytool 的 schema 来源为 ../pan.dev/openapi-specs/scm/（相对本仓库父目录）：
openapi-specs/scm/
auth/AuthService.yaml
config/
sase/objects/objects-june.yaml
sase/security/security-services-R2-2026.yaml
sase/operations/config-operations-march.yaml
iam/
ServiceAccounts.yaml Roles.yaml AccessPolicies.yaml禁止修改规范文件；如需更新请从上游 pan.dev 仓库同步。
Get an address object by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get an address object by ID', implying a read-only operation, but lacks details on idempotency, permissions, or side effects. For a simple getter, this is minimal but does not disclose additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It is front-loaded with the essential information. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with full schema coverage, the description is minimally adequate. It does not explain the response format or error conditions, but given the simplicity, it is acceptable. However, compared to richer examples, it lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the only parameter 'id' has a description 'Object UUID'. The description adds no extra meaning beyond the schema, just 'by ID' which is implicit. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an address object by ID' clearly states the action (Get), the resource (address object), and the method (by ID). It distinguishes from sibling tools like list_addresses which retrieves multiple addresses, and get_address_group which retrieves a group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not mention that list_addresses should be used to retrieve all addresses or that this tool is for a single address by UUID. No when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an address group by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only implies a read operation ('Get') but does not disclose behavioral traits like whether it returns the full object, any side effects, or authentication requirements. The absence of an output schema leaves the agent uncertain about the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is adequate but not rich. It could be improved by specifying what an address group contains (e.g., name, members) to help the agent understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter 'id' with description 'Object UUID'). The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('an address group'), and the method ('by ID'). It distinguishes from sibling tools like 'get_address' or 'get_service', which retrieve different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. For instance, it doesn't clarify when to use 'get_address_group' versus 'list_address_groups' or how it differs from other get tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a service object by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation through the word 'Get', but lacks explicit behavioral details such as authentication requirements or potential side effects. With no annotations, the description should be more transparent, but the simplicity of the tool (a simple retrieval) mitigates this need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description could be more complete by indicating what fields are returned or mentioning error cases. However, for a simple get-by-ID tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'id' as 'Object UUID', and the description adds no further meaning. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'service object by ID', indicating a retrieval operation. It distinguishes from sibling tools like get_service_group but could be more specific about the nature of a service object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternative tools like list_services or get_service_group, nor does it mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a service group by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations, so description carries full burden. Simply states 'get', which is adequate for a read operation, but no details on error handling or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple retrieval tool with one parameter. Lacks output specification, but reasonable given no output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Object UUID'. Description adds no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get', resource 'service group', and method 'by ID'. Distinguishes from siblings like list_service_groups and get_service by specifying the parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_service_groups or get_service. Agent must infer usage from param name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a tag object by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic function and does not describe side effects, permissions, or return characteristics. The agent cannot infer if this is read-only or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. However, it could be more informative while remaining concise, such as hinting at the returned object structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, no nested objects, no output schema), the description is minimally adequate. It conveys the core purpose but does not fully cover what the agent needs for successful invocation, such as the format of the returned object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, but the description adds no additional meaning beyond what the schema already provides ('Object UUID' vs 'by ID'). Baseline score of 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'tag object by ID', which distinguishes it from list_tags and other get tools for different resources. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_tags or other get tools. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List address objects
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by object name | |
| limit | No | Page size (default 200) | |
| device | No | Container: device name | |
| folder | No | Container: folder name | |
| offset | No | Pagination offset (default 0) | |
| snippet | No | Container: snippet name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose that the tool is read-only, supports pagination, or filtering. The schema implies these behaviors, but the description adds no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified and merely restates the tool name. It does not front-load useful information and fails to earn its place as a clarifying element.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too minimal. It omits pagination behavior, container usage, and return value structure, making it insufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List address objects' is a tautology of the tool name 'list_addresses'. It does not specify what constitutes an address object or differentiate from sibling tools like list_address_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_address or list_address_groups. No exclusions or context for filtering are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List address group objects
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by object name | |
| limit | No | Page size (default 200) | |
| device | No | Container: device name | |
| folder | No | Container: folder name | |
| offset | No | Pagination offset (default 0) | |
| snippet | No | Container: snippet name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'List', which implies read-only but does not explicitly state behavior like pagination, result limits, or that filtering is optional. Fails to disclose that the tool may return a large set of objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (six words) but lacks substantive information. While concise, it is under-specifying for a tool with 6 optional parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters and no output schema, the description is insufficient. It does not explain return format, pagination behavior, or how container parameters affect results. Leaves agents without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'address group objects'. It distinguishes from sibling tools like 'get_address_group' which retrieves a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'get_address_group' or 'list_addresses'. No context on prerequisites or filtering by container.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List service group objects
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by object name | |
| limit | No | Page size (default 200) | |
| device | No | Container: device name | |
| folder | No | Container: folder name | |
| offset | No | Pagination offset (default 0) | |
| snippet | No | Container: snippet name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'List service group objects' without mentioning pagination, filtering behavior, authentication needs, or side effects. The schema parameter descriptions partially compensate, but the description adds no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at a single sentence with no fluff. It front-loads the core action and resource. While it could include more detail, it efficiently conveys the minimum necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 optional parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return format, how pagination works, or the semantics of container parameters (device, folder, snippet) beyond what the schema provides. The agent lacks necessary context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter (name, limit, device, folder, offset, snippet) already has a clear description. The tool description does not add any additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List service group objects' clearly states the verb (list) and resource (service group objects), making the tool's purpose identifiable. However, it does not differentiate from sibling tools like 'get_service_group' or 'list_services', missing an opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_service_group' or 'list_services'. There are no prerequisites, exclusions, or context hints to help the agent decide, leaving it to infer from the input schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List service objects
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by object name | |
| limit | No | Page size (default 200) | |
| device | No | Container: device name | |
| folder | No | Container: folder name | |
| offset | No | Pagination offset (default 0) | |
| snippet | No | Container: snippet name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'list' without indicating whether the operation is read-only, safe, or has any side effects. No mention of pagination, rate limits, or required permissions, which is insufficient for a mutation-free list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It earns its place by being minimal and direct, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and moderate complexity (container-based filtering), the description is too minimal. It does not explain the return format, how containers work, or any important usage details like default limit. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate. No explanation of how parameters interact (e.g., name filtering alongside container filters) is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List service objects' clearly states the action (list) and the resource (service objects), distinguishing it from sibling tools like 'get_service' which retrieves a single service. However, it could be more specific by mentioning it returns multiple objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_service_groups' or 'list_addresses'. The description does not provide any context about filtering or container-based usage, leaving the agent without direction on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tag objects
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by object name | |
| limit | No | Page size (default 200) | |
| device | No | Container: device name | |
| folder | No | Container: folder name | |
| offset | No | Pagination offset (default 0) | |
| snippet | No | Container: snippet name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a read operation, but no details are given about pagination behavior, performance implications, or whether it requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but under-specified. A single phrase does not earn its place; more structured information is needed for utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention return format or any behavioral details. For a list tool with 6 parameters, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions, so the baseline is met. The tool description does not add any additional meaning or context beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List tag objects' only slightly expands on the tool name. It does not specify what kind of tags (e.g., firewall tags) or how it differs from the sibling tool 'get_tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_addresses' or 'get_tag'. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_addressget_address_groupget_serviceget_service_groupget_taglist_address_groupslist_addresseslist_service_groupslist_serviceslist_tagsEach tool targets a distinct combination of object type and action (get vs list), leaving no ambiguity. The five object types are clearly separated.
All tool names follow a consistent 'verb_object' pattern with underscores, using 'get_' for single retrieval and 'list_' for bulk retrieval, all lowercase.
10 tools covering five object types with two operations each is well-scoped for a read-only interface, fitting the typical 3-15 range.
Only read operations are provided; missing create, update, and delete tools severely limits the ability to manage objects, making the surface incomplete for a full management scenario.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Let AI agents query data and act across all your business apps via MCP.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zm1990s/vibe-coding-scm-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
