Opsphere — DevOps & SRE Intelligence

GHE: Search Code in Org

ghe_search_code

Read-only

Search code remotely in GitHub across the organization (REST /search/code). Use repo:owner/name or the shorthand repo:name.

Input Schema

Name	Required	Description
`q`	Yes	GitHub code-search query, e.g. "VERCEL_TOKEN path:.env" or "symbol repo:owner/name".
`org`	No	Optional org; defaults to the active workspace GHE_ORG or Cloud Catalog github_org.
`limit`	No
`context_id`	No	Optional explicit Connection Hub work context (ctx_*). Omit to use the conversation's active workspace; global Hub tools ignore it.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	Yes
`contractVersion`	Yes
`dataSchemaVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

changedOutput schema / properties / data / additionalProperties
```
Previous value: -trueNew value: +false
```
changedOutput schema / properties / data / properties / items / items / additionalProperties
```
Previous value: -trueNew value: +false
```

addedOutput schema / properties / dataSchemaVersion

Added value: +{
+  "const": 2,
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "contractVersion",
-  "ok",
-  "data"
-]New value: +[
+  "contractVersion",
+  "dataSchemaVersion",
+  "ok",
+  "data"
+]

First observedOct 15, 2026

TDQS

B3.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the REST endpoint and the word 'remotely'; it does not disclose rate limits, permissions, result caps, pagination behavior, or search scope limitations.

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?

Two short sentences are front-loaded with the core purpose and query syntax. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, rich annotations, and mostly documented parameters, so the description need not explain return values. It covers purpose and key query syntax, though it could be more complete about scope defaults and search limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already documents q, org, and context_id. The description adds the shorthand repo:name syntax for q, but does not explain the limit parameter or add meaning beyond the schema for the remaining parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: search code in GitHub across an organization, and names the REST endpoint. It is distinguishable from sibling tools such as ghe_org_repos or ghe_repo_summary, though it does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives syntax guidance for the query using repo:owner/name or repo:name, which implies code-search usage. However, it does not state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Opsphere — DevOps & SRE Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?