Every call to your workspace's MCP endpoint runs as the Growee user who authorized it, inside that workspace. Reads are checked record by record against each area's own view rule, writes run the app's own authorization, a static token is limited to the tools on its allowlist, and free workspaces are metered at 1,000 successful tool calls a month.
Every call to your workspace's MCP endpoint runs as the Growee user who authorized it, and what it can do is bounded by that user's own permissions.
One endpoint per workspace. Each workspace connects to its own MCP endpoint, https://{workspace}.api.growee.net/mcp/restify. The workspace can also be named with a ?tenant= parameter on the same path.
Transport security. Every Growee response, the MCP endpoint included, is sent with HTTP Strict Transport Security for the domain and its subdomains.
AI employees run as themselves. When an AI employee runs, it authenticates as its own Growee user with a token minted for that run, so it passes the same permission checks a person would.
The public documentation server
Growee also runs a public documentation MCP server. It answers product questions and can create a new workspace for an agent, the same kind of new workspace the public sign-up page creates. None of its tools read or change the records inside an existing workspace.
Authentication: OAuth and static tokens
There are two ways to connect a client, and they behave differently. An OAuth sign-in ties the connection to a person and expires. A static MCP client token does not expire, and carries the tool allowlist you gave it.
OAuth sign-in
The flow. Connecting an AI app uses the OAuth authorization code flow with PKCE (S256 required), discovery metadata, and RFC 7591 dynamic client registration, on a Laravel Passport server.
Consent before connection. Before a connection is created you see a consent screen that names the app asking, shows the Growee account you are signed in as, lists what the app will be allowed to do, and gives you Cancel and Authorize.
Token lifetimes. OAuth access tokens last 10 minutes and refresh tokens last 20 days.
Registered clients. Apps that register through dynamic client registration are public clients with no client secret, so the S256 code challenge is what binds an authorization code to the app that asked for it. Registration accepts callback addresses on claude.ai, claude.com and chatgpt.com, or a loopback address with an explicit port.
Static MCP client tokens
Who can create one. Any member of the workspace can create a static token for themselves, and what it reaches is bounded by that person's own permissions. A workspace-level switch that turns MCP off for everyone is not yet shipped.
Pick the tools, or grant every tool. You can create a static MCP client token in Settings, Integrations, MCP Client Tokens, tick exactly which tools it may call, or grant every tool with a wildcard. That is the Settings path; the Claude Code skill mints its own connection token, and that token carries every tool.
How the secret is stored. Static tokens are stored as SHA-256 hashes, and the plain secret is shown once, at creation.
What the list shows. The token list shows each token's name, how many tools it may call, and when it was last used, and you can delete a token from that screen.
No expiry, no IP allowlist. A static MCP client token has no expiry date and no IP allowlist: it works until someone deletes it or regenerates its secret.
The link in Settings carries a token. The connection URL shown in Settings carries your sign-in token, so treat that link like a password. It stops working when you sign out of Growee. For a headless client, create a static MCP client token instead; its link carries that token.
What an assistant can and cannot do
Two lists, both written from the code that ships today rather than from a roadmap.
What an assistant can do
Sign in through the OAuth authorization code flow with PKCE (S256 required), see a consent screen naming the app and your account, and hold an access token for 10 minutes with a refresh token for 20 days.
Connect instead with a static MCP client token that is limited to the tools you tick, or granted every tool with a wildcard.
Connect a terminal client through the Claude Code skill, which mints its own connection token carrying every tool.
Discover which areas of your workspace exist, what operations each has, and run one, through four wrapper tools plus three read-only helpers.
List records in the areas whose listing tool is switched on, with every returned record checked against that area's own view rule first.
See the fields an area lets your role see: 14 of the 75 areas declare field-level visibility rules, and on employees the salary and internal-cost fields need the matching permission.
Run an area's report getters where the area switches getters on: 14 of the 75 do, and the sensitive ones re-check the caller's permission in their own handler.
Create and update records, with the app's own authorization check running before the write, the same check the REST API runs.
Run actions the app exposes, such as sending an email to a lead or marking an invoice paid, each of which checks the caller's permission in its own handler.
Delete records in the 23 of 75 areas that expose a delete tool, each switched on by a role permission.
Attach a large file by receiving a short-lived pre-signed upload URL and uploading straight to storage, instead of sending bytes through the tool call.
Make 1,000 successful tool calls a month on the free plan, per workspace, with the cap lifted on any paid plan.
What an assistant cannot do, as shipped
Run against a workspace you are not a member of: the call is refused unless you are a member of the workspace named in the URL, and the 116 workspace-scoped models carry a global query filter on the workspace id.
Fall back to a different workspace when the one named in the URL does not exist: that is a 404.
Run an operation that is missing from its static token's allowlist: the allowlist is checked when the operation runs, not just when the tool list is built.
Read MCP client tokens through MCP: that area has listing and single-record reads switched off, and no token value is declared as a field.
Keep working after its static token is deleted: the delete is policy-checked and removes the row, so the token stops authenticating on its next use.
Start a drip sequence on a campaign that is still in draft: drip sending selects active campaigns, and a campaign is created in draft.
Reads, writes and deletes
Every call runs as your own Growee user inside your tenant: reads return what your role can already see, writes run the app's own permission checks, and a static token is limited to the tools on its allowlist. Underneath that sentence, here is what each half means area by area.
Reads are checked at two levels
Each area decides whether its listing tool exists at all: 54 of the 75 areas inherit the framework's open default and 21 set their own rule. Every record a listing returns is then checked against that area's own view rule before it leaves the server, and 29 areas narrow the query on top of that. On some areas that view rule is passed by any member of the workspace, so read narrowing is a per-area answer.
Where an area does branch by role, it branches the way the app does: on holidays, timesheets and meetings a manager sees the team, a direct-report manager sees their reports plus themselves, and everyone else sees their own records. Some areas hide individual fields as well: 14 of the 75 declare field-level visibility rules, and on employees the salary and internal-cost fields need the matching permission.
Creates and updates run the app's own checks
Create and update calls run the app's own authorization check before they write, the same check the REST API runs. 60 of the 75 areas expose at least one write tool. Four of them switch a create or update on at the area level and the rest are gated on a role permission, often paired with a per-tenant CRM entitlement. Delete tools exist on 23 of the 75 areas, and each one is switched on by a role permission.
An assistant can also run the actions the app exposes, such as sending an email to a lead or marking an invoice paid. Actions are reachable where the area switches actions on, and these actions check the caller's permission before they run: sending a lead email requires the CRM permission, marking an invoice paid requires the invoicing permission. On the campaign side: campaigns are created in draft by default, and drip automation only starts sending once you activate them.
The tool surface
The server exposes seven tools: four that let an assistant discover which areas exist, what operations each has, and run one, plus three read-only helpers for account setup guidance, configuration and product documentation. Running an operation re-checks the connection's tool permission at execution time, not just when the tool list is built. Besides tools, the server exposes two read-only resources: assistant guidance about Growee, and the configuration payload the web app itself loads, which carries the workspace's own reference lists, such as departments, positions, roles, holiday policies and expense categories, with every row checked against that area's own view rule before it is returned, plus the workspace's current plan and its seat counts.
Record content an assistant reads is what your users typed into Growee; the server returns it as data and does not rewrite or filter it for the model, so treat it as untrusted input in the client, as with any MCP server.
Workspace isolation
A filter on the query, not a convention. Workspace-scoped records carry a workspace id, and every query on a workspace-scoped model is filtered to the workspace resolved for the request. 116 models carry that filter.
Membership on every call. The call is refused unless you are a member of the workspace named in the URL.
No silent fallback. Naming a workspace that does not exist returns 404 rather than falling back to another one. With no workspace in the URL, the endpoint uses your first workspace membership, and refuses the call if you have none.
Then the per-record check. On top of the workspace filter, every record a listing returns is checked against its area's own view rule before the response leaves the server.
Metering and limits
MCP is free on every plan, and any paid plan lifts the monthly cap, not just a paid CRM plan. The free CRM stays free up to 100 leads and one CRM seat. See pricing for the plans themselves.
The free-plan meter. On the free plan an assistant can make 1,000 successful tool calls a month. The count is per workspace, shared by everyone in it, and resets at the start of the next calendar month.
What counts. Only successful tool calls count. Listing the tools, connecting, and calls that fail do not.
What a refusal looks like. A call past the cap is refused with HTTP 429 and a body that says how many calls were used, the cap, when it resets, and where to upgrade.
Throttles on the connection paths. Dynamic client registration is limited to 5 requests a minute, minting a connection token to 5 a minute, and the public documentation server to 60 a minute.
Logging and attribution
A per-call log of MCP requests is not shipped yet. On the 47 models that keep creator and editor columns, records created or updated through an assistant carry your Growee user as their creator and last editor, and each static MCP client token shows when it was last used. Not every area keeps those columns. That is current-state attribution rather than a record of each request.
An OAuth-connected app has no last-used timestamp today, so the last-used column applies to static tokens.
Revocation and offboarding
Deleting a static token. Deleting an MCP client token removes it immediately, and it stops working on its next use. Regenerating one invalidates the old secret at once. A static MCP client token is managed by the person it belongs to: the token screen lists your own tokens and the delete runs against them.
Offboarding, stated plainly. A static token is deleted by the person it was issued to, from Settings. Revoking a person's tokens when they are archived, and an admin screen that lists and revokes other people's tokens, are not yet shipped. OAuth grants end by expiry.
Ending an OAuth connection. Ending an OAuth connection from inside Growee is not shipped yet. An access token lasts 10 minutes and a refresh token 20 days, so a connection that is left unused stops working once its refresh token expires; an app that keeps refreshing keeps its access.
Signing out is not revocation. Signing out of the Growee web app does not revoke MCP client tokens or OAuth connections; they are ended by deleting the token or by the OAuth token expiry.
Where the endpoint runs
The application server that answers MCP requests runs on AWS in the EU, in Ireland. For the rest of Growee's hosting and security posture, including data residency, encryption at rest and in transit, the subprocessor list, backups and the independent penetration test, see the Trust Center.
AI employees
Growee does not ship any AI employee turned on. Nothing we ship is enabled by default: an employee record is a person unless someone marks it as an agent, and each integration an agent uses has to be connected first.
Once configured, an agent runs as its own Growee user with a token minted for that run, so it passes the same permission checks a person would. The honest shape of that surface: a configured agent also carries the four discovery-and-execute tools on every run, so what bounds it is its own user's permissions rather than a per-integration list of tools.
Questions to ask any vendor about its MCP server
These are the questions we would ask a vendor, with Growee's own answer under each one, including the ones where the answer is not yet. For which HR systems ship a server at all, see which HR vendors ship MCP servers, compared.
1. Which areas of my data does the server expose, and can I see the list?
Growee: 75 areas. 60 expose at least one write tool, four of them switched on at the area level and the rest gated on a role permission; 23 expose a delete tool, every one gated on a role permission. An assistant enumerates the areas itself through the discovery tools.
2. Whose identity does a call run as?
Growee: The Growee user who authorized the connection, resolved by the app's normal authentication guard, with tool access bounded by that user's permissions. An AI employee runs as its own Growee user.
3. How does a client authenticate, and how do I revoke it?
Growee: OAuth authorization code with PKCE S256, discovery metadata and RFC 7591 dynamic client registration, or a static token limited to a tool allowlist. Deleting a static token takes effect immediately, and its owner is who manages it from the token screen. An admin screen that lists and revokes other people's tokens, and revoking a person's tokens when their account is archived, are not yet shipped. Ending an OAuth connection from inside Growee is not yet shipped either. An access token lasts 10 minutes and a refresh token 20 days, so a connection that is left unused stops working once its refresh token expires; an app that keeps refreshing keeps its access.
4. Which plan includes it, and how is usage metered?
Growee: MCP is included on every plan. Free workspaces get 1,000 successful tool calls a calendar month, shared across the workspace; any paid plan lifts the cap; a call past the cap is refused with 429 and a body naming the usage, cap, reset date and upgrade link.
5. How is one customer's data kept out of another's?
Growee: 116 workspace-scoped models carry a global query filter on the workspace id, membership is checked on every call, and naming a workspace that does not exist is a 404 rather than a fallback. On top of that, every record a listing returns is checked against its area's own view rule before the response leaves the server.
6. What is logged about each call, and for how long?
Growee: A per-call log is not yet shipped. What exists is current-state attribution: records created or updated through an assistant carry your user as creator and last editor on 47 models, and not every area keeps those columns. Each static token shows when it was last used, and an OAuth connection has no last-used timestamp.
7. Do write tools exist, and what gate does each one pass?
Growee: Yes. Create and update run the app's own authorization check before writing, the same check the REST API runs. At the area level, four areas switch a create or update on with no condition and the rest are gated on a role permission, often paired with a per-tenant CRM entitlement. Delete tools exist on 23 of the 75 areas and each is switched on by a role permission.
8. Can a secret ever be returned to the model?
Growee: Not yet. Growee does not yet mask every credential field on the MCP path, so this is a gap rather than a guarantee. Passwords are not exposed as a field.
Last updated: September 2026
Security reviewer FAQ
The questions a security review asks about an MCP server, answered from the code that ships. Anything missing? Email security@growee.ai.
Does the assistant see everything in Growee?
No. Read access is checked at two levels. Each area of the product decides whether its listing tool exists at all: 54 of the 75 areas inherit the framework's open default and 21 set their own rule. Every record a listing returns is then checked against that area's own view rule before it leaves the server, and 29 areas narrow the query on top of that. On some areas that view rule is passed by any member of the workspace, so this is a per-area answer rather than a blanket one. Field visibility is separate again: 14 areas declare field-level rules, and on employees the salary and internal-cost fields need the matching permission.
Can an assistant delete records?
In some areas. Delete tools exist on 23 of the 75 areas Growee exposes over MCP, and each one is switched on by a role permission. Creates and updates reach further: 60 of the 75 areas expose at least one write tool, four of them switched on at the area level and the rest gated on a role permission, often paired with a per-tenant CRM entitlement, and either way the create or update runs the app's own authorization check before it writes. Campaigns are created in draft by default, and drip automation only starts sending once you activate them.
Can I limit which tools a token can call?
Yes, on the Settings path: you create a static MCP client token in Settings, Integrations, MCP Client Tokens, tick exactly which tools it may call, or grant every tool with a wildcard. The Claude Code skill mints its own connection token instead, and that token carries every tool. An operation that is missing from a token's allowlist is refused when an assistant tries to run it, not just when the tool list is built.
Is there a log of what the assistant did?
A per-call log of MCP requests is not yet shipped. What exists today: on the 47 models that keep creator and editor columns, records created or updated through an assistant carry your Growee user as their creator and last editor, and each static MCP client token shows when it was last used. Not every area keeps those columns. An OAuth-connected app has no last-used timestamp, so that column applies to static tokens.
How do I revoke an assistant's access?
A static MCP client token is deleted by the person it was issued to, from Settings, and the delete takes effect immediately, so the token stops authenticating on its next use. Regenerating a token invalidates the old secret at once. Revoking a person's tokens when their account is archived, and an admin screen that lists and revokes other people's tokens, are not yet shipped. Ending an OAuth connection from inside Growee is not yet shipped either: an access token lasts 10 minutes and a refresh token 20 days, so a connection left unused stops working once its refresh token expires, while an app that keeps refreshing keeps its access. Signing out of the Growee web app does not revoke MCP client tokens or OAuth connections.
Where does the MCP endpoint run?
The application server that answers MCP requests runs on AWS in the EU, in Ireland. Each workspace connects to its own endpoint, and every Growee response, the MCP endpoint included, is sent with HTTP Strict Transport Security for the domain and its subdomains. For data residency, encryption, subprocessors and the independent penetration test, see the Trust Center.
Is MCP included in my plan?
Yes, on every plan including the free one. A free workspace is metered at 1,000 successful tool calls a calendar month, counted per workspace and reset at the start of the next month, and any paid plan lifts the cap, not just a paid CRM plan. Only successful tool calls count: listing the tools, connecting, and calls that fail do not. A call past the cap is refused with HTTP 429 and a body that says how many calls were used, the cap, when it resets, and where to upgrade. The free CRM stays free up to 100 leads and one CRM seat.
Does the AI provider see our data?
This page documents the Growee side of the connection: what an assistant can reach, as whom, and under which checks. Responses go to the MCP client you connected. For the providers Growee itself engages and what each one processes, see the subprocessor list and the AI question in the Trust Center FAQ.
Our engineers answer security questionnaires directly, MCP ones included. Reach us at security@growee.ai and we will get back to you within 3 business days.