Platform / MCP Configuration
MCP Configuration
The foundational building block that defines what data your AI agent can access, what actions it can take, and who can use it. Create one in minutes.
Your Agent's Settings
What it is
A configuration bundles everything your AI agent needs into a single, manageable unit. It has four components: data sources, permission policies, deployments, and API keys.
Think of it as a permissions profile for your AI. You decide exactly what it can see, what it can do, and who gets access -- all in one place.
Every new Telara organization comes with a default connection pre-configured. When your team members run telara login for the first time, their coding tools are automatically connected — no manual configuration needed. As an admin, you can add data sources and permissions at any time and they take effect immediately for all connected users.
Quick Start
Custom configurations
Beyond the default connection, you can create custom configurations to give different teams or projects specific data access and permissions. Set one up in four steps.
Go to Capabilities > Configurations and click "Create Configuration." Give it a name that reflects its purpose -- for example, "engineering-readonly" or "support-team-full-access."
Select the integrations your agent should have access to. Choose specific repositories, projects, or channels -- or include everything from an integration. Your agent only sees what you explicitly allow.
Assign the configuration to your organization, a specific team, or an individual user. This controls who can connect to this configuration from their IDE or other tools.
Create an API key and add it to your tool settings (Claude Code, Cursor, etc.). The key is shown once at creation -- copy it immediately.
Data Access
Data sources
Data sources define what content your agent can search through in your knowledge base. Every integration you have connected to Telara can be added as a data source. You control the scope down to individual repositories, projects, or channels.
Adding GitHub as a data source lets your agent search code and issues. It does not let your agent create issues or open pull requests. For that, you need a permission policy.
Built-in Capabilities
Search tools
Every configuration comes with four built-in search tools at no extra setup. These tools work immediately once you add data sources -- no permission policies required. They are read-only by design, giving your agent powerful search and context capabilities without any risk of modifying your data.
Search across all your configured data sources using natural language. Ask "how does authentication work in the backend?" and get relevant results from code, issues, messages, and documents.
Use when your agent needs to find information across integrations without knowing exact file names or issue numbers.
Navigate relationships between items in your knowledge base. Follow connections from a code file to the issues that reference it, the pull requests that modified it, and the Slack conversations that discuss it.
Use when your agent needs to understand how things connect -- tracing dependencies, finding related work, or mapping impact.
Get rich, structured context for a specific item. Returns the item itself along with its relationships, history, and surrounding context -- everything your agent needs to understand it fully.
Use when your agent has identified a specific item and needs comprehensive detail before taking action or answering a question.
Access the full content of your indexed data. Read the complete text of documents, code files, and messages as they were when they were last synced.
Use when your agent needs the actual content of a file or document, not just search results or summaries.
Adding Actions
Permission policies
Want your agent to do things, not just search? Attach a permission policy to unlock live actions. Policies control which actions your agent can perform -- creating issues, posting messages, updating tickets, and more.
Without any policies, your configuration is read-only. Your agent can search and retrieve information using the built-in search tools, but it cannot modify anything. This is by design -- you opt in to write access explicitly.
You can attach multiple policies to a single configuration. When policies overlap on the same action, the most restrictive setting wins. This means you can layer policies safely -- adding more policies never loosens permissions.
Access Control
Deployments
Deployments control who can use a configuration. Deploy to your entire organization for a shared baseline, or target specific teams and users for tailored access.
More specific scopes override broader ones. If your organization has a default configuration but the engineering team has its own, engineers will get the team-level config. If a specific user has a personal override, that takes priority over everything.
Connecting Your Tools
API keys
API keys connect your tools to a specific configuration. Generate a key, add it to your tool's settings, and you are ready to go. Works with Claude Code, Cursor, or any compatible tool.
Each key is tied to a user and a configuration. The raw key is shown exactly once when you create it -- copy it immediately and store it securely. You can revoke a key at any time, and it takes effect instantly.
Access Model
API key permissions
Who can generate an API key depends on the scope the key is being created for. The scope must be within the deployment scope of the configuration -- you cannot generate a broader-scoped key than what the configuration is deployed to.
For example, if a configuration is deployed to a specific team, only members of that team (with owner, admin, or maintainer role) can generate keys for that team or for individual users. They cannot generate an organization-wide key for a team-scoped configuration.
| Key Scope | Who Can Generate | Required Deployment |
|---|---|---|
| organization | Organization admin or security admin | Must be deployed at organization scope |
| team | Team owner, admin, or maintainer | Must be deployed at organization or team scope |
| project | Project owner, admin, or maintainer | Must be deployed at organization or project scope |
| user | The user themselves only | Any deployment scope |
How It Works
How your tools connect
When your tool connects, Telara resolves the right configuration automatically. It identifies you from the API key, finds the most specific deployment that applies, applies any permission policies, and makes the appropriate tools available -- all instantly.
Common Patterns
Use cases
Configurations are flexible enough to support anything from a simple search-only knowledge base to a fully interactive assistant with scoped permissions per team.
- Add GitHub, Jira, and Confluence as data sources
- No permission policies needed
- Agent can search, browse, and read -- nothing else
- Deploy to the whole organization as a safe default
- Same data sources as above
- Attach a policy that unlocks creating issues and adding comments
- Set sensitive actions to require approval
- Agent can search AND take action on your behalf
- Engineering team gets repos + Jira + read-write policy
- Support team gets Zendesk + Slack + read-only policy
- Each team sees only the data relevant to their work
- Individual users can get overrides when needed
Recommendations
Best practices
Follow these guidelines to get the most out of your configurations while maintaining strong security.
Create your first configuration without any permission policies. Verify that your agent can search and retrieve the right data before unlocking actions. This lets you validate data source filtering without risk.
When you are ready for write access, start with "require approval" on sensitive actions. Once you are confident in the agent's behavior, selectively move actions to "auto-approve." You can always tighten permissions later.
Set a conservative organization-wide default, then create more permissive configurations for specific teams that need them. This ensures every user has a baseline while power users get the access they need.
Set expiration dates on your API keys and rotate them on a regular schedule. Use the usage tracking to identify keys that have not been used recently -- they may be safe to revoke. Never share keys between users.