Skip to main content
Glama
ShellFrameAI

AgentSecure Community

Official
by ShellFrameAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

agentsecure.get_policy_hint

Evaluate a proposed Mesh action against local agent policy without executing it; returns allowed/blocked status, reasons, and guidance for next steps.

Instructions

Evaluate a proposed Mesh action against the current local agent policy without executing it. Checks cannot, can_message (when a send_message target is supplied), requires_human_for, and sensitive markers in action/resource. Returns allowed, blocked, reason, action, sanitized resource, and allowed_next_step. This is guidance, not an authorization token or a guarantee about external permissions; existing approval records are not consulted. Use agentsecure.request_approval to record a review request, or agentsecure.policy.describe for HTTP network/secret configuration. Example: {"agent_id": "frontend-agent", "action": "send_message", "target": "backend-agent"}.

Input Schema

NameRequiredDescriptionDefault
actionYesNon-empty action label matched against mesh.agents policy, e.g. send_message or deploy_preview. Action/resource text is also checked for sensitive markers such as deploy or secret.
targetNoRecipient agent ID for a send_message check; defaults to empty. Only used with action=send_message to check can_message restrictions; not a hostname or URL.
agent_idYesNon-empty Mesh agent ID, e.g. backend-agent. Pass this session's AGENTSECURE_AGENT_ID value when set; it is not read automatically. IDs are caller-supplied local labels, not authentication credentials.
resourceNoOptional resource metadata; defaults to {}. Stored/returned fields are limited to action, environment, id, path, provider, repo, team, and type. Use non-secret scalar values or lists; other keys and top-level object-valued fields are dropped; list items are converted to scalars, and strings are truncated/redacted. Example: {"type": "code_file", "path": "src/app.py"}. For policy checks, the entire supplied object is examined for sensitive-action markers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / action / description
      Added value: +"Non-empty action label matched against mesh.agents policy, e.g. send_message or deploy_preview. Action/resource text is also checked for sensitive markers such as deploy or secret."
    • addedInput schema / properties / agent_id / description
      Added value: +"Non-empty Mesh agent ID, e.g. backend-agent. Pass this session's AGENTSECURE_AGENT_ID value when set; it is not read automatically. IDs are caller-supplied local labels, not authentication credentials."
    • addedInput schema / properties / resource / description
      Added value: +"Optional resource metadata; defaults to {}. Stored/returned fields are limited to action, environment, id, path, provider, repo, team, and type. Use non-secret scalar values or lists; other keys and top-level object-valued fields are dropped; list items are converted to scalars, and strings are truncated/redacted. Example: {\"type\": \"code_file\", \"path\": \"src/app.py\"}. For policy checks, the entire supplied object is examined for sensitive-action markers."
    • addedInput schema / properties / target / description
      Added value: +"Recipient agent ID for a send_message check; defaults to empty. Only used with action=send_message to check can_message restrictions; not a hostname or URL."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses non-execution, local-policy scope, which policy checks are performed, the returned fields, and the important limitation that this is not an authorization token or a guarantee about external permissions.

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 purpose and critical non-execution scope are front-loaded, followed by checked conditions, return values, limitations, alternatives, and an example. The paragraph is dense but free of filler and appropriately sized for a policy-evaluation tool.

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 no output schema and no annotations, the description supplies the missing context: it enumerates returned fields, states what is checked, and clarifies that existing approvals and external permissions are not covered. It is complete enough for an agent to invoke 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 already 100%, so the schema documents parameter meanings in detail. The description still adds value with a concrete example and by tying target to the send_message check and noting that action/resource text is examined for sensitive markers.

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 a specific verb and resource: evaluating a proposed Mesh action against the current local agent policy without executing it. It clearly distinguishes the tool from approval recording and network/secret policy inspection by naming those alternatives.

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 frames the tool as guidance rather than authorization, notes that approval records are not consulted, and tells the agent to use agentsecure.request_approval for review requests or agentsecure.policy.describe for HTTP network/secret configuration. This gives clear alternatives 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.

This server cannot be deployed

Other Tools