docs: fix typos and grammar (#12278)

Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>

docs/developer-guide/aws-details.mdx

@@ -39,7 +39,7 @@ The AWS provider implementation follows the general [Provider structure](/develo
 - **Key AWS Responsibilities:**
     - Receives an `AwsProvider` instance to access session, identity, and configuration.
     - Manages clients for all services by regions.
-    - Provides `__threading_call__` method to make boto3 calls in parallel. By default, this calls are made by region, but it can be overridden with the first parameter of the method and use by resource.
+    - Provides `__threading_call__` method to make boto3 calls in parallel. By default, these calls are made by region, but it can be overridden with the first parameter of the method and use by resource.
     - Exposes common audit context (`audited_account`, `audited_account_arn`, `audited_partition`, `audited_resources`) to subclasses.
 
 ### Exception Handling
@@ -59,7 +59,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
 - Directly in the code, in location [`prowler/providers/aws/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/aws/services)
 - In the [Prowler Hub](https://hub.prowler.com/). For a more human-readable view.
 
-The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all AWS services.
+The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all AWS services.
 
 ### AWS Service Common Patterns
 
@@ -68,7 +68,7 @@ The best reference to understand how to implement a new service is following the
 - The constructor (`__init__`) always calls `super().__init__` with the service name and provider (e.g. `super().__init__(__class__.__name__, provider))`). Ensure that the service name in boto3 is the same that you use in the constructor. Usually is used the `__class__.__name__` to get the service name because it is the same as the class name.
 - Resource containers **must** be initialized in the constructor. They should be dictionaries, with the key being the resource ARN or equivalent unique identifier and the value being the resource object.
 - Resource discovery and attribute collection are parallelized using `self.__threading_call__`, typically by region or resource, for performance. The first parameter of the method is the iterator, if not provided, it will be the region; but if present indicate an array of the resources to be processed.
-- Resource filtering is consistently enforced using `self.audit_resources` attribute and `is_resource_filtered` function, it is used to see if user has provided some resource that is not in the audit scope, so we can skip it in the service logic. Normally it is used befor storing the resource in the service container as follows: `if not self.audit_resources or (is_resource_filtered(resource["arn"], self.audit_resources)):`.
+- Resource filtering is consistently enforced using `self.audit_resources` attribute and `is_resource_filtered` function, it is used to see if user has provided some resource that is not in the audit scope, so we can skip it in the service logic. Normally it is used before storing the resource in the service container as follows: `if not self.audit_resources or (is_resource_filtered(resource["arn"], self.audit_resources)):`.
 - All AWS resources are represented as Pydantic `BaseModel` classes, providing type safety and structured access to resource attributes.
 - AWS API calls are wrapped in try/except blocks, with specific handling for `ClientError` and generic exceptions, always logging errors.
 - If ARN is not present for some resource, it can be constructed using string interpolation, always including partition, service, region, account, and resource ID.
@@ -162,7 +162,7 @@ When you instantiate `Check_Report_AWS`, you must provide the check metadata and
 
 If the resource object does not contain the required attributes, you must set them manually in the check logic.
 
-Other attributes are inherited from the `Check_Report` class, from that ones you **always** have to set the `status` and `status_extended` attributes in the check logic.
+Other attributes are inherited from the `Check_Report` class, from those you **always** have to set the `status` and `status_extended` attributes in the check logic.
 
 #### Example Usage
 

docs/developer-guide/azure-details.mdx

@@ -57,7 +57,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
 - Directly in the code, in location [`prowler/providers/azure/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/azure/services)
 - In the [Prowler Hub](https://hub.prowler.com/) for a more human-readable view.
 
-The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all Azure services.
+The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all Azure services.
 
 ### Azure Service Common Patterns
 

docs/developer-guide/checks.mdx

@@ -172,7 +172,7 @@ else:
 
 ### Resource Identification in Prowler
 
-Each check **must** populate the report with an unique identifier for the audited resource. This identifier or identifiers are going to depend on the provider and the resource that is being audited. Here are the criteria for each provider:
+Each check **must** populate the report with a unique identifier for the audited resource. This identifier or identifiers are going to depend on the provider and the resource that is being audited. Here are the criteria for each provider:
 
 - AWS
     - Amazon Resource ID — `report.resource_id`.

docs/developer-guide/gcp-details.mdx

@@ -102,7 +102,7 @@ The generic service pattern is described in [service page](/developer-guide/serv
 - Directly in the code, in location [`prowler/providers/gcp/services/`](https://github.com/prowler-cloud/prowler/tree/master/prowler/providers/gcp/services)
 - In the [Prowler Hub](https://hub.prowler.com/) for a more human-readable view.
 
-The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used accross all GCP services.
+The best reference to understand how to implement a new service is following the [service implementation documentation](/developer-guide/services#adding-a-new-service) and taking other services already implemented as reference. In next subsection you can find a list of common patterns that are used across all GCP services.
 
 ### GCP Service Common Patterns
 
@@ -113,7 +113,7 @@ The best reference to understand how to implement a new service is following the
 - Only projects with the API enabled are included in the audit scope.
 - Resource discovery and attribute collection can be parallelized using `self.__threading_call__`, typically by region/zone or resource.
 - All GCP resources are represented as Pydantic `BaseModel` classes, providing type safety and structured access to resource attributes.
-- Each GCP API calls are wrapped in try/except blocks, always logging errors.
+- Each GCP API call is wrapped in try/except blocks, always logging errors.
 - **Retry Configuration**: All `request.execute()` calls must include `num_retries=DEFAULT_RETRY_ATTEMPTS` for automatic retry on rate limiting errors (HTTP 429).
 - Tags and additional attributes that cannot be retrieved from the default call should be collected and stored for each resource using dedicated methods and threading.
 
@@ -161,7 +161,7 @@ When you instantiate `Check_Report_GCP`, you must provide the check metadata and
     - Defaults to "global" if none are available.
 
 All these attributes can be overridden by passing the corresponding argument to the constructor. If the resource object does not contain the required attributes, you must set them manually.
-Others attributes are inherited from the `Check_Report` class, from that ones you **always** have to set the `status` and `status_extended` attributes in the check logic.
+Other attributes are inherited from the `Check_Report` class, from those you **always** have to set the `status` and `status_extended` attributes in the check logic.
 
 #### Example Usage
 

docs/developer-guide/mcp-server.mdx

@@ -352,7 +352,7 @@ result = await self.api_client.poll_task_until_complete(
 
 ### Tool Docstrings
 
-Tool docstrings become description that is going to be read by the LLM. Provide clear usage instructions and common workflows:
+Tool docstrings become the description that is going to be read by the LLM. Provide clear usage instructions and common workflows:
 
 ```python
 async def search_items(self, status: str = Field(...)) -> dict:

docs/developer-guide/provider.mdx

@@ -31,7 +31,7 @@ Before implementing a new provider, you need to determine which type it belongs
 
 #### Decision Criteria
 
-Once you have decided the provider you want or need to add to Prowler, the next step is to study how to retrieve data from it. Based on that, the provider will fall into one of the following types: SDK, API or Tool/Wrapper (maybe in the future there will be new types but for now this are the only ones).
+Once you have decided the provider you want or need to add to Prowler, the next step is to study how to retrieve data from it. Based on that, the provider will fall into one of the following types: SDK, API or Tool/Wrapper (maybe in the future there will be new types but for now these are the only ones).
 
 **Choose SDK Provider if:**
 

docs/developer-guide/services.mdx

@@ -9,7 +9,7 @@ First ensure that the provider you want to add the service is already created. I
 </Note>
 ## Introduction
 
-In Prowler, a **service** represents a specific solution or resource offered by one of the supported [Prowler Providers](/developer-guide/provider), for example, [EC2](https://aws.amazon.com/ec2/) in AWS, or [Microsoft Exchange](https://www.microsoft.com/en-us/microsoft-365/exchange/exchange-online) in M365. Services are the building blocks that allow Prowler interact directly with the various resources exposed by each provider.
+In Prowler, a **service** represents a specific solution or resource offered by one of the supported [Prowler Providers](/developer-guide/provider), for example, [EC2](https://aws.amazon.com/ec2/) in AWS, or [Microsoft Exchange](https://www.microsoft.com/en-us/microsoft-365/exchange/exchange-online) in M365. Services are the building blocks that allow Prowler to interact directly with the various resources exposed by each provider.
 
 Each service is implemented as a class that encapsulates all the logic, data models, and API interactions required to gather and store information about that service's resources. All of this data is used by the [Prowler checks](/developer-guide/checks) to generate the security findings.
 
@@ -21,9 +21,9 @@ Within this folder the following files are also to be created:
 
 - `__init__.py` (empty) – Ensures Python recognizes this folder as a package.
 - `<new_service_name>_service.py` – Contains all the logic and API calls of the service.
-- `<new_service_name>_client_.py` – Contains the initialization of the freshly created service's class so that the checks can use it.
+- `<new_service_name>_client.py` – Contains the initialization of the freshly created service's class so that the checks can use it.
 
-Once the files are create, you can check that the service has been created by running the following command: `uv run python prowler-cli.py <provider> --list-services | grep <new_service_name>`.
+Once the files are created, you can check that the service has been created by running the following command: `uv run python prowler-cli.py <provider> --list-services | grep <new_service_name>`.
 
 ## Service Structure and Initialisation
 
@@ -31,7 +31,7 @@ The Prowler's service structure is as outlined below. To initialise it, just imp
 
 ### Service Base Class
 
-All Prowler provider service should inherit from a common base class to avoid code duplication. This base class handles initialization and storage of functions and objects needed across services. The exact implementation depends on the provider's API requirements, but the following are the most common responsibilities:
+All Prowler provider services should inherit from a common base class to avoid code duplication. This base class handles initialization and storage of functions and objects needed across services. The exact implementation depends on the provider's API requirements, but the following are the most common responsibilities:
 
 - Initialize/store clients to interact with the provider's API.
 - Store the audit and fixer configuration.