Fleet/Platform only. Register an HTTPS endpoint. Events: fiche.viewed, share.created, share.revoked, wifi.unlocked, quota.warning. HMAC SHA-256 in X-SesApp-Signature (t=unix,v1=hex of timestamp.body). Secret returned once. Max 5 endpoints. Requires Bearer.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS URL (http://127.0.0.1 allowed in DEV) | |
| events | No | Subset of events. Default: all. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure load, and it does so well: it reveals the HMAC SHA-256 signature format, that the secret is returned only once, and that at most 5 endpoints may exist. It stops short of describing failure behavior (e.g., when the 5-endpoint limit is exceeded) or whether registration triggers a verification request, but overall the side-effect profile is unusually transparent.
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?
Five short, information-dense sentences cover scope, resource, event vocabulary, signature mechanics, secret handling, capacity, and auth with no filler. The action is front-loaded and every clause earns its place.
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 no output schema, the description sensibly discloses the most important return behavior ('Secret returned once') and the endpoint capacity. It could add the response shape (e.g., endpoint id for later update/delete calls), but for a 2-parameter registration tool the provided context is sufficient for a competent agent to call it 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 coverage is 100%, so the schema already documents url and events. The description adds value by listing the valid event names (fiche.viewed, share.created, etc.) and clarifying the HTTPS requirement, which enriches the events parameter beyond the schema's generic 'Subset of events.'
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 opens with a specific verb and object: 'Register an HTTPS endpoint,' and enumerates the event types the endpoint can receive. This clearly distinguishes registering from sibling webhook tools like delete_webhook, list_webhooks, and update_webhook. The 'Fleet/Platform only' scope further narrows the purpose.
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?
The description states a scoping condition ('Fleet/Platform only') and authentication requirement ('Requires Bearer'), and the event list tells the agent what subscriptions can be configured. It does not explicitly name sibling alternatives such as delete_webhook or update_webhook for lifecycle operations, but the verb and resource make the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: fiches have create/get/list/update/delete, shares have create/list/revoke, webhooks have register/list/update/delete, and geocode/status/subscribe are separate supporting operations. There is no meaningful overlap between tools.
The majority of tools follow a clear verb_noun snake_case pattern such as create_fiche, revoke_share, and register_webhook. Minor deviations exist—status is noun-only, subscribe has no explicit object, and list_fiches pluralizes while create_fiche does not—but the naming remains predictable.
Fifteen tools is within the ideal range and each tool maps to a concrete operation needed for the service: fiche lifecycle, sharing, webhooks, and account management. No redundant or filler tools are present.
The tool surface covers full CRUD for fiches, share creation/listing/revocation, webhook registration/listing/update/deletion, and account subscription/status. Agents can complete the main workflows around creating, sharing, and managing access sheets without dead ends.