Tool Catalog

The tool catalog is MITRITY's registry of every tool, API, service, or resource that your AI agents can interact with. By cataloging tools, you enable fine-grained governance: instead of writing policies against raw action strings, you grant Capabilities at the tool level with operation-level granularity, set rate limits, and track usage patterns.

Browse the catalog at /app/tools. The page is split into three tabs:

Built-in (default) — the 82-tool catalog MITRITY ships with. Read-only on the customer side; MITRITY ops maintain it.
Custom — tools your tenant has authored. Create, edit, and delete here.
All — flat view across both sources.

Click any tool row to see the full operation list grouped by underscore-prefix (e.g. repos_*, actions_*) along with the action-type pattern, scopes, and resource pattern.

Built-in vs custom tools

Origin	Where it comes from	Who can create / edit / delete
Built-in	Shipped with MITRITY. Available to every tenant.	MITRITY only. The Custom tab is the home for customer authoring.
Custom	Authored for your tenant. Not visible to other tenants.	Anyone in your tenant with the `member` role or above. Use the Custom tab in the dashboard or the API endpoints below.

Built-in tools are unmodifiable on the customer side — the backend rejects mutation on is_builtin=true rows so the catalog stays consistent across tenants. To request a new built-in addition, file a request with support; meanwhile you can ship the same shape as a custom tool immediately.

What the v1 built-in catalog covers

The v1 built-in catalog ships 82 tools spanning all 13 categories. A representative sample:

Category	Sample tools
Cloud storage	AWS S3, GCP Cloud Storage, Azure Blob Storage (each with an Admin variant)
Databases	PostgreSQL, MySQL, MongoDB, Redis, BigQuery, Snowflake, ClickHouse, Databricks (most with Admin variants for DDL/IAM)
Vector DBs	Pinecone, Weaviate, Qdrant (each with Admin variants for index management)
LLM providers	Anthropic, OpenAI, AWS Bedrock, Azure OpenAI, Google Gemini, Cohere, Mistral, Together AI
Source / CI / IaC	GitHub (104 grantable surfaces), GitLab, Bitbucket, Kubernetes, Terraform (with Apply variant), Docker
Comms / PM	Slack, Microsoft Teams (with Admin variants), Jira, Linear, Notion, Confluence, Asana, ClickUp, Intercom
Observability	Datadog, Sentry, Splunk (operator / Admin / Splunk Cloud Admin for ACS API), PagerDuty, New Relic
Email / Payments / CRM	SendGrid, AWS SES, Resend, Postmark, Stripe, HubSpot
Identity	AWS Secrets Manager, HashiCorp Vault
MITRITY platform	MCP Delegate (`delegate_to`), MCP Approve (`create_approval`, `wait_approval`)

Operations on each built-in are sourced verbatim from canonical sources — vendor MCP servers where they exist, official SDK method names otherwise, REST API endpoint inventories as a last resort. Names match what you would see in vendor docs (e.g. Slack's conversations_add_message, AWS S3's get_object), so policy authors can paste an operation back into the vendor's documentation to confirm semantics.

Several tools have Admin variants. The split separates routine ops (read, list, query) from dangerous ones (DDL, IAM, org/instance management) so customers can grant the broad surface widely and the admin surface narrowly. For example:

PostgreSQL covers SELECT, EXPLAIN, list_*, describe_* — safe to grant to most agents
PostgreSQL Admin covers CREATE, ALTER, DROP, GRANT, REVOKE — gate behind a stricter capability and an approval flow

MITRITY-platform tools

Two tools are MITRITY-platform primitives. Neither integrates with an external API; both are surfaces the gateway exposes to your agents directly.

Tool	Action pattern	Operations	What it does
MCP Delegate	`mcp:delegate:*`	`delegate_to`	The hand-off used in delegation chains. Every agent that should be able to delegate needs this granted.
MCP Approve	`mcp:approve:*`	`create_approval`, `wait_approval`	Hold-and-release approval flow. Agents can call `create_approval` to pause until a human resolves it from `/app/approvals`.

Both ship as built-ins so the multi-agent demo and approval flows work without per-tenant tool creation.

Authoring a custom tool

Use the Custom tab on /app/tools → Add tool. Required fields:

Name — display name (e.g. Internal CRM)
Category — one of the 13 above; pick custom if none of the others fit
Action type pattern — glob matched against the action_type the gateway sees (e.g. crm:*, mycorp:billing:*)
Operations — comma-separated list of operation names. Use vendor-verbatim names if you're modeling a real API (e.g. list_contacts, update_deal); use whatever names your agents actually emit otherwise.

Optional:

Resource pattern — second glob matched against the action target. When both match, the tool matches.
Scopes — list of named scopes the tool exposes (e.g. prod, staging). Customers grant subsets of these per agent via the Capabilities form's allowed_scopes / denied_scopes.

Once saved, the tool is immediately grantable from any agent's detail page → Capabilities → Add capability.

Edit and delete

Per-row actions on customer-owned rows. Editing changes operations and scopes for all existing Capability grants automatically (Capabilities reference the tool by ID, not by snapshot). Deleting cascades — any agent capabilities referencing the tool are removed too, and those agents fall back to policy-rule evaluation for the affected actions.

Match rules

Match rules determine how raw agent actions map to tool catalog entries.

Action type patterns

Action type patterns use glob syntax to match the action_type field the gateway records on each event:

Pattern	Matches	Does not match
`s3:*`	`s3:get_object`, `s3:put_object`	`gcs:get_object`
`mcp:slack:*`	`mcp:slack:chat_post_message`, `mcp:slack:conversations_history`	`slack:chat_post_message` (no `mcp:` prefix)
`db:postgres:*`	`db:postgres:select`, `db:postgres:explain`	`db:mongo:find`

The prefix is set by the integration surface: native vendor SDKs use the vendor's namespace (s3:*, github:*); MCP-server-mediated tools use mcp:<vendor>:* (mcp:github:*, mcp:slack:*, mcp:postgres:*). The two coexist intentionally because the action_type the gateway records reflects which integration path the agent took.

Resource patterns

Resource patterns match an action's target (typically a URL, resource ID, or path):

Pattern	Matches
`.s3.amazonaws.com/`	`my-bucket.s3.amazonaws.com/data/file.csv`
`https://api.openai.com/*`	`https://api.openai.com/v1/chat/completions`
`postgres://prod-:5432/`	`postgres://prod-db:5432/myapp`

Combined with action_type pattern, this lets you scope tools narrowly — e.g. a tool that only matches PostgreSQL queries against production databases.

Operations

Operations define grantable surfaces on a tool. The catalog uses verbatim names from canonical sources — not a normalized read/write/delete vocabulary. For example:

AWS S3: get_object, put_object, list_objects_v2, delete_object (from the AWS SDK)
Slack: conversations_add_message, chat_post_message, reactions_add (from the Slack MCP server)
GitHub: 104 grantable surfaces including dispatcher sub-resources like actions_run_trigger:cancel_workflow_run
MCP Delegate: delegate_to

This means policy authors can paste an operation back into the vendor's docs to confirm its semantics. Some tools have very large surfaces (47+ for Splunk Cloud Admin, 104 for GitHub MCP, 51 for GitLab); the Capabilities picker groups them by prefix and offers Use wildcard * as a shortcut for "grant everything this tool exposes now and in the future" backed by the same glob support the backend evaluator uses.

API reference

GET /api/v1/tools and GET /api/v1/tools/{id} are available to any authenticated tenant key. POST, PUT, and DELETE enforce tenant ownership and reject mutation on is_builtin=true rows.

List tools

curl https://api.mitrity.com/api/v1/tools \
  -H "Authorization: Bearer mk_your-api-key"

Query parameters:

Parameter	Type	Description
`search`	string	Case-insensitive substring match on name
`is_builtin`	`true` \| `false`	Filter to built-in or custom only. Omit for both.
`sort_by`	`name` \| `created_at`	Sort field
`sort_order`	`asc` \| `desc`	Sort direction
`limit`	integer	Results per page (default 25)
`offset`	integer	Pagination offset

Create a custom tool

curl -X POST https://api.mitrity.com/api/v1/tools \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Internal CRM",
    "category": "custom",
    "match_rules": {
      "action_type_pattern": "crm:*",
      "resource_pattern": "https://crm.internal.company.com/api/*"
    },
    "operations": ["list_contacts", "get_contact", "update_contact", "list_deals", "create_deal"],
    "scopes": ["sales", "support"]
  }'

Update or delete

PUT /api/v1/tools/{id} and DELETE /api/v1/tools/{id} accept tenant-owned tool IDs and return 403 on built-ins or cross-tenant requests. Delete cascades into tool_permissions; existing grants for the deleted tool are removed and those agents fall back to policy-rule evaluation for the affected actions.

Best practices

Lean on the built-in catalog

The 82 built-ins are sourced from canonical APIs and updated as vendors evolve. Granting MCP Slack (built-in) gets you Slack's actual operation names; rolling your own Slack custom tool with [send, read, list] shortcuts you out of the per-method governance the built-in supports.

Use the Admin tier

For high-stakes tools (databases, IAM, org admin), prefer granting the base tier widely and gating the Admin tier behind a stricter capability + approval flow. The split is purposeful — DDL on production should never travel with SELECT.

Match the integration surface in the pattern

If your agent uses a vendor's MCP server, pattern-match the mcp:<vendor>:* namespace. If it uses the vendor's SDK directly, match <vendor>:*. The two prefixes correspond to different audit trails and shouldn't be conflated.

Periodic catalog review

The Built-in tab gets new tools as MITRITY adds them. The Custom tab shows what your tenant has accumulated — review it monthly and prune tools that no agent uses; orphan custom tools complicate capability audits.

Category	Description	Examples
`storage`	File / object / blob storage	AWS S3, GCS, Azure Blob
`database`	Relational / document / KV / vector stores	PostgreSQL, MongoDB, Redis, Pinecone, BigQuery
`messaging`	Email, chat, notifications, SMS	Slack, Microsoft Teams, SendGrid, AWS SES, Postmark
`llm`	Large language model APIs	Anthropic, OpenAI, AWS Bedrock, Azure OpenAI, Gemini
`code_execution`	Code interpreters, shells, sandboxes	Python REPL, Shell
`code`	Source control	GitHub, GitLab, Bitbucket
`network`	HTTP, web fetch	HTTP Client, Web Fetch
`monitoring`	Observability, incident, search	Datadog, Sentry, Splunk, PagerDuty, Elasticsearch, New Relic
`infrastructure`	IaC, containers, orchestration	Terraform, Kubernetes, Docker
`project_management`	Issue trackers, knowledge bases	Jira, Linear, Notion, Confluence, ClickUp, Asana
`identity`	Secrets managers, vaults	AWS Secrets Manager, HashiCorp Vault
`search`	Search engines	Elasticsearch (when used as a search index)
`custom`	Anything not covered above, plus MITRITY-platform primitives	MCP Delegate, MCP Approve, custom tenant tools